Description
Assuming we have a DSL roughly like this (modified per #477), we have a few ways to integrate this.
- We could place the generator input in a separate file, and the generator script (automatically run by
makewhen the DSL file is updated) writes the interpreter cases to a separate file (I'll call itcases.hfor now, we can bikeshed the actual name later). Inceval.cwe replace all the cases (roughly 4000 lines) with a single#include "cases.h". (Presumably we'd checkcases.hinto git, just so people can bootstrap more easily.) - Place the generator input in a separate file, but have the generator update
ceval.cin place, sort of like . A downside is that people will undoubtedly confused and try to edit the generator output. (We could add comments warning them off, but we'd probably have to repeat those comments for each case.) - Place the generator input in
ceval.c, exactly where the cases are currently, but surrounded by#ifetc. so that the compiler uses the#include "cases.h"but tooling (e.g. VS Code) sees the generator input and believes this is the actual code. (This may actually be a little bit complicated, because at least VS Code understands#ifand expands them according to the configured variables. We'd have to fool it, otherwise it'll think that the generator input is all dead code and dim its appearance.) The generator can find its input by readingceval.c, looking for the appropriate marker#ifand#else. It still writes its output tocases.h.
(3) feels like a bit more complicated to implement, but is probably the most user-friendly for people trying to read or edit the generator input, since they see it in a context where their editor can show them both the C code for an instruction and the surrounding C code (static functions they call, and the non-generated parts of the function containing the switch). It also preserves the git history of the C code included in the generator input.
I'm not keen on (2), because of the mechanics of rewriting ceval.c in place. But it does preserve git history, like (3).
The simplest to build is probably (1). It does not preserve git history, however (the code of all instructions would be owned by the initial creator of the input file).
I think I've convinced myself to prototype (3) and see how this works out. Now on to designing the architecture of the generator. :-)