[Openmcl-devel] how does one cause stack-allocation for floats?
Toomas.Altosaar at hut.fi
Wed Mar 29 14:57:51 UTC 2006
I've been listening in on the OpenMCL list and thought I'd put in my 2 cents.
At 05:25 -0700 29.03.2006, openmcl-devel-request at clozure.com wrote:
>would a smarter compiler - which was planning on keeping the result of
>that addition in an FP register - have any idea of why it's being told
>to put things in memory and take them back out (when, after all, that
>largely defeats the purpose of any analysis it has done) ?
But until that day dawns we won't run into this problem.
If such a smart compiler were to exist today I'd _gladly_ go through
my code and simplify things, removing lots of LAP and stack allocated
Great to hear that in your new 64 bit Lisp single precision floats
will be immediate objects. Too bad double precision is still consing.
What about a "slightly damaged" double float format, to the same tune
as MCL's non-consing short floats from 10+ years ago? So that the tag
plus most of what makes a double float could fit into 64 bits (BTW:
how big is a tag in the x86 64 bit version?)
>Perhaps more significantly, should users be encouraged to think of
>floats as being mutable objects and of exercising control over their
>allocation ? I think that there are lots of aesthetic reasons for
>saying "no", and the fact that this doesn't have much to do with
>really good code generation is a strong practical reason for doing
>so as well.
Having to allocate stuff temporarily on the stack does not lead to "good" code.
However, when faced with no other practical solution, then "good"
must "yield" to practical. I can think of many cases where things
would have had to be implemented in some other programming
environment were it not for the availability of LAP and single (and
double) float allocations on the stack.
What about giving users the:
macros and just say that they may disappear and not be supported in
some future release? The liability would lie with the users and not
with the Lisp implementation.
More information about the Openmcl-devel