Closed erkyrath closed 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.
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 .
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.
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.
A good point: test added by commit 38f6e378c5c958bca7063e8e4e98699e04cbedbc.
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.