ByteCode Executor
lozinski
Posts: 76
in Propeller 2
In your sales literature you mention a ByteCode Executor. But I cannot find much information about it anywhere. There is this piece, but it does not give me a clean interface.
https://forums.parallax.com/discussion/comment/1407855#Comment_1407855
Could someone please point me to the documentation? Is this just a different name for the Spin Interpreter?
Thanks
Chris
Comments
Search in the GOOGLE docs for XBYTE. There is a small example of how to use it.
The basic prinzip it does is to read in the byte code jump thru a Vector table in LUT and do a RET to start the process again.
The inner loop using XBYTE/RET is quite fast. It is used by the SPIN2 interpreter but you can use it to build your own bytecode interpreter also. Say for a Z80 emulator or the 8080 used in the upcoming Arcade game console running 8 8-bit Arcade games at the same time from one P2.
The source for the Spin2-interpreter is available, not sure if @Baggers has the source for the 8080 (8086?) emulator available right now, it is a work in progress.
But be aware that @chip wrote both emulators, so the source is hard to read,
Enjoy!
Mike
Thank you.
Here is the documentation.
https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/export?format=pdf
Here is another discussion thread on the topic.
https://forums.parallax.com/discussion/171206/xbyte-and-hardware-stack
It will takes some time to fully understand it. Hardware engineers really do think differently from software engineers. I never met something like skipf before. I have a lot to learn.
Chris
Yeah the skip thing is another brilliant part, but not directly connected to the XBYTE cmd.
so one can use one without the other...
Mike
From the documentation.
https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/export?format=pdf
BYTECODE EXECUTION LOOKUP TABLE
(to be completed.)
If someone would be so kind as to complete that it would be most appreciated. If not, I will learn to read and understand this assembler, and write the documentation. In any case I need to learn to read the assembler.
Thank you for complimenting skipf. Often just discussing things stretches the mind. I was quite clueless about skipf. Now maybe I understand it. We really want multiple processors to be able to access the same data. So a round robin solution is great. Then we need a FIFO buffer, but we still want to reduce branches. Skipf does that. One can skip parts, rather than branch, rather than have multiple copies of similar code. And still get the benefit of a large fifo buffer.
All very interesting.
SKIPF has a few quirks. If the code is running in COG or LUT, then not only are the instructions skipped, but there is no clock penalty for those instructions being skipped, up to a run of 7 or 8 (I forget), then there is a 2 clock penalty and the no penalty skipping continues. However, if the code is running from hub then each instruction skipped takes 2 clocks.
If you want to see some other skip examples then my Z80 interpreter uses it too. It's not finished and at present I am not using xbyte.
https://forums.parallax.com/discussion/comment/1512317/#Comment_1512317
You may also find some good tips here
https://forums.parallax.com/discussion/comment/1512317/#Comment_1512317
Here is another link to the doc:
https://docs.google.com/document/d/1gn6oaT5Ib7CytvlZHacmrSbVBJsD9t_-kmvjd7nUR6o/export?format=pdf
As shown on page 27, XBYTE does RFBYTE,PA + GETPTR PB + RDLUT temp,PA + EXECF temp automatically whenever RET or _ RET _ executes with $1FF on the top of the hardware stack (TOS). EXECF = JMP + SKIPF.
XBYTE saves code and cycles, for example _ RET _ adds no time to the instruction it precedes when TOS = $1FF. However, XBYTE uses the FIFO (with RFBYTE) and you might prefer to use SKIPF and EXECF but not XBYTE if you want the FIFO available for some other purpose, such as the streamer.
SKIPF is a wonderful innovation on the P2 and I suggest learning about that and EXECF first, then XBYTE will be quite simple.
You had posted earlier on the micropython thread, so just to make sure your hopes aren't too high: XBYTE is wonderful for running simple bytecode like the Spin interpreter, or for CPU emulation of 8 bit systems. But it would be of very little value for python bytecode, or any other dynamically typed language (like JavaScript), because the instruction dispatch depends on the data types at run time. XBYTE would save a little bit of time in instruction decode, but the vast majority of the time in a python bytecode interpreter is spent elsewhere.
WOW. Thank you. Great guidance.
I am still learning.
In order to even understand the XBYTE stuff, I need to understand P2 Assembly.
So today i was reading that.