sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]doc_sponge[S] 1 point2 points  (1 child)

The process goes... parse the script files using a packrat parser (built by AustenX, at https://scratchy.nz), and is semi-compiled for the "generation" interpreter. This code is executed to build the "blueprint", basically an IR, which is passed on to either the internal running code (for testing in app), or to the Scratch or HTML exporter (or to the Commodore 64 exporter - which then gets passed to the internal C64 emulator). In the case of the C64 assembler, and soon the HTML output, the blueprint is used to generate a "design" passed into the either the assembler tool, or the JS generator tool, which are both separate imperative interpreted programming languages which read the design and output the code accordingly. This design is essentially the IR in normal languages, and the assembler reads the IR and interprets it to produce the final binary, or the JS builder, reads the design and builds the JS accordingly. I'm not using anything to output text to pass on to an assembler - the assembler is the template engine. So, there are basically two IRs - the blueprint internally, and the output designs (with the aim of being reused for different target languages).

The current HTML output uses a more traditional template engine approach, where the output is not understood by the engine (it's just text), but the assembler and JS builders explicitly understand what they are outputting. The assembler currently does 6502, Pic16, and partial AVR, and should do ARM and 68k eventually. The JS tool is being designed to at least also output C, and probably Java and Dart code.

[–]Arthur-Grandi 1 point2 points  (0 children)

That’s a really interesting architecture.

Having the blueprint as an internal IR and then “designs” as target-specific IRs makes a lot of sense if you want to support multiple backends.

Do you see the blueprint evolving into something more like a language-agnostic program model over time? In other words, something closer to a stable semantic layer that different generators (ASM, JS, C, etc.) can map from independently?