proj-jasper-jasperAssemblyNotes2

--

so, Jasper Assembly may be fixed-length, not for efficiency, but for ease of implementation. Code density is not a concern because we expect that a compiler will compile Jasper Assembly to a target system. We do, however, wish to preserve 'intent' so as to aid optimizations on a target system.

we'll probably have arbitrary word size, and allow the storage of complex data structures in one 'memory location'.

We might stick to things addressable by 1,2,4,16 bits. When to use what (um, this is kinda obvious..):

• 1 bit: when you have a bool
• 2 bits: when you need to address 4 things
• 4 bits: when you need to address 16 things
• 16 bits: when you need to address more than 16 things but less than 64k things
• arbitrarily large: when you need to address more than 64k things

ok, to add some meat to that:

• 1 bit: bool
• 2 bits: most small hardcoded enumerations in the language definition should usually have less than 4 items; 4 is probably the maximal size (out of the choices 1,2,4,16,65536) for something to have a human-comprehensible 'crystalline' assembly-like character
• 4 bits: things like registers; auxiliary operands; also, addressing into 16-bit fields; anything for which 16 bits is (64k choices) is way overkill
• 16 bits: anything that won't fit in 4 bits, but which must be directly encoded into instructions

note that, in order to capture enough 'basis sets of primitives' to preserve intent across various computation paradigms, we want more than 16 opcodes. So, according to the above scheme (which conspicuously omits 8 bits/256), we should have the opcode field be 16 bits. Note that this gives us room for 'custom opcodes', and for using custom opcodes for subroutines, Forth-like.

PL book: Stack Machines