ROM adventures (dev7rom)

[Phibrizzo]

Then, wouldn't it be simpler to add independent RTI instruction in newer version of ROMs?

BTW: why doesn't exist DEC instruction? (x--)

[lb3361]

Why no DEC instruction?

Having a DEC(b) instruction that runs as fast as INC(b) would take four precious bytes in page 3. Having a DECV(v) that runs as fast as INCV(v) would take two precious bytes in page 3. I have only four free bytes left in page 3 which I believe are best kept to organize a new page of opcodes in some distant future. Having instructions DEC(b) or DECV(b) using the prefix 0x35 would make them much slower and not very compelling when you can use SUBIV(1,v).

So the next question is what having INCV(v) at all? Turns out that this is used much more often than DECV would be.

In the LCC test suite:

Code: Select all

% grep INCV gigatron-lcc/gigatron/tst/*.sbk | wc -l
     142
% grep SUBIV gigatron-lcc/gigatron/tst/*.sbk | wc -l
      21
% grep ADDIV /gigatron-lcc/gigatron/tst/*.sbk | wc -l
      58

In the counts above, 19 out of 21 SUBIV instructions are SUBIV(1,...), but none of the ADDIV instructions are ADDIV(1,...) because the compiler would select INCV() instead.

[lb3361]

Latest changes:

• Added opcodes VSAVE and VRESTORE to save or restore a virtual interrupt context, and opcode EXCH to atomically exchange a byte. Together these instructions make it possible to implement preemptive multitasking. See viewtopic.php?t=463 and doc https://github.com/lb3361/gigatron-rom/ ... interrupts.
• Added opcode COPYS that copies data from a zero page address to the stack, or conversely, without changing vAC. This is documented at https://github.com/lb3361/gigatron-rom/ ... structions. Together with opcode ALLOC, opcode COPYS can be used to push/pop multiple values from the stack. This is particularly useful when a C function needs to preserve callee-saved registers in its prologue and to restore them in its epilogue, avoiding the need for a runtime subroutine.
• Added opcodes LOKEA/LEEKA that work for longs (4 bytes) like DOKEA/DEEKA for words (2 bytes) and PEEKA/POKEA for bytes. This is a minor optimization for programs dealing with long integers. For instance a single LOKEA(x) can replace the sequence DOKEA(x);ADDI(2);DOKEA(x+2). It takes three bytes instead of six and runs a little faster. Documented in https://github.com/lb3361/gigatron-rom/ ... arithmetic

[Phibrizzo]

Hello

I been watching latest doc of vCPU7 instructions and discovered that LEEKA and LOKEA have the same op codes #$3532.
What is correct?

[lb3361]

Hello

I been watching latest doc of vCPU7 instructions and discovered that LEEKA and LOKEA have the same op codes #$3532.
What is correct?

This was a documentation error. The opcode for LOKEA(XX) is 35 34 XX. The doc is now fixed.
I checked that the opcode was correct in Core/interface-dev.json, Utils/gt1dump.py, and gigatron-lcc/gigatron/mapsim/gtsim.c.
So this is just a documentation error with no additional consequences.