lightning
[Top][All Lists]
Advanced

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

Re: [Lightning] Stack register control?


From: Sandro Magi
Subject: Re: [Lightning] Stack register control?
Date: Fri, 28 Sep 2007 12:32:29 -0400

On 9/27/07, Robert Bedichek <address@hidden> wrote:
>
> Sandro,
>
> My code runs inside a Linux process.  I need to have a valid stack pointer at 
> all times, in case I get a signal.  It also helps with debugging.  And I make 
> calls frequently enough that I would probably lose if I saved and restored 
> the ESP register for every call.

I wasn't considering saving the register at all. For instance, SML/NJ
is compiled into continuation-passing style (CPS) in which all stack
frames are heap-allocated, and the stack register is thus freed for
use as a general register. I'm considering the same approach.

Consider also lightweight-threading/processes, like userspace threads
and Erlang language processes, in which either CPS form or stack
switching is quite common. I also wondered why userspace thread
packages don't use GNU Lightning as a portable backend.

Your point about signals is well-taken though. I will have to read up
a bit more on signal handling.

> My target is an x86 and modern x86's can do loads and stores very quickly, 
> usually two per cycle with very low latency to the the first level of memory 
> hierarchy.  Some code is faster on some x86 processors when rewritten to use 
> memory rather than registers for some of their operands.  This is due to 
> scheduling rules and resource conflicts (your loop might be maxed out in 
> register accesses but have spare mem slots). I know that sounds crazy, but 
> true.  I can't give you a specific example, sorry.  But the point is, memory 
> is not such a bad place to have operands on an x86 host.

Perhaps not, but other targets may be a concern. Interesting tidbit
about maxing out register accesses; is this is related to a hardware
limit on instruction level parallelism?

In any case, LLVM and GNU Lightning seem like the only two viable
options. While LLVM has quite a few advantages, including opimizers,
register allocation, more code backends, etc., I'm not sure I can get
the level of control over resources I need (such as GCing generated
code). I believe the control I need is achievable in Lightning, with
the added benefits that code generation is much faster and Lightning's
small size is very cache-friendly.

Does anyone have any experience with Lightning's code generation speed
and quality as compared to LLVM's?

Thanks for the comments everyone! :-)

Sandro




reply via email to

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