Re: [kaffe] HAVE_move_float_const
Ciao Gerlando, --- Gerlando Falauto [EMAIL PROTECTED] 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+functionhl=delr=ie=UTF-8oe=UTF-8selm=3D8EF8EB.2000809%40mchsi.comrnum=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 ;) 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... 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 ;) cheers, dalibor topic __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
On Tue, 1 Jul 2003, Dalibor Topic wrote: Ciao Gerlando, --- Gerlando Falauto [EMAIL PROTECTED] 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+functionhl=delr=ie=UTF-8oe=UTF-8selm=3D8EF8EB.2000809%40mchsi.comrnum=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 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
Hi everyone, hi, (especially the JIT back-end coders) does anyone have any idea why _slot_slot_fconst is declared void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int) ^^ shouldn't there be a float instead? Can you update and try again. Gerlando thanks, tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
Ciao Gerlando, --- Gerlando Falauto [EMAIL PROTECTED] wrote: On Tue, 1 Jul 2003, Dalibor Topic wrote: --- Gerlando Falauto [EMAIL PROTECTED] wrote: 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? sounds reasonable to me. I'd like to hear what Tim Helmer think about it. 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. ;) In my opinion working code beats proposals. I think that's how linux was developed, and it was quite successful so far ;) cheers, dalibor topic __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] HAVE_move_float_const
Hi everyone, (especially the JIT back-end coders) does anyone have any idea why _slot_slot_fconst is declared void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int) ^^ shouldn't there be a float instead? I took a quick look at the back-ends who actually use it (alpha, arm, i386, ia64), and they are all restricted to a few wired values (like 1.0, 2.0, 10.0 and so on) so this is never a problem for them. However, since my architecture does not provide native floating point support, I can move any fp constant to any register as an immediate. This casting from float to double, though, messes everything up when I get the const value with const_float(2) if the constant is not some nice value. Note that the ARM, i386 and ia64 ports also use const_float(2) and that IMHO is an inconsistency. So I am going to change _slot_slot_fconst to (SlotInfo*, SlotInfo*, float, ifunc, int). Please let me know if I should send a patch (for jit, jit3 and alpha) or if I am just insane. Thanks! Gerlando ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
Hi Gerlando, void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int) shouldn't there be a float instead? I am hesitate to reply for this, but if old story is still true, any c function arguments are converted to double from float. See, pp.137 of C a reference manual. # There should be better and newer books exist. Kiyo ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
On Monday, June 30, 2003, at 04:54 AM, Gerlando Falauto wrote: Hi everyone, hi, (especially the JIT back-end coders) does anyone have any idea why _slot_slot_fconst is declared void _slot_slot_fconst(SlotInfo*, SlotInfo*, double, ifunc, int) ^^ shouldn't there be a float instead? Its a problem, I think I went the wrong direction when fixing another problem, I'll look at it in a bit. Thanks! Gerlando tim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] HAVE_move_float_const
Don't have that manual at hand, but I think that very much depends on the compiler and/or the runtime architecture. I can assure you my (old, ugly, buggy, horrible, non-standard, fp-less, whatever) compiler and You could consider using a better compiler ;) You wanna write one? ;-) Be my guest! Seriously, it's a sort of top-secret platform, and this compiler is the best I could ever get. architecture do not make such a conversion. If a parameter is a float, it's passed in one register (or memory slot), if it's a double, it takes two registers/slots. This really depends on what version of the C the compiler implements. In KR C (i.e. pre-ANSI), float function parameters are always promoted to double. In post-ANSI C (i.e. C89, C99) float function parameters are only promoted to double, if the function declaration is written in KR style. Confusing? Sure it is, so just use double and you're on the safe side ;) 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 (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! 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? later, Gerlando ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
