[Openmcl-devel] how does one cause stack-allocation for floats?

[Toomas Altosaar]

Hi Gary,

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 
float code.

Side note:
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:

WITH-STACK-DOUBLE-FLOATS
WITH-PPC-STACK-SHORT-FLOATS

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.

Thanks,

Toomas