Re: How to implement dynamic typing?

On Wed, 21 Apr 2010 12:23:48 +0200, Mike Pall <mikelu-1004cc@mike.de>
wrote:


>George Neuner wrote:
>> On 14 Apr 2010 17:55:11 +0100 (BST), Tony Finch wrote:
>>
>> >[LuaJIT's] only numeric type is the double precision floating
>> >point number. It uses different kinds of NAN as tags for the
>> >other types ...
>
>[Also, none of the popular architectures would throw an exception on a
>NaN load. They only slow down when doing arithmetics with NaNs.]


More precisely, they won't throw an exception unless told to do so.
Lua itself can may up the FPU correctly, but possibly a call to
foreign code might leave the FPU in the wrong state. (I don't know
anything about Lua's FFI, so this is just speculation.)




>> Also the IEEE storage format for doubles leaves the tag in the
>> middle of the first word (the sign bit is first - NANs are encoded
>> in the exponent). That makes tag checking/extraction cumbersome on a
>> 32-bit machine.
>
>It's not necessary to extract the type tag from the middle. There are
>enough tags available in the range 0xfff80001 .. 0xffffffff. Using
>small signed numbers (e.g. -1 .. -12) allows shorter instruction
>encodings, too.


But that would not be different NANs.




>The following post shows the assembler code for a dynamic type check
>(in the context of the interpreter part of LuaJIT):
>
> http://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0
>
>The dynamic type check is very cheap on a super-scalar CPU as it's
>out of the dependency chain. I should mention the trace compiler
>can get rid of most of these type checks of course.


Assuming the code in the link is correct, then Tony's description of
the tag scheme (see top) is wrong. It appears that Lua does not use
"different kinds of NAN", but instead sets the exponent to one
particular NAN value and then stores tags in the upper mantissa bits.
Quite different.


This scheme sacrifices the entire first word of the double, so
non-double immediates have 100% overhead due to tagging.


George

Return to the comp.compilers page.
Search the comp.compilers archives again.