Re: How to implement dynamic typing?

Mike Pall wrote:




> 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


From that link:


>E.g. x=x+1 ...


>// Prologue for type ABC instructions (others have a zero prologue).
>movzx ebp, ah Decode RC (split of RD)
>movzx eax, al Decode RB (split of RD)


>// The instruction itself.
>cmp [edx+ebp*8+0x4], -13 Type check of [RB]
>ja ->lj_vmeta_arith_vn
>movsd xmm0, [edx+ebp*8] Load of [RB]
>addsd xmm0, [edi+eax*8] Add to [RC]
>movsd [edx+ecx*8], xmm0 Store in [RA]


(Why don't you need a type-check of [RC]?


>// Standard epilogue: decode + dispatch the next instruction.
>mov eax, [esi] Load next bytecode
>movzx ecx, ah Decode RA
>movzx ebp, al Decode opcode
>add esi, 0x4 Increment PC
>shr eax, 0x10 Decode RD
>jmp [ebx+ebp*4] Dispatch to next instruction


>Yes, that's all of it. I don't think you can do this with less
>instructions.


This is some code of mine from an old bytecode interpreter, for
++x, using tagged descriptors:


;the type-check
      mov eax,[ebx+4]
      cmp word [eax+kdtype],ti4
      jnz kincrm1


;the instruction
      inc dword [eax+kvalue]


;the epilogue (it can be done in 2-instructions, but it's slower)
      lea ebx,[ebx+8]
      mov eax,[ebx]
      jmp eax


Overall it wasn't particularly fast however. Actual x=x+1 instructions
are slow. And it's hampered by:


1) Having to do type checks for two operands (the compiler isn't
      clever enough to see x=x+1 needs just one check. But then, this
      tends to get written as x+:=1 or just ++x)


2) Continual checks for freeing and duplicating memory, as there is no
      GC to offload this stuff to.


I've just looked at something called LuaJIT 2.0.0, and it is pretty
impressive speedwise, also the fact that it seemed to be just two
smallish files (you get used to huge sprawling downloads).


Using "luajit -j off" runs it as a normal interpreter, if I understood
correctly, and slows it down enough to be able to actually measure
the execution times..


Anyway Luajit seems a new target to try and beat..


--
Bartc

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