Re: Compiling procedure/closure application natively
- From: "William D Clinger" <cesura17@xxxxxxxxx>
- Date: 30 Mar 2007 07:51:09 -0700
Andreas wrote:
Finally, my question is this: Was my encoding procedures as "address in
memory" without additional heap allocation a case of premature
optimization?
Yes. You can reconsider that optimization later.
What is the usual way this is done? I did have a look at larceny's
assembly output on x86 and it appeared to me to do a similar dispatch,
i.e. distinguish between closure and procedure at every call-site.
No. Larceny represents *all* procedures as closures.
The runtime checking you saw was probably for (1) global
variable references, to make sure the variable has been
given a value or (2) to make sure that the value being
called is a procedure, not a number or boolean or string
or whatever. (When calling a top-level procedure, the
peephole optimizer should combine checks (1) and (2),
but Larceny's x86 code generator is still pretty crude
and may not do that yet.)
Larceny's Twobit compiler also performs a first-order
closure analysis to identify procedures that are *only*
called (Aziz's first category). Those procedures don't
have to represented as values at all. In Larceny, their
code will be merged into the codevector for some other
procedure, making it hard for you to locate their code
when looking at the input to or output from the Sassy
or Nasm assemblers.
Will
.
- References:
- Prev by Date: Re: Why does delay need to be special?
- Next by Date: Re: how do I rewrite this simple macro so that r5rs compiler will compile.
- Previous by thread: Re: Compiling procedure/closure application natively
- Next by thread: Re: Compiling procedure/closure application natively
- Index(es):
Relevant Pages
|
