Hi Michael,
On Mon, 18 May 2015, Michael Ferguson wrote:
> I do have one question for you about this. The C function frexp breaks
> up a floating point number into a normalized fraction (stored as a
> double) and an exponent.
Yes.
frexp(double mantissa, int *exponent)
frexpf(float mantissa, int *exponent)
frexpl(long double mantissa, int *exponent)
I always try to avoid with a passion such call function overhead. They do
tend to confuse optimizers. That is not currently a big issue for Chapel
because Chapel does not by itself create assembler. However, in the future
when the language gets to be a full-blown compiler, it will be an issue.
Going back to try and fix the problem in hindsight is always difficult and
frustrating.
In C++ which has the C concept of bit fields, I can to do something like
#include <ieee754.h>
float f = (float) 10.5; // copy 10.5 from memory into a register
union ieee754_float ft = {f}; // copy/write-back to memory here
unsigned int negative = ft.ieee.negative;
unsigned int mantissa = ft.ieee.mantissa;
unsigned int exponent = ft.ieee.exponent;
No overhead except for a copy/write-back into the memory used by 'ft'.
Note that I think those unions in 'ieee754.h' need an extra integral
field, not that I have any input to the standards committee.
> Do you know how to convert that behavior to returning the mantissa
> as an integer?
Yes. But this may not often be an issue. I normally want to either throw
away, or re-use (as-is), the mantissa.
I want lean and lucid. So probably too messy for what I want.
> Is it important to you to get an integer mantissa versus a normalized
> fraction?
It makes it easier to put things back together again. So I will say yes
but that not be the full answer.
> Do you know why the fractional mantissa strategy was chosen for C?
Yes. But that's a topic for discussion on another day, preferably over a
cold decent beer to help drown/cool any disagreement heat in words that
might be flying around. I lament that we still have mathematical libraries
which have an interface which dates back long before I even knew what a
computer was!! Let's go offline if you want to discuss that one. And we
might need a referee!
> I think it would be straightforward to implement something in the
> runtime that calls these C functions.
> Alternatively, we could use the implementation similar to what you have
> described as some C functions (that are inline) in the runtime.
That sounds interesting. How do you create/write C functions that then get
effectively expanded in-line in the C code which Chapel creates?
> Either way, I think that the best approach here is to implement it as
> part of the runtime (rather than give Chapel the ability to use C
> unions, e.g.).
Ultimately, that sounds an extremely sound approach. Not reall my field of
expertise.
> You could implement it in C for now.
OK. However, but how far do you take that argument? Such discussions can
degrade to the point where something like writing the module Norm should
be done in C. That becomes a deal-breaker and defeats the Chapel-ification
purpose. Or heaven forbid, you use some in-line assembler within Chapel.
But then you then need versions for X86-64, ARM, SPARC, MIPS, ..... Yuk.
Not my scene. Oops, probably time for another discussion over a beer, or
considering it is in-line assembler, something stronger????
> I suppose an alternative would be to use the Chapel support for C
> interoperability to memcpy from the real(64) to a uint(64) and then do
> your shifting and extracting.
Hmmmm. That would kill the ootimizer too. But following on from that, If
you added a new concept to Chapel (to give Brad a few more grey hairs) and
had a neutral type (bits) that allows copies in/out at will, i.e. without
casting as in ...
var lf : real(64);
.....
...assign value to lf ...
.....
var vlf : bits(64) = lf;
....
var ieeelf : int(64) = vlf;
or even something like
var lf : real(64);
.....
...assign value to lf ...
.....
var ieeelf : int(64) = lf:bits(64);
this might be an option because most optimizers would probably sort out
any irrelevant or redundant operations/transformations.
> I still think it would be better to do the whole operation in C myself.
See my earlier comment.
> P.S. I'm hoping that the hex floats patch will go in this week...
Beauty. That's cool.
Thanks - Damian
Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
