Fast Bytecode Interpreter

Comments

The _ret_ may be kludgy, but just 'ret' looks too understated, I think. All the conditions have underscores in them, so my eye expects to see an underscore in a prefix. I wish we could just use if_ret, but that don't make a lick of sense. I tried do_ret, but it looks weird. There is probably a better idea, but I don't have it.

NOP = 0000_0000000_000_000000000_000000000
ROR = eeee_0000000_czi_ddddddddd_sssssssss
But...
_RET_ ROR 0,0 will be treated as a NOP.
Any ROR with conditional (if_xxxx), ddddddddd <>0, sssssssss<>0, or #sssssssss will execute correctly. So it's only an extremely specific case which has no purpose that becomes a NOP. This case/exception could be flagged by the assembler.

However, what happens if this _RET_ ROR 0,0 is preceded by an AUGxx ???

... but I still find this simpler, less cluttered, and easier to read & edit.

djnz count,#loop
ret
'or
add r0,r1
ret

Identical binary code results.

PC's should be doing the housekeeping, so programmers do not have to.

And how will you write it if you want 2 instructions, an ADD and a RET ?
In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.
Both is here not possible without knowing how the assembler optimizes this code.

In Assembler you need to have control over every aspect of the generated code, you need to be able to count the cycles and the instruction count from the source.

Yup, completely agree about control - which is why the solution above exists.

Count the cycles ? - somewhat less so, as already the P2 stalls in various places, making that impossible.
If I really want cycles, I time the code in a real device, or use a simulator. I do not expect to be able to extract all the timing nuances from assembler source.

Instruction count ? - I already look at List files for that, because I commonly use Macros and conditionals in my ASM for other MCUs. Many P2 designers will do the same. (once the tools catch up)

So you never use macros then ?
Or include files ?
Or generic calls ?
Or conditional code ?

There are already many cases where any exact ASM source-line-to-bytes rule is broken.

Yep, bin there, done that.

At some point, when your program is big enough and complex enough to require macros and high level language features you start to ask yourself "Why am I doing all this?". It's time to just use a proper high level language.

With all that complexity added to PASM the user now has three languages to learn instead of two. Spin + PASM + all that asm meta-programming, rather than simply Spin + PASM.

Since the approach I suggest (which does get rid of the horribly ugly _underscores_) is not mutually exclusive, you are of course free to use the _ret_ form. A user taste choice.

I get the idea. It's just that now instructions as written may generate a variable number of actual instructions. Which makes all that instruction counting that people like to do on the Propeller, to get timing right, rather more difficult.

I have always campaigned for simplicity in the P2, but that boat seems to have sailed a long time ago.

I agree with the reasoning about RET being placed along with WC and WZ, after the instruction and operands, but it would be marooned way out there. I think this thing needs to go where the conditionals go, so that it jumps out in a consistent position. Otherwise, it gets lost in the noise.