Re: Lua string library partially reimplemented in Lua

["Mark Meijer" <meijer78@...>]

This may seem like a weird question... but is it actually necessary
for a variable used as a field of bits, to have a valid representation
as a (lua)number, and to be able to convert between the two? In other
words, what exactly justifies treating a bit field as a number, or a
number as a bit field? Especially if the value of a bit field (when
interpreted as an integer datatype - which could be considered an
implicit cast) has a different representation from the same value as a
lua number (i.e. usually a double).

Perhaps bit fields should be treated more as an opaque "type", only
allowing operations to set and clear specific bits by means of the
usual bitwise operators. This may be limiting in some ways, but it
probably also means much simpler semantics, and no unnecessary
conversion issues.

I'm not saying it should be this way or that way, it's just a thought.

Cheers


2008/9/20 Mike Pall <mikelu-0809@mike.de>:
> Alex Davies wrote:
>> Mike Pall wrote:
>>> Since Lua doesn't have a standard bit manipulation library (yet),
>>> I took the liberty to define its semantics:
>>
>> Much needed addition. And I like the rules, can see how they can provide
>> for efficient optimizations, but may I ask why it's necessary to make
>> non-integral numbers behave in an implementation defined behaviour on
>> modern processors? (Is it to allow for more algebraic simplifications?)
>
> Well, truncation would make the most sense. But this is not the
> default rounding mode, and flipping it all the time can be quite
> expensive.
>
> There's another difficulty: the double -> 32 bit int conversions
> return 0x80000000 for values out of range and cannot be used. But
> the conversion to 64 bit ints is only available for x87 and not
> for SSE2 (except in x64 mode).
>
> So I have to use the 2^52 + 2^51 biasing trick for SSE2. But
> changing the SSE rounding mode is very expensive. And roundsd
> (with selectable rounding modes) is only available starting with
> SSE4.1 (45nm Core2). Ah, the joys of the x86 instruction set. :-|
>
> Also thinking ahead about implementations for non-x86 machines,
> it's probably best to leave the behaviour of bit operations for
> non-integral numbers implementation-defined.
>
> BTW: the JavaScript guys now have a big problem because the
> official spec defined some very rigid rules for conversions to
> integers. Trying to conform _and_ make this fast proves to be a
> challenge.
>
> --Mike
>