Funny Finding: Single Instruction Inline Assemblies for XBYTE

Christof Eb. · 2026-04-24 10:22

Kind of funny finding:
While experimenting with my little XBYTE machine and PASM, I discovered, that single instructions as inline assemblies make sense. The reasons are, that P2's instruction set is very rich and that in 32 bit there can be 9bit operands as well. For example you can code "ret shl tos,#2" (register tos=tos*4). To read the instruction from HUB RAM the streamer is still used, so that is fast.

So we start with a special XBYTE code "mexec", which loads the next long into a cog register and jumps to it there. It must contain "ret" to resume the xbyte machine.
Execution time for the instruction seems to be only 16 cycles.

 i_mexec                rflong data     ' get the instruction must contain _ret_
                        jmp #data

I love simple things! :-)
Have fun, Christof

cgracey · 2026-04-26 21:31

Right on!!!

For what you described, you could have it read the instruction into two registers ahead ($+2) and then get a free instruction slot that could be fixed. That would take two clocks less than the jmp would have.

You could do a double instruction with AUGS or something, too:

        rflong  .a
        rflong  .b
.a      nop               'becomes       AUGS
.b      nop               'becomes _RET_ INSTR

I love new discoveries like these.

TonyB_ · 2026-04-27 12:54

@cgracey said:
Right on!!!

For what you described, you could have it read the instruction into two registers ahead ($+2) and then get a free instruction slot that could be fixed. That would take two clocks less than the jmp would have.

You could do a double instruction with AUGS or something, too:
        rflong  .a
        rflong  .b
.a      nop               'becomes       AUGS
.b      nop               'becomes _RET_ INSTR
I love new discoveries like these.

Related info:
Storing tables for SKIPF or EXECF in hub RAM can enable an application that would never fit entirely in cog RAM. It is the best use I've found for no-wait RDFAST so far. My current project requires multiple tables of SKIPF and EXECF data (not instructions and no XBYTE):

        rflong  skipf_data
        skipf   skipf_data
        rflong  execf_data 
...
'skipf done
...
        execf   execf_data
...
skipf_data
execf_data      long    0

cgracey · 2026-04-28 03:08

@TonyB_ said:
@cgracey said:
Right on!!!

For what you described, you could have it read the instruction into two registers ahead ($+2) and then get a free instruction slot that could be fixed. That would take two clocks less than the jmp would have.

You could do a double instruction with AUGS or something, too:
        rflong  .a
        rflong  .b
.a      nop               'becomes       AUGS
.b      nop               'becomes _RET_ INSTR
I love new discoveries like these.
Related info:
Storing tables for SKIPF or EXECF in hub RAM can enable an application that would never fit entirely in cog RAM. It is the best use I've found for no-wait RDFAST so far. My current project requires multiple tables of SKIPF and EXECF data (not instructions and no XBYTE):
        rflong  skipf_data
        skipf   skipf_data
        rflong  execf_data 
...
'skipf done
...
        execf   execf_data
...
skipf_data
execf_data      long    0

That is hard for me to get my head around. I can imagine what it would do, but I can't figure the strategy. I'm trying to visualize code that could work efficiently like this.

Funny Finding: Single Instruction Inline Assemblies for XBYTE

Comments