<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'> AMD64_NT starting up mentor: <br> <br> *** <br> *** runtime error: <br> *** An enumeration or subrange value was out of range. <br> *** file "..\src\EventWireRep.m3", line 89 <br> *** <br><br><br>This opens up a big multi-part can of worms.<br>I'm not sure the order to present things.<br>Please bear with me.<br><br><br><br>Background:<br><br> Time.T is a double/longreal number of seconds since a platform-specific epoch.<br> This cleverly gives I guess pretty good range and precison.<br> On Windows, that is 1601.<br> The underlying system stores 64bit 100s of nanoseconds. <br>This gives both good range and precision.<br> And it works ok with Modula-3. <br> On Posix is presumably 1970. <br> This is all ok. Not controversial.<br><br><br><br>Corralaries:<br><br>Time.Now on Windows returns around 1.3022747815483961e10.<br>My simple math says that is off by a month but hopefully<br>more precise math says it is exactly correct.<br> We have confusing Modula-3 code and straightforward C code to compute this.<br>That it is within a month seems adequate to backup everything<br>else I'm seeing/saying.<br><br><br>events!EventWireRep_M3 [c:\dev2\cm3\m3-comm\events\src\eventwirerep.m3 @ 90]<br><br> Int32 = BITS 32 FOR [-2147483647-1..2147483647];<br> TRep = RECORD ts: Int32; objNum: Int32; space: EventSpaceID.T; END;<br><br>VAR myTs: Int32 := ROUND(Time.Now());<br><br><br> Clearly this is a problem. <br> It runs out "soon" on 32bit Posix systems, it runs out <br> already on Win64, and on Win32, well, it produces <br> garbage one way or another, but no range errors. <br><br><br>On AMD64_NT, this reasonably rounds to<br><br> 13022747815 -- the full integer value of the double<br> fits in a 64bit integer.<br> <br>But it doesn't fit in 32 bits.<br> On I386_NT, this somewhat "correctly" rounds to<br> -2147483648<br> <br>Hm. Shouldn't it be nearest integer 2147483647??<br><br><br>In either case, see you the problem.<br><br>Ok, so this is three dilemnas/questions/bugs in one.<br><br><br>http://modula3.elegosoft.com/cm3/doc/reference/complete/html/2_6_10Arithmetic_operations.html<br><br><br>ROUND(r) is the nearest integer to r; ties are broken according to the constant RoundDefault<br><br><br>1) How should ROUND be defined? Is Modula-3 adequately safe here?<br><br><br> What should round of numbers less than FIRST(INTEGER)-1 <br> or greater than LAST(INTEGER) + 1 round to? <br><br><br> By the simple definition, they should round to FIRST(INTEGER) <br> and LAST(INTEGER). But is it safe?<br><br><br> You know, I can see taking the whole part of the number <br> and losing the fractional part as being ok when desired, <br> but when the whole part doesn't fit, not even when rounded <br> up or down by 1? Doesn't that seem like it should be a range error? <br><br><br><br>2) What is up with the various implementations?<br><br><br>ASSUMING Modula-3 ROUND is defined safely enough,<br>is the integrated NT/x86 backend correct here?<br><br><br>On I386_DARWIN:<br><br>IMPORT IO, Fmt;<br><br>BEGIN<br>IO.Put(Fmt.Int(ROUND(1.3022747815483961e10)) & "\n");<br>END Main.<br><br><br>We get: 137845760.<br><br><br>Wow, that is just wrong.<br>Sure it got the mantissa close, but the exponent is arbitrary seeming.<br>I could chalk this up to a bug in my C backend,<br>but it gets constant folded in the front end.<br>The backend just gets load_integer 137845760.<br>This seems highly incorrect.<br>Maybe bugs in Target.Float?<br>Maybe overflow is being ignored??<br>I'll look later, another day.<br><br><br><br>3) What to do?<br><br><br>3a) The frontend seems wrong here, no matter what.<br><br>3b) The integrated backend seems at least slightly wrong.<br><br>3c) The events code either needs widening, or perhaps<br>this isn't time, but a somewhat arbitrary "fingerprint".<br>Perhaps it can just use MOD?? I will likely verify if it needs to be<br>time or just a reasonably volatile number to cross check sender/reciever<br>and then use MOD. Posix and Win32 systems probably can't talk to each other. Lame.<br><br><br><br>Someone might suggest that Win32 epoch be changed to 1970.<br>I don't think so.<br><br><br>4) can anyone understand and explain the Modula-3 code we have here in Time.m3?<br><br><br><br>Thank you,<br> - Jay </div></body>
</html>