towards a P2 Virtual Machine using XBYTE and Subsystems
This is some experiment exploring possibilities of P2.
Overall goal is a self contained system like Taqoz with SD card using PC with Teraterm as terminal.
One aspect is about the virtual machine: I asked myself, what would be the most "natural way" to implement a dual stack machine (Yes, my implementation shall run Forth, once more) on P2? So, yes we have two index registers PTRA + PTRB for the stacks, but how about the program counter?
Well, why not try XBYTE, which has it's hidden PC, promises to give a fast interpreter and uses the microcache of the streamer.
Downside is, that you can only use XBYTE, if you dedicate it's cog to pure assembler.
XBYTE is new for me and I will have to learn much here. I will start a link-list in the next post about XBYTE.
So, if we want to use libraries from FlexProp or write some code in C, we have to have "intelligent" Subsystems in other Cogs. The question is, if this can be turned into a the benefit of overall throughput. After all it has not been too easy for me to make good use of additional COGs in the past. So at the moment, the idea is something like this:
COG0: Compiler, runs C code, compiles Forth to Bytecode
COG1: Serial buffered input
COG2: Console buffered output (?? process decimal output, string output ??)
COG3: SD Driver (?? with read ahead and write caching ??)
COG4: XBYTE Machine executing Bytecode
COG5, COG6: Spare XBYTE Machines executing Bytecode
COG7: VGA tile driver
I would be interested in your thoughts about such "intelligent subsystems". What is really helpful?
Christof
Comments
Link List about XBYTE
Propeller P2 assembler instructions:
https://docs.google.com/spreadsheets/d/1_vJk-Ad569UMwgXTKTdfJkHYHpc1rZwxB-DcIiAZNdk/edit#gid=0
Incomplete Assembler Manual:
https://docs.google.com/document/d/1rQ_2FPLebT9GL6cZxgwHFbqxO9Kh9SfO6yn9gGTT6EE/edit
P2 Docu:
https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/edit
Obex:
https://obex.parallax.com/
@Wuerfel_21 's P2 Instructions Docu:
https://p2docs.github.io/
About XBYTE Zylin ZPU:
https://forums.parallax.com/discussion/166563/zpu-and-riscv-emulation-for-p2-now-with-xbyte
https://github.com/totalspectrum/zog/blob/master/zog_p2.spin
https://github.com/zylin/zpu/blob/master/zpu/docs/zpu_arch.html
Uses execf but not XBYTE:
https://forums.parallax.com/discussion/173342/6502-cpu-emulator/p1
https://forums.parallax.com/discussion/174344/p2-native-avr-cpu-emulation-with-external-memory-xbyte-etc/p1
Chips XBYTE machine:
https://forums.parallax.com/discussion/172813/p2-space-invaders-8080-emulation/p1
There must be some first discussion of XBYTE somewhere?
Other interesting links?
Do you need XBYTE? Catalina already has everything you need including the plugins you listed, apart from the Forth stuff. If you really do want Forth, there are Forth compilers written in ANSI C - e.g. https://gist.github.com/lbruder/10007431
Seriously, though - I have been giving some thought to adding an XBYTE back end for LCC (this would be similar to Catalina's COMPACT mode, except that COMPACT mode would still be useful because it also works on the P1). Fairly easy to do, and you then get all the other Catalina stuff thrown in for nothing.
If there would be any interest in such a thing, let me know. I've pretty much run out of things to add to Catalina, and Winter is Coming!
Thanks, Ross, for your comment. Though there seems to be some misunderstanding. I already have a Forth, written in C. https://forums.parallax.com/discussion/176167/p2ccforth-another-forth-written-in-c#latest And lbruder's version was one of it's sources of inspirations. A downside of P2CCForth is it's low speed in comparison to Taqoz and it's low code density.
So a Virtual Forth Machine written in PASM and using XBYTE might combine some good features?
Christof
you could try these AUGS instructions to use any stackpointer for your data stack. compiler needs to add AUGs before opcodes and in some cases add DUP/DROP before/after ... should be the fastest while still compact. use normal returnstack for 2nd stack. can play with _RET to produce tight code
No worries. I don't know or use Forth, but you triggered my interest by mentioning XBYTE. I looked at XBYTE a while ago and ruled it out for Catalina, but now I can't recall exactly why. I'll have another look.
Ross.
I've used XBYTE a lot.
Pros:
GETPTR
when PC required.Cons: