[M3devel] LONGREAL and m3gdb (was gettimeofday called from CheckLoadTracedRef?)

[Mika Nystrom]

Haha, FP isn't weird!  It's just... FP!

This is a bit disappointing... here's FreeBSD4:

(552)rover:~/fp/src>./a.out
sizeof(float) = 4
sizeof(double) = 8
sizeof(long double) = 12
(553)rover:~/fp/src>../FreeBSD4/fp
BITSIZE(REAL) = 32
BITSIZE(LONGREAL) = 64
BITSIZE(EXTENDED) = 64

I think the "12" is just to get them word-aligned.

i387 supports 10-byte extended format in hardware (in fact that is
the *only* format it supports, which may cause subtle bugs and/or
inefficiencies when using other sizes).

PowerPC does 128-bit but is that normally provided in hardware?

In any case it seems to me that on i386, Modula-3's EXTENDED ought
to be Intel 80-bit FP, possibly padded with two extra bytes like
in C.  Easiest seems to just make it match C's long double...

If the backend compiler optimizer knows what it's doing, 80-bit FP
can run faster on i387 than 32- or 64-bit.  Because in the narrower
formats, the 387 has to convert results to the narrower format on
every operation, which it normally does by storing the result and
re-loading it.  That's not necessary if the code stays in 80-bit
extended; instead it keep the intermediate results in registers.

    Mika

jay.krell at cornell.edu writes:
>What does 'long double' give you in C? On Windows I'm sure it is 64  
>bits. I was just reading that powerpc has a 128 bit long double but I  
>don't know if always/everywhere and it is in software via two doubles  
>and lacks various features.On x86 there is something somehow  
>supposedly much better for FP via SSE/2/3/whatever. Imho FP is just  
>all around wierd and to be avoided..
>
>  - Jay (phone)
>
>On May 24, 2009, at 1:45 PM, Mika Nystrom <mika at async.caltech.edu>  
>wrote:
>
>> Hrmph this is a bit silly.
>>
>> 80-bit FP ought to be supported on x86, at least, since that's the
>> native precision of the i387 (and 68881?)...
>>
>>     Mika
>>
>> Jay writes:
>>>
>>> Modula-3 only actually implements two floating point formats.
>>> The language spec and frontend might support three "names", but two  
>>> of them are the same.
>>>
>>> - Jay
>>>
>>>
>>> ----------------------------------------
>>>> Date: Sun, 24 May 2009 08:50:14 -0500
>>>> From: rodney.m.bates at cox.net
>>>> To: m3devel at elegosoft.com
>>>> Subject: Re: [M3devel] LONGREAL and m3gdb (was gettimeofday called  
>>>> from CheckLoadTracedRef?)
>>>>
>>>> Floating point values in m3gdb is one area I have never done any
>>>> work on at all, but I have been aware for a long time that it  
>>>> probably
>>>> needs some. It just uses stock gdb's code, which also just uses
>>>> the C builtin arithmetic on C floating types. At the very least, the
>>>> mapping between C's two and Modula-3's three floating types, on
>>>> the various targets, is purely an accident right now. I recall there
>>>> is something wrong in the formatting too.
>>>>
>>>> Mika Nystrom wrote:
>>>>> Hi Modula-3ers, especially Tony,
>>>>>
>>>>> I'm seeing the following behavior a lot in a program I'm running:
>>>>>
>>>>> #0 0x68ecbba7 in gettimeofday () from /lib/libc.so.5
>>>>> #1 0x68611cb9 in Now () at ../src/time/POSIX/TimePosix.m3:16
>>>>> #2 0x685ecf06 in CollectorOn (timeOnEntry=Invalid C/C++ type code  
>>>>> 30 in symbol table.
>>>>> ) at ../src/runtime/common/RTCollector.m3:674
>>>>> #3 0x685f2476 in CheckLoadTracedRef (ref=Invalid C/C++ type code  
>>>>> 46 in symbol table.
>>>>> ) at ../src/runtime/common/RTCollector.m3:2271
>>>>> #4 0x68139379 in Get (tbl=Invalid C/C++ type code 26 in symbol  
>>>>> table.
>>>>> )
>>>>> at ../FreeBSD4/SortedTotalOrderLRTbl.m3 => /usr/local/cm3/pkg/ 
>>>>> libm3/src/sortedtable/SortedTable.mg:145
>>>>>
>>>>> Is it normal for CheckLoadTracedRef to make system calls?
>>>>>
>>>>> Hmm, why is it even doing CheckLoadTracedRef? Here's the code  
>>>>> (from SortedTable.mg):
>>>>>
>>>>>
>>>>> PROCEDURE Get ( tbl : Default;
>>>>> READONLY k : Key.T;
>>>>> VAR(*OUT*) v : Value.T): BOOLEAN =
>>>>> VAR
>>>>> x : Node := tbl.h.hi;
>>>>> cmp : Cmp;
>>>>> BEGIN
>>>>> WHILE (x # NIL) DO
>>>>> cmp := tbl.keyCompare (k, x.key);
>>>>> IF cmp = 0 THEN v := x.value; RETURN TRUE; END;
>>>>> IF (cmp < 0)
>>>>> THEN x := x.lo; (* line 145 *)
>>>>> ELSE x := x.hi;
>>>>> END;
>>>>> END;
>>>>> RETURN FALSE;
>>>>> END Get;
>>>>>
>>>>> where Node is defined as
>>>>>
>>>>> TYPE
>>>>> Node = REF RECORD
>>>>> key : Key.T;
>>>>> value : Value.T;
>>>>> lo : Node := NIL;
>>>>> hi : Node := NIL;
>>>>> priority: INTEGER (* random num; tree is a heap on these *)
>>>>> END;
>>>>>
>>>>> It seems odd to me that, under these circumstances, x := x.lo would
>>>>> cause any sort of checking activity...
>>>>>
>>>>> I'm using a CM3 that's about a month old, on FreeBSD4.
>>>>>
>>>>> Mika
>>>>>
>>>>> P.S. Needless to say, the code in question runs about 10x faster  
>>>>> under
>>>>> PM3 than with this relatively new CM3... but my m3gdb is having  
>>>>> trouble
>>>>> with PM3's LONGREALs for some reason.
>>>>>
>>>>>
>>>>
>>