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

[jay.krell at cornell.edu]

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.
>>>>
>>>>
>>>
>