JIT for XMOS

[ale500]

I have been, since last year, thinking about doing a just-in-time compiler using at least two threads. The target assembler should be simple so XS-1 opcodes do sort of the same and I can test a couple of ideas I have. I should probably dig a bit more to see how multiple threads are used to solve this problem, I just did not wanted to dive into thousands of lines of code to find that a particular idea is not used. With that regard I think that a JIT for the ZPU processor maybe a good idea, I just do not know how repetitive small fragments of code are and which sweet spots should be used in terms of buffer sizes and so on.
Anyone has some thoughts on this ?

[Folknology]

Ooh that sounds like a good idea. Not sure about ZPU though. What would be really cool is for the JIT to support a new CSP language, I could certainly help out if that's of interest.

regards
Al

[ale500]

I really do not know that much about CSP and occam (for example) to steer in that direction. It would probably be a nice gateway into managing more memory :). It may be worth to dig a bit about this CSP beast, I'm sure the XMOS architecture is more than well suited to use it... wonder why ;-)

I was thinking in something more direct like... assembly to assembly.

[Folknology]

I get creating higher level langs and or scripting but I'm not sure what assembly to assembly is for, what are your intentions around this?

regards
Al

[ale500]

I'd love to run unix on the XMOS :). Maybe some early version, the one that fit into 32k would be a good candidate :). That needs more memory and well I thought that a coldfire to xmos JIT would sort of fit the bill. The assembly is not that big, there are no byte and word ops besides load and store, then it would fit without being a tight fit (meaning most memory is used for buffers and not to decode instructions).

What you propose could make more sense into the goal of more memory because the abstraction layer could mean that with ease more core can be tasked... interesting... it definitely needs more thought on my part...

[octal]

@ale500,
I'll post the XZPU (zpu implementation on XMOS) this weeknd if I could find enough time to cleanup code and test it. (check https://www.xcore.com/forum/viewtopic.php?f=14&t=1067 )

@Folknology
I really think that JIT and other such alternatives on XMOS is not a good solution for CSP. The best is to have a native OCCAM implementation (You ruined my life :mrgreen: )

[Folknology]

@octal did you see Jonathans thread - https://www.xcore.com/forum/viewtopic.php?f=29&t=1136

regards
Al

[Folknology]

@ale500 have you checked your SYS-X Link pinouts (on your board) by the way - https://www.xcore.com/forum/viewtopic.php?f=26&t=1134

regards
Al

[Folknology]

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

regards
Al

[octal]

Folknology,
I agree with Andrew's post, an LLVM front end would be the best solution, it let us have benefits from back end optimizations and from all available debug tools.

But for that, is the XC LLVM version fully working?