A Spin JIT?

tom66

Is there a Spin JIT (just-in-time compiler) or a program to convert Spin to optimized assembly code? I imagine if instructions like waitcnt wouldn't take 341 instructions to execute if they were directly compiled as assembly...

I might write a basic one, but it would need knowledge of the Spin bytecode.

heater

Problem is your resulting PASM binary will have to fit within the COG execution space of 496 longs.

Most people would consider it not worth the effort to create a compiler for a system with such a sever limitation although I believe someone has a BASIC compiler that compiles to PASM now.

By the way, isn't the idea of JIT compiler that it converts byte codes to native assembler on the fly at run time? You might be severely pushed to find the resources in the Prop to do that.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Humanoido

Yes. I found one in my language research.
You can google it or if I find it again, will post
the url.

humanoido

tom66

It'd be like a JIT compiler, but since the Prop code doesn't change until another upload to the EEPROM, it can be JIT-compiled before upload, on a computer with a lot of power.

But that 496 instruction limitation would be a big bottleneck. It'd need some kind of way to run the programs from the main RAM.

BradC

tom66 said...
It'd be like a JIT compiler, but since the Prop code doesn't change until another upload to the EEPROM, it can be JIT-compiled before upload, on a computer with a lot of power.

But that 496 instruction limitation would be a big bottleneck. It'd need some kind of way to run the programs from the main RAM.

Sounds like what you want is one of the C compilers.
Biggest problem with that is while it runs much faster (not as fast as native PASM in the cog however), it is 3-4x larger. It's a tradeoff really.

You would not need heaps of power to do it, just a nicely written compiler.

Upsides :
- Faster code execution than native Spin

Downsides :
- Slower than native PASM by quite a bit
- 3-4x larger than native Spin


Why did you want to do it again?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

tom66

Programming exercise, but also just an idea.

MagIO2

To convert a SPIN program to optimized PASM code is of course possible. But not as a JIT compiler. Optimizing code needs a lot of knowledge that is packed into a module called Optimizer. Why should such an Optimizer be run on the target system with it's limitations instead of running on the PC?

496 longs of COG RAM means that you have max. 496 PASM instructions for your program. You mentioned waitcnt ... That's a very exceptional SPIN instruction, as it directly can be converted to a PASM instruction. But you have others that can't be translated so easy.
For example:
outa[noparse][[/noparse]8..15] := data

This code compiled into SPIN-bytecode just eats a few bytes. Try that in PASM! You will see that the same functionality in PASM eats up some LONGs. So, the number of SPIN instructions compiled into a COG will be much less than 496. So, what algorithm do you want to implement with that?

From my point of view SPIN/PASM -as it is- is the ideal combination for this microcontroller.

You want waitcnt in PASM? Then use PASM!

Bean

heater said...
Problem is your resulting PASM binary will have to fit within the COG execution space of 496 longs.

Most people would consider it not worth the effort to create a compiler for a system with such a sever limitation although I believe someone has a BASIC compiler that compiles to PASM now.

By the way, isn't the idea of JIT compiler that it converts byte codes to native assembler on the fly at run time? You might be severely pushed to find the resources in the Prop to do that.

Yes, I am working on a PropBASIC compiler that works much like the SX/B language for the SX microcontroller.
The thread is here http://forums.parallax.com/showthread.php?p=835500
Right now it compiles to PASM, but eventually we want it to generate LMM code to get passed the 496 instruction limit.

Bean


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Does that byte of memory hold "A", 65, $41 or %01000001 ?
Yes it does...


·

kwinn

tom66, the propeller tool will compile and download a program to the propeller in a few seconds so as far as I am concerned it pretty much is a JIT compiler. I have to agree with MagIO2's statement "From my point of view SPIN/PASM -as it is- is the ideal combination for this microcontroller."

If you want a programming exercise why not write some useful SPIN/PASM objects and put them in the OBEX. I am sure the folks on this forum would provide a lot of suggestions if you had trouble coming up with an idea for an object.

BradC

tom66 said...
Programming exercise, but also just an idea.

Ahh, that sounds like the best reason to do it.

I reckon the way to tackle it is in a linear fashion. Read the interpreter from end to end, and just create a little code generator for each bytecode.

To start with you could to what Bean is doing and just generate straight cog code (limited by the cog size of course), and then move to LMM later as you get the hang of it.

The interpreter source is basically the definitive documentation on how the spin bytecodes work. It's logical and easy to understand to follow through. Practically self documenting [noparse]:)[/noparse]

Anything you are unsure of, you can always ask. There are numerous people who know then ins and outs of the bytecode.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
If you always do what you always did, you always get what you always got.

photomankc

I'd love to see a SPIN ---> PASM compiler. Even if it was completely limited to cog code. This would make it a lot easier for me to get started with PASM. I could optimize later as I got better but a good starting point would be nice for simple loops that I'd like to speed up in a cog.

kwinn

photomankc has a pretty good idea. Even a preprocessor that converted Spin to PASM would be good, particularly if it had the spin statement as a comment and the PASM code following it. Good learning aid.

ericball

photomankc said...
I'd love to see a SPIN ---> PASM compiler. Even if it was completely limited to cog code. This would make it a lot easier for me to get started with PASM. I could optimize later as I got better but a good starting point would be nice for simple loops that I'd like to speed up in a cog.

The problem with this approach is SPIN uses HUB RAM for almost everything, while the focus in PASM is to try to keep stuff in COG RAM. So I don't think a SPIN -> PASM compiler based on the SPIN interpreter would be a good starting point.

I understand the transition from HLL to assembly is a big one. It really is about breaking down tasks into the operations the processor supports.

Let me give a quick example. The Propeller has no multiply instruction. So say you need to multiply two unsigned values together. In PASM all registers are 32 bits, and I'm going to assume the inputs and the result is 32 bits or less. So let's go back to basic math and put together a multiply algorithm using shifts, adds and logical operations. First express the algorithm in HLL pseudo code.

result = 0 
while arg1 > 0 
 if arg1 & 1 then result += arg2 
 arg1 >>= 1 
 arg2 <<= 1 
wend

Now I'm going to translate that algorithm to PASM. (Yes, this isn't the most efficient algorithm, it's just an example.)

DAT
		MOV	result, #0		' result = 0
loop		CMP	arg1, #0	wz	' while arg1 > 0
	if_z	JMP	exit
		TEST	arg1, #1	wc	' if arg1 & 1 then result += arg2
	if_c	ADD	result, arg2
		SHR	arg1, #1		' arg1 >>= 1
		SHL	arg2, #1		' arg2 <<= 1
		JMP	#loop			' wend
exit

Okay, I have a working algorithm. It's not perfect, but it will do the job quite nicely. But note I just took each HLL statement and broke it down into PASM operations.

Class dismissed. Your homework is to optimize the PASM code without searching the forums for the answer.