1-byte NOP for vCPU

[gawater]

Quick question: I'm in need for a single byte vCPU NOP instruction. For 2 bytes I can do ORI 0, for 3 there's BCC "next_line" but for a single byte I didn't see anything obvious in the documented instruction set. So I thought might there be an undocumented single byte opcode that doesn't do anything aside from incrementing vPC? I tried some values without luck, but since I don't want to dive into the ROM code (yet), I thought I'd ask here first.
.

[at67]

All the one byte instructions modify vAC or the stack, I assume this is not good enough?

What do you need a NOP for?
1) Alignment of data?
2) Padding of data?
3) Alignment of code so that you can stitch two unrelated code segments together?

1) and 2) are not an issue on the Gigatron, 3) there is a better way to do it and that is to use a thunk to stitch them together, e.g.

ROMv5a/DevROM or higher, (preserves vAC)

Code: Select all

        ...
        ...
        CALLI    _next_segment
        

_next_segment
        <do_stuff>

All ROM's, (trashes vAC)

Code: Select all

        ...
        ...
        LDWI    _next_segment
        CALL    vAC
        

_next_segment
        <do_stuff>

All ROM's, (preserves vAC)

Code: Select all

        ...
        ...
        STW     _temp_
        LDWI    _next_segment
        CALL    vAC
        

_next_segment
        LDW     _temp_ 
        <do_stuff>

[gawater]

farjump.txt

(1.88 KiB) Downloaded 437 times

When coding in vCPU assembly I spend a lot of time on relocating code because of pagebreaks, and I was thinking of ways to avoid this headache. I added 7 far jump instructions, written as assembler macros: JMP address (far jump always), JMPcc address (far jump on condition, where cc = EQ, NE, etc. See attached include file.

Instead of 9 bytes (as in your last example) a thunk needs only 4 bytes, plus one call table entry, but the price is slower execution. Once the code is running I can optimize the gt1 file. Whenever there's a call to JMP, I check the high byte of the destination address. When it's equal to the current page number I replace the 4 byte JUMP instruction by the equivalent 2 byte BRA and leave the 2 address bytes be -- they will be jumped over anyway. The final result won't be as fast or compact as hand-allocated code or code produced by an optimizing compiler (such as yours), but I'm happy to pay that price...

However, when I similarly want to post-optimize conditional jumps, there's this snag. I have to replace the 4 byte JMPcc instruction by a 3 byte BCC instruction, and one byte remains that gets executed when the condition is not met. Ideally I want to put a single byte NOP in there. Anyway, if that doesn't exist, a possible (yet untested) work around is to append a zero byte to the JMPcc instructions, making them 5 bytes long so that I have 2 bytes left to fit an NOP (ORI 0 for instance) into.

Like this:

%MACRO JMPEQ target
CALL jmp_eq
DW target
DB 0
%ENDM

and change the ADDI 2 into ADDI 3 in the CONTINUE macro.

[at67]

Makes sense, unfortunately there is no vCPU NOP single byte instruction, you could do funky stuff with RET, PUSH or POP if you kept track of the stack/return address state, but that would probably be extremely inefficient in the long run.

https://github.com/kervinck/gigatron-ro ... ummary.txt