Assembling Local Variables

Another major class of programming language functionality which cannot easily be expressed simply as loading a constant or calling a function is local variables: What C afficionados call "automatic" variables.

The Muq assembler supplies the following functions in support of local variables:

• assembleVariableSlot Allocate a local variable.
• assembleVariableGet Load from a local variable.
• assembleVariableSet Store to a local variable.

Let's assemble code for : square -> x x x * ; as an example:

stack:
"square" --> *fun*$s.name
stack:
*asm* reset
stack:
"x" *asm* assembleVariableSlot --> *x*
stack:
*x* *asm* assembleVariableSet
stack:
*x* *asm* assembleVariableGet
stack:
*x* *asm* assembleVariableGet
stack:
'* *asm* assembleCall
stack:
nil -1 *fun* *asm* finishAssembly --> *cfn*
stack:
*cfn* 'square setSymbolFunction
stack:
2 square
stack: 4

This time, a peek at the disassembly shows:

constants:
code bytes:
00: 2d 01 38 00 36 00 36 00 0e 2e
code disassembly:
000:      2d 01       VARS   1
002:      38 00       SETv   0
004:      36 00       GETv   0
006:      36 00       GETv   0
008:      0e          MUL    
009:      2e          RETURN 

By now, you can probably divine most of the coding rules by inspection:

• Allocate every local via assembleVariableSlot.
• Don't assume anything about the return value from assembleVariableSlot, except that it will be accepted by assembleVariableGet and assembleVariableSet.
• Give assembleVariableSlot as input the name of the local variable, as specified by the user. If the local is compiler-generated, pick a descriptive name that starts with a blank: Debuggers will normally suppress display of these.

Some fine points:

• All local variables are always allocated at the start of the function, via a single VARS instruction. The assembler counts the number of locals you allocate and emits the proper VARS instruction. If you allocate no locals, it generates no VARS instruction, as another minor optimization. There is no need for the compiler writer to count the number of locals allocated, or to attempt to allocate them all before starting to generate code.
• Access to locals is much faster than access to symbols (and about as fast as access to constants). You should feel free to use locals; You should avoid generating needless accesses to symbols. (Access to vector slots will be a bit slower than access to symbol value slots, of course, and access of object properties will be much slower yet.)

Go to the first, previous, next, last section, table of contents.