32-bit binary arithmetic

ID:1704209
 
Oct 21 2014, 9:41 pm
Keywords: binary, bitwise, math
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Since DM stores numbers in a 32-bit format, it's strange that it only offers 16-bit binary arithmetic.

This can probably be resolved either by allowing binary manipulation of the standard floats up to 32 bits width, or implementing an ushort (unsigned 16-bit integer) data type to reduce memory usage by bitfields and increase code clarity (note that I support doing this anyway).
Oct 26 2014, 7:20 pm
Technically floats support up to 24 bits. The mantissa is 23 bits, but that effectively gives it a 24-bit range. I've always been on the fence about changing it, because it could conceivably change existing games. On the other hand, I think that's highly unlikely.
Oct 26 2014, 8:42 pm
In response to Lummox JR
Lummox JR wrote:
Technically floats support up to 24 bits. The mantissa is 23 bits, but that effectively gives it a 24-bit range. I've always been on the fence about changing it, because it could conceivably change existing games. On the other hand, I think that's highly unlikely.

I say go with it. I'm sure there's benefits to having 24-bit flags over 16-bit. Another way about the current problem would be to create two variables which hold 16 bits each, but that doubles the size in memory (8 bytes instead of 4).
Oct 31 2014, 7:52 am
Yeah, i can't think of any existing code this would break.

Though I was thinking it'd be fine to allow manipulating all 32 bits, since I doubt anyone who wants to fiddle with the sign/exp of a float expects to have the engine hold their hand through the process.
And it's strange to waste those bits when saving every bit of memory is part of the fun of bit twiddling.
Oct 31 2014, 9:09 am
I don't think it even uses floats in the backend for binary operations. It is set to 16 bits because of legacy reasons where numbers would always be 16 bits. The backend most likely uses shorts.
Oct 31 2014, 5:15 pm
GatewayRa wrote:
mob/verb/Yo()
>     var x = ~0
>     src << "[x] is equal to 65535."

There, I just made code that'd be broken.
Note existing, there's obviously theoretical examples but I hope no existing project relies on code like that (though i wouldn't be surprised at this point).

GatewayRa wrote:
Can do what Javascript and Flash does, and make the default numeric type a double instead of a float, and with 53 bit accuracy 32-bit binary operations wouldn't be a problem.
That just shifts the issue upwards. This would be the same request, except with 64 bits instead of 32.
Oct 31 2014, 6:46 pm
I'm presuming if someone used ~0 they really wanted "The highest available bit" not "exactly 65535", so changing the value on them shouldn't be a dealbreaker.
Oct 31 2014, 7:00 pm
In response to MisterPerson
MisterPerson wrote:
I'm presuming if someone used ~0 they really wanted "The highest available bit" not "exactly 65535", so changing the value on them shouldn't be a dealbreaker.

This. You might do something like this (which is actually the first time I've used ~0 since I haven't needed to mess with bitflags much):
#define STATE_OFF 0

#define STATE_A 1
#define STATE_B 2
#define STATE_C 4
// ...
#define STATE_O (1<<15)

#define STATE_ALL ~0

To raise the limit in this case would give you a larger STATE_ALL, but games that didn't have any more than 16 flags (0 to 15, because they couldn't if they wanted to) wouldn't be broken. But, as I said, I haven't messed with bitflags much, I just know the basics of why you might want to use them and how.