<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Agreed. I might have more a clue this time around for LONGINT/NT386.<BR>
I think first of all "three" occurences of INTEGER need to be Target.Int, and then push that around, all in m3back:<BR>
last_imm : INTEGER := 0;<BR> lowbound : INTEGER := FIRST (INTEGER);<BR> upbound : INTEGER := LAST (INTEGER);<BR><BR>
Something is bugging me a bit though.<BR>
Is TInt also used to hold LONGINT values for 32bit targets?<BR>
<BR>
I'll look into the atomics too.<BR>
It's easy, because in particular, we can just be overly strict on the memory model.<BR>
Boehm's prototype already is -- using full barriers where only release/acquire is called for.<BR>
<BR>
mfence is a "relatively new" instruction. We are ok with that?<BR>
<BR>
I'll try to report back later about the offset question.<BR>
I'll compile some C examples and see what addressing modes get used. :)<BR>
<BR>
- Jay<BR><BR> <BR>> From: hosking@cs.purdue.edu<BR>> Date: Wed, 13 Jan 2010 10:40:20 -0500<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] integer overflow and for loops<BR>> <BR>> I really don't think an interface should support overflow checks for unsigned types. We have Word.T and Long.T with their current semantics. To be honest I don't think this is really a high priority right now.<BR>> <BR>> I do have another suggestion for where to direct your energies. :-) What about going back to smartening up the integrated backend to generate LONGINT properly on Windows? As a warmup to get you back in the groove you might first consider implementing the M3CG atomic primitives that I just added to m3middle and m3cg and will shortly push through the front-end. Here is a link to the proposed implementations for these on x86/x86_64: http://www.decadentplace.org.uk/pipermail/cpp-threads/2008-December/001937.html<BR>> <BR>> We only need the following:<BR>> <BR>> Load Relaxed: MOV (from memory)<BR>> Load Acquire: MOV (from memory)<BR>> Load Seq_Cst: LOCK XADD(0) // alternative: MFENCE,MOV (from memory)<BR>> <BR>> Store Relaxed: MOV (into memory)<BR>> Store Release: MOV (into memory)<BR>> Store Seq Cst: LOCK XCHG // alternative: MOV (into memory),MFENCE<BR>> <BR>> Acquire Fence: <ignore><BR>> Release Fence: <ignore><BR>> Acq_Rel Fence: <ignore><BR>> Seq_Cst Fence: MFENCE<BR>> <BR>> Also, we need implementations for the fetch_and_op variants, which presumably require LOCK variants for all the operations to ensure that they are atomic (regardless of memory order).<BR>> <BR>> One question I have for efficient code on x86 is whether the M3CG ops need to take an offset as well as the address of the atomic variable. The ops as currently defined do not take an offset. This would permit more efficient addressing modes for the instructions just like regular loads/stores.<BR>> <BR>> On 12 Jan 2010, at 22:08, Jay K wrote:<BR>> <BR>> > <BR>> > If isn't needed for safety, then I agree.<BR>> > I really thought it was needed for safety.<BR>> > But I do not "argue" that that is true.<BR>> > I guess array bounds checking, and checks upon assignment to subranges, make it redundant.<BR>> > <BR>> > <BR>> > That said, even if it shouldn't be mandatory, making it a thread local still doesn't seem like the one true solution. It is one of a few solutions.<BR>> > This is a common problem. There are several solutions all with tradeoffs.<BR>> > It could be bound to a type, or an interface, or a process, or code compiled with a certain flag.<BR>> > I tend to think type/interface are the best options.<BR>> > <BR>> > <BR>> > INTERFACE IntegerOverflowOut;<BR>> > <BR>> > <BR>> > (* maybe UNTRACED REF := NIL for "compatibility" *)<BR>> > <BR>> > PROCEDURE Add(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;<BR>> > PROCEDURE Sub(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;<BR>> > PROCEDURE Mult(a,b: INTEGER; VAR overflow: BOOLEAN): INTEGER;<BR>> > PROCEDURE AddUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;<BR>> > PROCEDURE SubUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;<BR>> > PROCEDURE MultUnsigned(a,b: Word.T; VAR overflow: BOOLEAN): Word.T;<BR>> > <BR>> > PROCEDURE AddLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;<BR>> > PROCEDURE SubLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;<BR>> > PROCEDURE MultLong(a,b: LONGINT; VAR overflow: BOOLEAN): LONGINT;<BR>> > PROCEDURE AddUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;<BR>> > PROCEDURE SubUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;<BR>> > PROCEDURE MultUnsignedLong(a,b: Long.T; VAR overflow: BOOLEAN): Long.T;<BR>> > <BR>> > <BR>> > INTERFACE IntegerOverflowRaises;<BR>> > <BR>> > EXCEPTION Error;<BR>> > <BR>> > PROCEDURE Add(a,b: INTEGER): INTEGER RAISES Error;<BR>> > PROCEDURE Sub(a,b: INTEGER): INTEGER RAISES Error;<BR>> > PROCEDURE Mult(a,b: INTEGER): INTEGER RAISES Error;<BR>> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T RAISES Error;<BR>> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T RAISES Error;<BR>> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T RAISES Error;<BR>> > <BR>> > PROCEDURE AddLong(a,b: LONGINT): LONGINT RAISES Error;<BR>> > PROCEDURE SubLong(a,b: LONGINT): LONGINT RAISES Error;<BR>> > PROCEDURE MultLong(a,b: LONGINT): LONGINT RAISES Error;<BR>> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T RAISES Error;<BR>> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T RAISES Error;<BR>> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T RAISES Error;<BR>> > <BR>> > <BR>> > INTERFACE IntegerOverflowSilent;<BR>> > <BR>> > <BR>> > PROCEDURE Add(a,b: INTEGER): INTEGER;<BR>> > PROCEDURE Sub(a,b: INTEGER): INTEGER;<BR>> > PROCEDURE Mult(a,b: INTEGER): INTEGER;<BR>> > PROCEDURE AddUnsigned(a,b: Word.T): Word.T;<BR>> > PROCEDURE SubUnsigned(a,b: Word.T): Word.T;<BR>> > PROCEDURE MultUnsigned(a,b: Word.T): Word.T;<BR>> > <BR>> > PROCEDURE AddLong(a,b: LONGINT): LONGINT;<BR>> > PROCEDURE SubLong(a,b: LONGINT): LONGINT;<BR>> > PROCEDURE MultLong(a,b: LONGINT): LONGINT;<BR>> > PROCEDURE AddUnsignedLong(a,b: Long.T): Long.T;<BR>> > PROCEDURE SubUnsignedLong(a,b: Long.T): Long.T;<BR>> > PROCEDURE MultUnsignedLong(a,b: Long.T): Long.T;<BR>> > <BR>> > <BR>> > Notice how two of the interfaces are "source compatible" and allow<BR>> > easy switching between them for testing/investigation.<BR>> > That might be deemed a feature, and provided somehow across all three.<BR>> > <BR>> > <BR>> > Is anyone strongly opposed to providing something *like* these in m3core?<BR>> > Maybe inlined by the compiler?<BR>> > <BR>> > <BR>> > You know, some program might have a mix of code that absolutely requires integer overflow to raise, and other code that absolutely requires it to be silent. Having a thread local doesn't cut it for such code, unless you go to the trouble of fiddling back and forth the thread local.<BR>> > Sometimes the setting should be set by the author of the code and not be changable without recompiling it all.<BR>> > <BR>> > And sometimes not.<BR>> > <BR>> > <BR>> > - Jay<BR>> > <BR>> > <BR>> > <BR>> > ----------------------------------------<BR>> >> Subject: Re: [M3devel] integer overflow and for loops<BR>> >> From: hosking@cs.purdue.edu<BR>> >> Date: Tue, 12 Jan 2010 21:18:59 -0500<BR>> >> CC: m3devel@elegosoft.com<BR>> >> To: jay.krell@cornell.edu<BR>> >> <BR>> >>> http://www.roland-illig.de/articles/modula-3-for-loop.pdf<BR>> >> <BR>> >> This assumes that overflow checks should be defined on integers in the language. Rather than making things special for FOR loops it would mean general overflow checks on all integer arithmetic in the language. I think this is an unacceptable overhead for a systems programming language. C does not have it. The characteristics of restricted range integer arithmetic are well understood. If programmers want overflow checking it should be compiled/configured (using FloatMode) on the side (without tying the language spec down).<BR>> >> <BR>> <BR> </body>
</html>