JIT for XMOS

[Folknology]

@octal I would probably add your weight to this thread https://www.xcore.com/forum/viewtopic.php?f=5&t=9

Jonathan, I and others have been asking these questions for a while, Xmos just aren't responding to them.

regards
Al

[octal]

@octal what sort of data rate do you need to keep feeding the XZPU without stalling?

regards
Al

I didn't timed it yet. I only implemented the virtual machine (to execute the ZPU bytecode).
I need to check the execution of each instruction correctly (I already implemented debug stuff to trace everything), and I'll need to add memory management routines and RTL.

Actually the ZPU is executed within a single thread. ZPU executes from a single thread (so multiple zpu can be instanciated each corresponding to a new thread).

Memory management routines does read and write operations. I made them independent of the rest of the code, this way, I can now implement multiple kinds of executions:
1- Either a ZPU executes loads code from UART or SPI Flash or SPI RAM, .... and use internal RAM for the STACK
2- The ZPU executes code from an external RAM (and use it for STACK if internal RAM is insufficient)
3- The ZPU thread, using com chanels, uses another thread () that will be responsible of Reading/Writing data (either from an external SPI RAM, Flash, UART, ...).

this way, users can have complete control over the way the ZPU will be used.

I need see how we can implement the ZPU (maybe via simple RTL functions) in order to permit synchonisation and data exchange between multipl ZPUs running in different threads. This will be nice to synchronize and data exchange between multiple ZPUs running on different chips and communicating via XLINKS.

[octal]

@octal I would probably add your weight to this thread https://www.xcore.com/forum/viewtopic.php?f=5&t=9

Jonathan, I and others have been asking these questions for a while, Xmos just aren't responding to them.

regards
Al

Amazing !
maybe this is because actual GCC version that XC depends on has not been fully ported to LLVM.

Anyway, this does not prevent from making an OCCAM native compiler :mrgreen: altought it would be a long time (and surely not a single person) project. If I can find someone with deep knowlege (experience) with XMOS asm, I can start somework on that.

[Folknology]

An interesting model for Amino might also be :

Internal RAM for the STACK and DATA, along with optional code via other thread or even Ethernet for Amino

regards
Al

[octal]

Folknology,
On ZPU everything is on STACK !!!

Initially I had been interrested in ZPU for ARM/PIC32. I wanted to provide ethernet connected boards for customers. The boards have to read simple sensors and activate some external additional boards. The idea is that the customer have a web based dashboard where he does use widgets, each widget let him control the main board and the additionnal boards behaviour.
I stoped work when I got at updating the main board firmware. If I lock the main board, I have noway to reflash it, unless I add an intelligent bootloader that will check the CRC or the firmware and that have a default base firmware on an onboard memory/flash/MicroSD.
With ZPU, the solution is very good, because for webbased controlled boards, ZPU execution is very fast (more than can be handled by the connection to the server). ZPU virtual machine is very simple and its implementation can be checked 100% by hand.
So this moves the problem to only having a very well tested ZPU implementation on the main board. Later, I can have full control on program execution, on its updates, on uploading modules through web (enhancing the RTL part only), ....
having a GCC implementation for ZPU makes things really easy, as I can implement anything with normal C, test it on PC and generate ZPU bytecode directly. This really makes things very easy.

When I first saw your project AMINO, I smiled a lot ... it's almost 100% what I want to do, but YOU want to do it with native code uploading, which makes things a bit difficult, as you can garantee (easily) that your system will never hang.

With ZPU the system WILL NEVER HANG as we can add to the virtual machine implementation a parametric section where we can implement some guards (like a virtual WDT), and when a certain condition arise, we can simply dump the system state and restart the VM. The VM can even have executions steps that it traces somewhere and it can continue execution after anormal program abort or can try another execution path if available to avoid reset condition.
In any case, your REAL CUP will never hang, and thus no exeternal additional board and the main board will never be in a situation that may be dangerous for electronics or controlled devices (this of course does not mean that we should not implement such safety things in the electronic of additional boards themselves).

Regards

[Folknology]

When I first saw your project AMINO, I smiled a lot ... it's almost 100% what I want to do, but YOU want to do it with native code uploading, which makes things a bit difficult, as you can garantee (easily) that your system will never hang.

On a number of the more resilient Amino designs such hanging is catered for by means of a watchdog and similar mechanisms, in some of the designs they could even hardware reset.

regards
Al

[ale500]

Lots of ideas... I definitely have to code some of them :) :mrgreen:

[octal]

Lots of ideas... I definitely have to code some of them :) :mrgreen:

XZPU code will be free and available on GIT very soon :)

[ale500]

I have to try this XZPU code myself. I neglected all Propeller implementation due to lack of time... but I think I'll give it a try.

For the time being I'm thinking on some JIT ideas... I want to use two threads for execution and fetch... I think the ZPU would be a good start due to the small number of opcodes involved...

Hei Octal can we get hold of that nice disassembler ?

[octal]

Hei Octal can we get hold of that nice disassembler ?

Hi ale500,
I'll post the code (time permitting) this weekend (for XZPU and for the disasm).
If you need the disasm urgently, let me know which OS version you want and I'll compile it to you. It's written in C++/QT, and tested to work under Win and Mac/OSX, I can test under Linux if you want.

Edit:
Well I attached binary of the pre-version of ZPU disassembler for Windows.

Full sources will be uploaded to GIT with XZPU sources.