Roadmap

[ISSOtm]

RGBDS is going through a transition phase of sorts, where answering some challenges (mainly implementing requested features) will require large changes. Thing is, some of these changes require others, which creates a dependency tree, recorded here so that people can contribute in useful ways.

• Symbol "layering" system

  • Local symbols ([Feature request] File-local defines #342), for restoring symbols on scope exit
  • User-defined functions ([Feature request] User-defined functions #201), for allowing "placeholder" symbols for params

• Expression system rewrite
  An expression can either be "known", storing a single i32 value, or "unknown", storing a full-blown RPN expression. (Numeric constants are known, symbols may or may not be, and the logic for operators is generally that it's known if all operands are, but there are exceptions).
  Eager evaluation of expressions is a triple performance benefit:

  • No need to lug around a RPN buffer (realloc is slow)
  • RGBASM needs to evaluate some expressions (IF, REPT, everything called const or uconst in the grammar); eager evaluation only computes them once
  • Smaller expressions emitted in object files means smaller object files, which also implies faster linking (less read, less realloc

  Thus, eager evaluation cannot go away. It however has problems:

  • Expressions passed to RGBLINK may produce unexpected results if their parameters change, example:

    X = 3
        db X
    X = 4
    ; Is 3 emitted, or 4?
    

  • References are not emitted, leading to smart linking idiosyncrasies (see discussion in Implement smart linking #654), symbols sometimes not appearing in sym/map files, ...
    A proper expression rewrite is required for the following:
  • User-defined functions ([Feature request] User-defined functions #201), so that symbols can be lazily evaluated
  • Smart linking (Smart linking #82) needs references to still be emitted somehow
  • Not reporting errors as soon as encountered would allow discarding some of them (Make && and || short-circuiting #619, and then [Feature request] Ternary operator #621)
  • Just better behavior all around? It would probably break backwards compatibility, but would make more sense (right?)

[aaaaaa123456789]

Considering these are such disparate issues, it might be worth it to open separate discussions for each and link them here.

[ISSOtm]

Part of the point is to highlight that some changes (such as user-defined functions) actually have several "prereq" changes

[aaaaaa123456789]

I can see that being useful, which is why I suggested keeping this topic around and link the individual discussions in the OP.