@RossH said:
However, I'm now looking at using it instead to build a bytecode interpreter for Lua. If I can do that it would make Lua absolutely fly on the P2, and make all other P2 languages look positively neanderthal!
+1 for languages on P2 XBTYE ... I think that might be what makes P2 stand out in the market. I'm not ready for the big reveal, but this is what I've been coding on for the past week.
@JonnyMac said:
I don't know if I understand XBYTE,
I don't know if I understand XBYTE either. But, of all the P2 projects I've started in the past few years, it seems like I've hit the bedrock beneath to build my foundation on. It is keeping my attention.
The easiest way to understand XBYTE is to compile and run the demo given in the P2 documentation. I have attached a slightly modified version below (I modified it to light up the LEDS on the P2 Evaluation board, which makes it very easy to see immediately the impact of any changes you make to the program - for example, I have added a waitx instruction to the PASM code at label r2, which is the code that implements the XBYTE code 2, and also to the code at label r4, which implements the XBYTE code 4).
'
' xbyte demo, modified to use default RCFAST clock (20Mhz) and the P2 Eval LEDs
'
dat org
drvh #56 ' otherwise they float!
drvh #57 ' otherwise they float!
drvh #58 ' otherwise they float!
drvh #59 ' otherwise they float!
setq2 #$FF 'load bytecode table into LUT $100..$1FF
rdlong $100,#bytetable
rdfast #0,#bytecodes 'init fifo read at start of bytecodes
push #$1FF 'push $1FF for xbyte
_ret_ setq #$100 'start xbyte with LUT base = $100, no stack pop
'
' Bytecode routines
'
r0 _ret_ drvnot #56 'toggle pin 56
r1 _ret_ drvnot #57 'toggle pin 57
r2 waitx ##10000000 'wait 1/2 second (@20mhz)
_ret_ drvnot #58 'toggle pin 58
r3 _ret_ drvnot #59 'toggle pin 59
r4 rfvars pa 'get offset
add pb,pa 'add offset
waitx ##10000000 'wait 1/2 second (@20mhz)
_ret_ rdfast #0,pb 'init fifo read at new address
'
tmp long 0
'
' Bytecodes that form the XBYTE program in hub
'
orgh
bytecodes byte 0 'toggle pin 56
byte 1 'toggle pin 57
byte 2 'toggle pin 58
byte 3 'toggle pin 59
byte 4,(bytecodes-$) & $7F 'relative branch, loop to bytecodes
'
' Bytecode EXECF data, moved into lut $100..$1FF (no SKIPF patterns are used in this example)
'
bytetable long r0 '#0 toggle pin 56
long r1 '#1 toggle pin 57
long r2 '#2 toggle pin 58
long r3 '#3 toggle pin 59
long r4 '#4 relative branch
If you save it as xbyte.pasm you can compile and run it using the following commands:
p2asm xbyte.pasm
payload xbyte
Then watch the LEDs! Note that the bytecodes table is the 5 byte XBYTE program that is being executed - the rest of the program is just set up.
@RossH said:
However, I'm now looking at using it instead to build a bytecode interpreter for Lua. If I can do that it would make Lua absolutely fly on the P2, and make all other P2 languages look positively neanderthal!
+1 for languages on P2 XBTYE ... I think that might be what makes P2 stand out in the market. I'm not ready for the big reveal, but this is what I've been coding on for the past week.
Interesting. I was also planning to implement the Lua interpreter across multiple cogs. It looks like your Lisp Engine will get there first, but that is entirely appropriate!
Comments
+1 for languages on P2 XBTYE ... I think that might be what makes P2 stand out in the market. I'm not ready for the big reveal, but this is what I've been coding on for the past week.
I don't know if I understand XBYTE, but am looking forward to seeing what you're doing so that I can learn from it.
I don't know if I understand XBYTE either.
But, of all the P2 projects I've started in the past few years, it seems like I've hit the bedrock beneath to build my foundation on. It is keeping my attention.
The easiest way to understand XBYTE is to compile and run the demo given in the P2 documentation. I have attached a slightly modified version below (I modified it to light up the LEDS on the P2 Evaluation board, which makes it very easy to see immediately the impact of any changes you make to the program - for example, I have added a waitx instruction to the PASM code at label r2, which is the code that implements the XBYTE code 2, and also to the code at label r4, which implements the XBYTE code 4).
' ' xbyte demo, modified to use default RCFAST clock (20Mhz) and the P2 Eval LEDs ' dat org drvh #56 ' otherwise they float! drvh #57 ' otherwise they float! drvh #58 ' otherwise they float! drvh #59 ' otherwise they float! setq2 #$FF 'load bytecode table into LUT $100..$1FF rdlong $100,#bytetable rdfast #0,#bytecodes 'init fifo read at start of bytecodes push #$1FF 'push $1FF for xbyte _ret_ setq #$100 'start xbyte with LUT base = $100, no stack pop ' ' Bytecode routines ' r0 _ret_ drvnot #56 'toggle pin 56 r1 _ret_ drvnot #57 'toggle pin 57 r2 waitx ##10000000 'wait 1/2 second (@20mhz) _ret_ drvnot #58 'toggle pin 58 r3 _ret_ drvnot #59 'toggle pin 59 r4 rfvars pa 'get offset add pb,pa 'add offset waitx ##10000000 'wait 1/2 second (@20mhz) _ret_ rdfast #0,pb 'init fifo read at new address ' tmp long 0 ' ' Bytecodes that form the XBYTE program in hub ' orgh bytecodes byte 0 'toggle pin 56 byte 1 'toggle pin 57 byte 2 'toggle pin 58 byte 3 'toggle pin 59 byte 4,(bytecodes-$) & $7F 'relative branch, loop to bytecodes ' ' Bytecode EXECF data, moved into lut $100..$1FF (no SKIPF patterns are used in this example) ' bytetable long r0 '#0 toggle pin 56 long r1 '#1 toggle pin 57 long r2 '#2 toggle pin 58 long r3 '#3 toggle pin 59 long r4 '#4 relative branchIf you save it as xbyte.pasm you can compile and run it using the following commands:
Then watch the LEDs! Note that the bytecodes table is the 5 byte XBYTE program that is being executed - the rest of the program is just set up.
Ross.
Interesting. I was also planning to implement the Lua interpreter across multiple cogs. It looks like your Lisp Engine will get there first, but that is entirely appropriate!