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

Jay jay.krell at cornell.edu
Sun May 24 20:19:46 CEST 2009


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


More information about the M3devel mailing list