|[22 earlier articles]|
|Re: How to implement dynamic typing? email@example.com (George Neuner) (2010-04-20)|
|Re: How to implement dynamic typing? firstname.lastname@example.org (Mike Pall) (2010-04-21)|
|Re: How to implement dynamic typing? email@example.com (bartc) (2010-04-21)|
|Re: How to implement dynamic typing? firstname.lastname@example.org (George Neuner) (2010-04-22)|
|Re: How to implement dynamic typing? email@example.com (George Neuner) (2010-04-23)|
|Re: How to implement dynamic typing? firstname.lastname@example.org (BGB) (2010-04-23)|
|Re: How to implement dynamic typing? email@example.com (bartc) (2010-04-24)|
|Re: How to implement dynamic typing? firstname.lastname@example.org (BGB / cr88192) (2010-04-26)|
|Re: How to implement dynamic typing? email@example.com (George Neuner) (2010-05-11)|
|Date:||Sat, 24 Apr 2010 16:39:09 +0100|
|References:||10-04-009 10-04-028 10-04-031 10-04-036 10-04-038 10-04-051 10-04-053 10-04-054 10-04-065|
|Posted-Date:||26 Apr 2010 01:28:16 EDT|
"BGB" <firstname.lastname@example.org> wrote in message
> "bartc" <email@example.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^ +:= 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,
> 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
> are evaluated and the value is assigned.
> ex: "Foo.bar.baz+=3;".
> "Foo.bar" 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.
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"
(What do you do with the other 4 bits?)
Return to the
Search the comp.compilers archives again.