[Openmcl-devel] how does one cause stack-allocation for floats?
gwking at metabang.com
Fri Mar 31 20:23:24 PST 2006
I'm probably missing something entirely (I'm tired, it's late, and,
frankly, this stuff often leaves me a bit confused...) but how dos
Randall Beer's FPC code fit into this discussion?
On Mar 29, 2006, at 9:57 AM, Toomas Altosaar wrote:
> 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
>> 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:
> 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.
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
Gary Warren King
More information about the Openmcl-devel