Re: How to implement dynamic typing?

"BGB" <cr88192@hotmail.com> wrote in message
> "bartc" <bartc@freeuk.com> wrote
>> Mike Pall wrote:
>>
>>> The following post shows the assembler code for a dynamic type check
>>> (in the context of the interpreter part of LuaJIT):


>> 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)
>
> oddly enough, my compilers tend to just split apart the += operation:
> "x+=1;" is internally compiled as "x=x+1;"


(These += or +:= assignments are always troublesome)


Converting a+:=b to a:=a+b is what I used to do in one compiler (and a
complex 'a' expression was evaluated twice).


Now I generally do something like:


ptemp:=&a
ptemp^ +:= b # or *ptemp = b in C-speak


but more efficiently than that looks (ptemp stays in a register). And for
very simple 'a' expressions, it can deal with a+:=b directly.


> although, IIRC, complex expressions are handled specially in the LHS,
> where
> most of the complex expression is handled, but then 'dup' is used to split
> it at the final stage, then it is evaluated into its lvalue and rvalue
> sides
> are evaluated and the value is assigned.
>
> ex: "Foo.bar[3].baz+=3;".
> "Foo.bar[3]" would be evaluated and dup'ed ('.' has a different operation
> for lvalues and rvalues).


And that probably sounds like the same trick.


>('.' has a different operation for lvalues and rvalues).


I use four kinds of l-value expressions:


1. Direct memory a:=b
2. Pointer a^:=b
3. Index a[i]:=b
4. Dot a.i:=b


However complex the lhs, it always boils down to one of these, unless
there's something I've missed out.


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


Yeah. But, then, in a:=b+c, these checks come down to 4 instructions of
overhead, when the type of a,b,c is simple (two cmp, and two jumps).


I will play around with GC later, for user-level allocated memory (ie.
explicit use of pointers). Introducing it for this behind-the-scenes stuff
is more tricky, if I want the language to work the same way (ie. variables
never share their data with each other, and everything is mutable).


> nevermind, my float28 format (used on x86, x86-64 uses float48) has poor
> accuracy (still better than float24, which was my original "flonum"
> format).


(What do you do with the other 4 bits?)


--
Bartc

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