[kaffe] HAVE_move_float_const

[Gerlando Falauto]

On Tue, 1 Jul 2003, Dalibor Topic wrote:

> Ciao Gerlando,
> 
> --- Gerlando Falauto <iurly at writeme.com> wrote:
> 
> > Nope, it's perfectly clear but still I don't get your point. If you wanna
> > be safe, shouldn't you just be CONSISTENT? Declare it as a float, and let
> > the compiler decide what casts are appropriate. At this level, so long as
> > I get what was meant to be passed (which is a *float*), I shouldn't really
> > care what the compiler does. The point here is, I want a float constant
> 
> Different versions of C 'standards' (and thus different versions of compilers)
> have had different interpretations of what you really meant to be passed when
> you wrote 'float'. :)
> 
> See
> http://groups.google.de/groups?q=float+parameter+function&hl=de&lr=&ie=UTF-8&oe=UTF-8&selm=3D8EF8EB.2000809%40mchsi.com&rnum=7
> for another nice explanation of the pitfalls involved.
> 
> > (which is 32-bit wide) exactly as it was written in the classfile, so I
> > can move it to a register (as a 32-bit chunk). If the compiler wants to
> > promote it as an internal optimization, that is none of my business!
> 
> The C99 standard doesn't guarantee you'll have 32 bit wide floats. It doesn't
> even guarantee the floats will be 'base 2'. But fortunately, kaffe hasn't been
> ported to such a beast yet, AFAIK ;) 

Well but we have the guarantee that *java floats* are 32-bit wide right?
So shouldn't we use that, again, for consistency?
Shouldn't all the immediates be 'jint', 'jlong', whatever, for that 
matter?

> On the other hand, we're talking about the jitter here, right? Then you of
> course you know more about types and their representations in the hardware.

> 
> > If I get it as a double, I have to cast it back to a float. Apart from
> > the waste of time, is that guaranteed to be non-destructive?
> 
> I don't think it's guaranteed to be non-destructive. NANs for example may not
> get to be the same NANs they were before...

That's my point. If Kaffe read a jfloat constant from a .class file, I
want my back end to get *exactly* that jfloat, not some other converted
stuff! But hey, that is only an issue if I have any float immediate in the
instruction stream, otherwise that doesn't matter, at all.

> But anyway, if just using floats works for you, please port a patch
> and let others evaluate it. That's much easier than trying to
> interpret the C standard ;)

That contradicts a lot of good software engineering principles, but I got
to admit, that's the way it is. ;)

Gerlando