OSDev.org

Well I was thinking about languages and intermediate bytecode for a backend...

Well the problem with compiling to an actual executable bytecode and then to machine code is there is no real way to specify some an opcode doesn't exist on the physical machine..

Like take the Z80 for example. It lacks division and multiplication. Leaving the mul and div instruciton out of the bytecode will obviously suck for things like x86.. but application may want to be notified if their mul and div instructions are really just being emulated(and therefore, not optimal) and they may wish to replace such mul and div instructions with their own optimized code to use simpler opcodes which may be optimal for their machine or have a negligible lack of precision for their specific application.

This is of course designed as yet another attempt at portable machine code.. but also to be used along side a language I'm designing where the entire language can be defined however you like.

Any comments on this approach?

earlz wrote:Like take the Z80 for example. It lacks division and multiplication. Leaving the mul and div instruciton out of the bytecode will obviously suck for things like x86.. but application may want to be notified if their mul and div instructions are really just being emulated(and therefore, not optimal) and they may wish to replace such mul and div instructions with their own optimized code to use simpler opcodes which may be optimal for their machine or have a negligible lack of precision for their specific application.

I don't think an application needs to know anything about what exists on the actual CPU, and it shouldn't need to replace instructions for more "optimized code". The bytecode is already optimized if it uses the mul and div, as your recompiler ought to know that the target machine code doesn't have mul and div and output the best instruction sequence it can, right?

(I'm really tired right now, so take the above with a grain of salt! )

Well.. more real-life example.

Your making a game that relies on decimal numbers. If the machine has floating point numbers, you'll use those. If it doesn't, you'll use a less precise fixed-point number system..

If you want bytecode application make aware of precision then you can have bytecode instruction that acts as a function and returns precision, or some special purpose register that contains number of digits after the point.

If machine doesn't have floating point but application wants it then the app examines the register and decides what to do on its own.

earlz wrote:Well.. more real-life example.

Your making a game that relies on decimal numbers. If the machine has floating point numbers, you'll use those. If it doesn't, you'll use a less precise fixed-point number system..

The byte code doesnt have to map 1:1 to processor instructions. As Hangin10 was pointing out the recompiler generates the appropriate set of instructions to achieve the desired result. If the target doesn't have native floating point operations the recompiler should generate the approprate instructions to emulate it or have an approprate emulation library.

earlz wrote:Well.. more real-life example.

Your making a game that relies on decimal numbers. If the machine has floating point numbers, you'll use those. If it doesn't, you'll use a less precise fixed-point number system..

You could also have bytecode that is conditionally compiled, depending on whether floating point numbers are implemented on the platform or not. Continuing your game example, you could have two implementations of vectors, one that uses floating point, and one that uses fixed point math. But tbh, I doubt the same code would be run on both embedded platforms where lack of an FPU is common, and platforms like the x86.

If the target doesn't have native floating point operations the recompiler should generate the approprate instructions to emulate it or have an approprate emulation library.

This is probably the easiest and best way to do it, since it requires minimal effort from the programmer and provides the best performance possible.

If the target doesn't have native floating point operations the recompiler should generate the approprate instructions to emulate it or have an approprate emulation library.

This is probably the easiest and best way to do it, since it requires minimal effort from the programmer and provides the best performance possible.

It provides best performance possible while requiring minimum effort from programmer.

geppyfx wrote:

If the target doesn't have native floating point operations the recompiler should generate the approprate instructions to emulate it or have an approprate emulation library.

This is probably the easiest and best way to do it, since it requires minimal effort from the programmer and provides the best performance possible.

It provides best performance possible while requiring minimum effort from programmer.

I'm pretty sure I've heard that before somewhere...
But yeah, that is probably the order of the priorities in most applications.

Devil's advocate here.
If you want a game to run on hardware that is crappy enough to not have floats, and give it more overhead by adding a bytecode step. Then the game must be non-demanding enough that just emulating floats isn't a performance problem anyway.

And that the difference between floats and fixeds is bg enough that you will never support properly both with one code path.