rsgbds — RGBDS, but in Rust!
This is a continuation of RGBDS (source code), but written in Rust instead of C and C++.
I grew tired of RGBDS' crashes, uncleanliness, and memory leaks.
Additionally, writing code in C requires to "spell everything out", which makes writing actual logic very painful.
I have lost count of how many times I have reimplemented std::vector
thus far!
Some other functions, I have had to reimplement myself in the name of portability (asprintf
is only available as a GNU extension).
This forms the basis of my motivation for rewriting RGBDS in a language that isn't C. The latter especially hinders implementation of new features.
The choice of Rust comes from the following pros:
- I am familiar with it.
- It's portable, likely on every system that RGBDS can already run on.
- It has (next to) no runtime, and no GC, so RGBDS will stay fast like an assembler ought to be.
- Rust appears to be more popular than C, so this should help new contributors.
- A lot of good libraries already exist to externalise a lot of tasks (holy crap,
codespan-reporting
's output makes me drool). - The usual "no memory safety issues!" also applies.
I am also aware of the cons, but I believe Rust is the best compromise, at least for me.
RGBASM is the hardest program to rewrite of the four, for various reasons:
- it's by far the most complex;
- it is composed of a lot of interacting parts;
- it's entirely driver by the parser, so lifetimes are hard to track;
- oh and did I mention that it has a parser?
So, I am currently starting with RGBASM. The design decisions I will have to take in it may heavily influence the other tools' code.
- Rewrite RGBASM
- Integrate
rgbds-obj
into argbds
crate (which RGBLINK will use) - Rewrite RGBLINK
- Rewrite RGBFIX
- Rewrite RGBGFX
- Integrate
rgbobj
- Add an xtask for generating man pages from the CLI structs, warning list, and things like that. (This would avoid forgetting to document new CLI args, for example.) This will be useful.
Once all of this is done, cleanup time!
- Clean up / reorganise code:
- Split modules more? Maybe one per
struct
/enum
? - Reorganise e.g.
input.rs
, given how closely tied it is tofstack.rs
? Maybe it'd be worth deepening the file tree a little more. (Make sure to add aREADME.md
in each directory, to make the categorisation clearer.)
- Split modules more? Maybe one per
- Hand-write RGBASM's parser, to make all interfaces with the lexer saner:
- No more
RefCell
s, the parser can "lend" everything to thenext()
method! - Sync points between the lexer and parser would be easier to control, eliminating the need for
lookahead_hack
(and associated productions). - Syntax error "expected bar, foo, or comma" can be customised (e.g. "expected instruction or directive"), though this is a bit of a double-edged sword.
- No more
build.rs
, so, faster compile times! - Opens the door to revision-based grammar changes, to enhance back-compat (though I am far from ready for that rabbit hole yet...)
- Downside: the grammar is likely to be less obvious, and e.g. conflicts won't be reported (implicitly, they will be solved statically). Oh well, such is life.
- No more
This port of RGBDS is licensed under the Mozilla Public License, version 2.0.
This Source Code Form is subject to the terms of the Mozilla Public License, v. 2.0. If a copy of the MPL was not distributed with this file, You can obtain one at http://mozilla.org/MPL/2.0/.
The full text of the MPL v2.0 can be found in the LICENSE
file.