Eric Sosman wrote:
> jacob navia wrote:
>> [...]
>> The purpose of this message is to discuss the data structures and the
>> choices I did. Obviously this is a serious implementation
>> of floating point, not just an academic exercise where the numbers
>> are represented just by "unsigned char" or similar solutions.
>
> Okay, I'll bite: Does this discussion have anything to do
> with C, or is it about implementation strategies for a library
> of assembly code?
>
The core of the library is written in C, with the four operations
(add, subtract and multiply, + ****ft in assembler). I do not
see why you think the library is in assembler.
> There seemed to be three C-ish things in your message:
>
> 1) Some assumptions about how a compiler pads (or rather
> doesn't pad) struct objects. I guess the assumptions
> are correct for your compiler, but they also seem
> gratuitous: The operations are described in terms of
> arrays, so why not just use arrays?
>
The problem is that arrays must be homogeneous. The exponent and the
sign are 32 bit, the mantissa is 64 bit. If you find a C array that
will do that I would take it immediately of course.
Nowhere in the code a specific layout is assumed. Precisely this
is the object of using a structure. I do not see where do you see
anything that assumes a specific layout...
Obviously, if we have
struct qfloat{ int32_t sign;int32_t exponent;
long long mantissa[7]};
and the compiler aligns each 32 bit integer into a 64 bit slot
we will have a waste of memory locations but the library will work
Obviously the assembler routines would need to be modified to
fit the compiler layout but I see no problem with this.
> 2) A trick for avoiding an address-of operator in function
> calls, by declaring the variables as one-element arrays.
> The price paid is that simple assignment now needs extra
> syntax: `x = y' becomes `x[0] = y[0]'. TANSTAAFL.
>
There isn't a single assignment
qfloat a,b;
a=b
in the whole library. Why?
Precisely because the library declared the numbers as arrays. For
unknown hysterical reasons arrays can't be assigned to.
NOW that I have rewritten this library to use structures, the assignment
as you say is possible in the source code. Within the library source
code the function
qmov(a,b); //Move a into b
is used.
> 3) I thought there was a third thing, but now I can't find it.
>
> So: You've done something of interest to lcc users and maybe
> to people who need in high-precision floating-point, and you
> should feel good about having done so. But I fail to understand
> why the implementation details of a library of assembly code are
> a fit topic for a forum devoted to a different language.
The cephes library is written in C. I made that very clear in my
message but maybe not clear enough for you.
Besides the extra precision, the library offers many special functions
in an open implementation. The list of functions is very long, with
elliptical integrals, statistics, physics, and many other functions like
Riemann zeta, Bessel functions, gamma, etc.
All that is written in C, for 32 bit, 64 bit and 448 bit precision.
This is a well known library, and I thought that we could discuss it in
this group.
>
> Follow-ups set to comp.compilers.lcc.
>
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
|
