[Openmcl-devel] how does one cause stack-allocation for floats? 
janderson at ravenpack.com
Wed Mar 29 12:20:54 UTC 2006
yes, yes, yes, i [have tried to] openly admit, that my instructions to the
compiler are incoherent.
unfortunately, the language of standard lisp does not offer a means to say it
and yes, i agree that there are lots of aesthetic reasons to not want to be
concerned whether any object is mutable.
even more than aesthetic reasons. on the other hand, for some things, i really
do want answers now, and need to be concerned about "resourcing" objects.
intermediate arithmetic results are among those objects. "putting them on the
stack" has been, as a matter of contingent convention, been a means to
as noted in my earlier response, i am not convinced that a compiler will ever
figure everything out.
i also don't understand why it should need to.
i am all ears for suggestions as to how to express the intent to the compiler in
a more coherent manner.
[way down at the bottom of my reply, was the query,]
> -----Original Message-----
> From: Gary Byers [mailto:gb at clozure.com]
> Sent: Wednesday, March 29, 2006 13.38
> To: james anderson
> Cc: openmcl-devel at clozure.com
> Subject: Re: [Openmcl-devel] how does one cause stack-allocation for
> floats? 
> On Wed, 29 Mar 2006, james anderson wrote:
> > ...
> > what is wrong with letting the program specify that it wants scratch
> > storage?
> > would it not be the right thing to support (declare (register result))?
> > it would avoid the (= 0.0 pi) problem. no?
as this is more polite and to the point than
maybe the compiler would be inclined to attend to it?
seriously, i understand your reply to explain that this is what one would like
the compiler to be able to infer.
apriori, i'm not even sure how much difference it would make whether the code
actually use a register, or uses the stack, or destructively uses a
heap-allocated cell. (modulo caching and memory bandwidth issues, with which one
could well experiment.)
why not just tell it, that it's ok to have a "destructive binding"?
More information about the Openmcl-devel