Thank you! My main inspiration was the Uxn assembly language [0], which is itself heavily inspired by Forth. I loved how easy it was to build something that looks like a high-level language by just stacking up macros, and I wanted to have that with embedded development too.

Rust isn't involved past implementing the Torque executable; you write your program with the Torque language and then run the assembler on it to convert it to machine code. You can see the whole process of running code on the TRS-80 from start to finish here [1].

For laying out structs, I'd build a macro that expands to the memory representation of the struct. If I wanted a struct representing, say, a 2D point with signed 16-bit little-endian integers for the x and y coords, I would build it from scratch like this (this is a valid program, you can assemble it with Torque):

  %BYTE:n     #nnnn_nnnn          ;
  %LOW:n      BYTE:[n 0xff <and>] ;
  %HIGH:n     BYTE:[n    8 <shr>] ;
  %16LE:n     LOW:n HIGH:n        ;
  %POINT:x:y  16LE:x 16LE:y       ;   
  
  @point-1 POINT:50:-7 
  @point-2 POINT:20:-45
  @point-3 POINT:0:0

If I want the address of a field, I can add an offset to the struct address, using macros to name the offset values:

  %POINT.X  0 ;
  %POINT.Y  2 ;
  SET:[point-3 POINT.X +]:15
  SET:[point-3 POINT.Y +]:32

Creating a DSL for an existing language wasn't something I'd ever considered. By being a standalone executable it's really easy to use and share, people don't have to install a whole language toolchain in order to use it.

Regarding constraints solving and jumping, Torque already throws an error if you try to pack too large a value into too small a field. This works really well for things like relative jumps, because jumping too far will create a value that can't fit in the instruction. I'm planning on adding an error-throwing token to the language that could be used alongside expressions and conditions to further constrain the values accepted by a macro, but I'm really happy with the simplicity of the language so far.

The actual internal representation isn't what I'd call an 'IR' per se, nothing like with a C compiler. It's all very pedestrian; the syntax tree is baked down across multiple passes, with macros acting as a glorified copy-paste system.

Thanks for the interest and the links, every one of those linked projects is new to me.

[0] https://wiki.xxiivv.com/site/uxn.html

[1] https://benbridle.com/articles/torque-programming-the-trs-80...