DavidKinder / Git

Fast Glulx interpreter, originally written by Iain Merrick.
MIT License
45 stars 13 forks source link

Double-precision opcodes #17

Closed erkyrath closed 2 years ago

erkyrath commented 2 years ago

This is pretty much the same as the code in glulxe. Except that ENCODE_DOUBLE() and DECODE_DOUBLE() do all their conversion by fast reinterpret-casting rather than math and bit-twiddling. (Following the example of ENCODE_FLOAT() and DECODE_FLOAT().)

opcode.h and opcode.c had some stray ^M characters, which I cleaned up in the course of adding this stuff.

I have tested this on Intel and ARM. I have not tested it on any big-endian architecture. Nasty surprises may occur.

DavidKinder commented 2 years ago

I'm a bit dubious about ENCODE_DOUBLE and DECODE_DOUBLE, and whether it's possible to get the encoding and decoding right on big-endian systems with memcpy(). I need to do a bit of experimentation before pulling this.

erkyrath commented 2 years ago

That's fair. If you don't want to use the dirty-cast versions, lift the safe-but-slower implementations from https://github.com/erkyrath/glulxe/blob/master/float.c .

DavidKinder commented 2 years ago

Testing on an emulated 68030 based system indicates that the dirty-cast way of encoding and decoding doubles will work on big endian systems (at least for systems using a standard representation of a double) provided that the low and high parts of the Glulx representation of the doubles are flipped round relative to little endian.

Commit 039f16f29af2fc37d4323b1ec4e8ebc97c35fc26 adds a config macro USE_BIG_ENDIAN and code that should do the right thing, probably.

erkyrath commented 2 years ago

You might want to do a test at startup time that verifies that the functions are encoding correctly. Otherwise people won't know they've compiled wrong until they run a game with double math.

DavidKinder commented 2 years ago

A good point: test added by commit 38f6e378c5c958bca7063e8e4e98699e04cbedbc.