lightning
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Lightning] About using lightning on a dynamically typed language


From: Paulo César Pereira de Andrade
Subject: [Lightning] About using lightning on a dynamically typed language
Date: Sat, 15 May 2010 16:34:01 -0300
User-agent: SquirrelMail/1.4.19

  Hi,

  I am working on a dynamically typed C/C++ like language, that also
supports statically typed objects. You can see the code at:

https://code.google.com/p/exl/

  The language vm is currently implemented using computed gotos, and
I plan to add several "super instructions" to it to attempt to reduce
the cost of indirect jumps.

  But I would like to know what do you think about the difficulty of
generating jit for it. The main issues would be:

o Dynamically typed. The language vm has a single register, and operates
  on a stack, example of pseudo opcode pattern for expression "a += b;"
    lb a    ;; load value of variable a
    push    ;; put "implicit value" on top of vm stack
    lb b    ;; load value of variable b
    add     ;; add top of stack to "implicit value" and pop stack
    sb a    ;; store "implicit value" in a
o Non bignum integers are 64 bits; there is support for signed/unsigned
  integers from 8 to 64 bits, and 32 bit floats, but, they are coerced
  to int64/float64 when loaded as the "implicit value", and uint64 may
  be loaded as a mpz_t in a kind of multiple precision register.

  I understand that it may make it significantly hard to implement as
pure jit, but I was wondering how/if it could be made in a way where
it kind of "cut&paste" blocks of compiled code, and have it to choose
the next opcode in a way where it can tell in advance the processor
where it is jumping next; if you look in the code, you can see that
it sets a "register void *const *label" variable significantly before
jumping to the next instruction, but that doesn't help branch prediction,
and I don't know if I could somehow instruct gcc to generate code to
tell about it...

[the language doesn't have yet a defined name, it is also a kind of
hobby, doesn't have yet a defined usage either, it is "just for fun",
but it may get somewhere, "as is" currently, it averages 2 to 8 times
faster than python on generic "small" integer code]

Thanks,
Paulo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]