Conversation

Notices

1. Embed this notice
   alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:13:20 JST alcinnz

   How'd I bootstrap a bytecode interpreter for Lua upon only the devtools we've built so far & our hypothetical idiomatic computer ( https://adrian.geek.nz/from-scratch/personal-computer )?

   I'd want to use our stack-based mid-level language embedded within Assembly, so we could have a table of which label to jump to for each opcode. Each would would jump back up to the start of this fetch/increment/execute loop.

   I'd give these opcodes a syntax akin to that mid-level language to be used later, mostly for string literals.

   1/5

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:21:52 JST alcinnz

     in reply to

     I'd have an opcode which pushes a literal value onto the stack, & on occasion we'd need to swap values. Followed by a 32bit value unless its a bool or nil. Occasionally we may need to duplicate or maybe swap or pop the top-of-stack.

     I'd have a goto opcode that sets the program counter, & conditional gotos which branch depending on if the top-of-stack is false or nil.

     I specifically include "maybe ops" in the CPU so simpler sub-opcodes for maths can be interpreted by the CPU itself.

     2/5?

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:30:12 JST alcinnz

     in reply to

     This opcode for maths would resolve the types before handing its parameter off to special CPU circuits to evaluate that integer or floating point microcode, or for records to its appropriate metamethod. There'd be a separate opcode for unary operators.

     Some math ops may have dedicated opcodes.

     I'd have a couple 2-arg opcodes (maybe I make these opcodes 32bits wide afterall?) to set a given "local" in so many frames back of the closure.

     And opcodes for getting/setting a value in a record.

     3/5

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:41:35 JST alcinnz

     in reply to

     There'd be an opcode for allocating a record with a given capacity.

     I'm choosing to "adjust" multiple-assignment at runtime, so add an opcode to capture the current stack-height in another stack, & another to ensure there's only so-many values after that point on the stack. Ensuring unused stackslots are nil'd could speed up elongating this!

     These "tuples" would also be used for handling function arguments & returns!

     I'd have an opcode for allocating a closure for a given function.

     4/5

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:47:01 JST alcinnz

     in reply to

     Functions would have opcodes for the calling them (pushing interpreter state to a callstack, & replacing it), & returning from them (popping callstack).

     Or the CALL opcode could jump to some assembly code a reference to which has been popped off the value stack. This would be useful for exposing the code we've written so far to Lua programs, manipulating the interpreter itself, or compiling the Lua code to run faster without the dynamic typechecks!

     As for variadic functoins & methods...

     5/5.5

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:54:16 JST alcinnz

     in reply to

     I'd add variations of the tuple opcodes to gather remaining arguments into a record (with an `n` property holding its length) to store as a `...` argument. And maybe I'd include an UNPACK opcode to push all those values onto the stack, to reflect the behaviour of `...` in Lua.

     And I'd have a variant of the OPEN-TUPLE opcode which first swaps the top stackslots & ensures the new-top is in the tuple as the first argument. For the "method" syntactic sugar.

     6/6.2!

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 04:58:21 JST alcinnz

     in reply to

     Finally I'd give the opcodes for getting/setting entries in a record the ability to store the key as a literal in the opcodes. For missing keys they will consult metamethods if available.

     I'd include a mode which disables consulting metamethods.

     And there'd be a few other more minor opcodes as well. But this mostly covers it!

     6.3/6.3 Fin for today!

   • Embed this notice
     Forth Co-Processor (pythonlinks@mastodon.social)'s status on Friday, 03-Jan-2025 05:32:00 JST Forth Co-Processor

     in reply to

     @alcinnz

     Writing a #LUA interpreter in verilog on an #FPGA is of interest to me. But sadly the newest vrsions of LUA are based on a register virtual machine, only the older versions are based ona. stack virtual machine.

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 05:32:17 JST alcinnz

     in reply to

     • Forth Co-Processor

     @PythonLinks I'm sure you could still implement it as a stack machine!

   • Embed this notice
     alcinnz (alcinnz@floss.social)'s status on Friday, 03-Jan-2025 05:38:29 JST alcinnz

     in reply to

     • Forth Co-Processor

     @PythonLinks I will remark that this isn't the only way I've moved computation from compiletime to runtime in my design of a Lua interpreter!

     The end-tuple opcode I described is parse-time in the reference implementation. Apart from around function calls.