<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'>That is done -- it is a constant 4k now.<BR>Hypothetically Sparc/IA64/Alpha could be 8k. Sparc used to be.<BR> <BR> <BR>I'm still leary of the omitted checks and suggest we compare<BR>against C# (JIT and native, Microsoft and Mono), Java, Go, Rust, Gnat, etc.<BR>If most/all of them check aggressively, we should to imho.<BR>If they actually omit more aggressively, which I believe is possible, we should consider that.<BR> <BR>In particular, I think the omission should be based on the offset+size of the access,<BR>not of the containing type. i.e. the field and not the record.<BR>However this might be a fallacy also.<BR> <BR>e.g.<BR> <BR>TYPE BigRecord = RECORD ...lots.... INTEGER smallFieldPast4K END;<BR> <BR>PROCEDURE F1(VAR a:INTEGER);<BR> <BR>PROCEDURE F2(b:REF BigRecord)<BR>BEGIN<BR> F1(b.a);<BR>END F2;<BR> <BR>Hm. I see. Maybe you have to check at b.a and a (not shown here)?<BR>The recipient of a "small" type doesn't know its offset, if any, within a larger type,<BR>and it can vary.<BR> <BR>I can have:<BR>TYPE SmallRecord = RECORD .. nothing .. INTEGER smallFieldAtStart END;<BR> <BR>F1(smallRecord.a);<BR> <BR>So maybe you are right anyway -- check needed at the "address generation" not just the deref.<BR> <BR>I need to study this more.<BR> <BR>Another idea, perhaps, is that if there is any dereference of a parameter within a function,<BR>do all the checks up front, and then none in the function. You know -- in case there are loops.<BR> <BR>But I also don't know the guarantees around "dynamic paths" -- turning conditional dereferences<BR>into unconditional dereferences.<BR> <BR>I need to study this more. :)<BR> <BR> - Jay<br><br> <BR><div>> Date: Thu, 27 Aug 2015 17:20:58 -0500<br>> From: rodney_bates@lcwb.coop<br>> To: hosking@purdue.edu<br>> CC: m3devel@elegosoft.com; jay.krell@cornell.edu<br>> Subject: Re: [M3devel] Target.First_readable_addr<br>> <br>> In any case, I would shed no tears if First_readable_addr were set target-indepenently<br>> to the lowest value on any target, since that would only increase the number of cases<br>> that give the proper error at the proper place & time.<br>> <br>> On 08/26/2015 10:07 PM, Antony Hosking wrote:<br>> > The compiler does in fact leave a nil check on every deref (both implicit and explicit) except in the case that the offset falls within the range that can be caught with a trap. In which case, yes the check is delayed until the actual memory access. It is perhaps not so bad that the offending deref will be visible up the stack in the case of VAR params. So, pragmatically I think it is nice to have zero-cost null checks, but it does compromise Rodney’s desire for every use of ^ to have the null check at that point.<br>> ><br>> >> On Aug 27, 2015, at 12:23 PM, Rodney M. Bates <rodney_bates@lcwb.coop> wrote:<br>> >><br>> >><br>> >><br>> >> On 08/26/2015 11:10 AM, Jay wrote:<br>> >>> Passing a ^ to a VAR imho should probably not count as a deref -- I agree with the implementation. Just like in C++ dereferencing a pointer to get a reference instead of a value. One wants a stack trace, and a runtime check maybe applied after the fact.<br>> >>> Ie. once we fault, show all nil parameters on the stack to all functions to help me fish for it. Not easy.<br>> >>><br>> >><br>> >> No, I disagree adamantly. The whole idea of linguistic support of parameters passed by<br>> >> reference, instead of the programmer manually concocting it by taking addresses and<br>> >> contents of pointers, is that the language ensures to the called procedure that the<br>> >> hidden pointer will be neither NIL, uninitialized, nor point to something of the<br>> >> wrong type.<br>> >><br>> >> In fact, pass by ref is not even defined in terms of the compiler lowering into pointer<br>> >> twiddling. It is defined abstractly as the formal is "bound to", i.e. "aliases" the actual<br>> >> (2.3.2). This is a highly proper subset of the full semantics of what pointers can do.<br>> >> NIL or uninitialized have no meaning in this definition, and wrong type is a failure of the<br>> >> type system that should only happen in UNSAFE code.<br>> >><br>> >> NIL deref, as a runtime error, should in concept happen when and where ^ is applied<br>> >> to a pointer, including the implied dereference when a subscript or field selection is<br>> >> applied directly without the ^ operator. It's purely an implementation question how to<br>> >> do this. If a segfault message will point to the line of code where the dereference<br>> >> happens, and before execution proceeds beyond that code, that would be marginally OK.<br>> >> (Only marginally, because the error message should be able to say with certainty that<br>> >> it's a NIL deref.<br>> >><br>> >> Fortunately, in safe Modula-3 code, there are not a lot of other ways to segfault<br>> >> (any?). Unfortunately, there's plenty of unsafe code, and if its programmer fails his<br>> >> obligation, its effects can escape into safe code.<br>> >><br>> >>><br>> >>> - Jay<br>> >>><br>> >>> On Aug 26, 2015, at 8:37 AM, "Rodney M. Bates" <rodney_bates@lcwb.coop> wrote:<br>> >>><br>> >>>> I have always thought "segfault, could it be a NIL pointer deref?", or whatever<br>> >>>> words to that effect, was a rather lame excuse of an error message, and not<br>> >>>> much help.<br>> >>>><br>> >>>> Since this scheme doesn't fault at the point of the real deref, but afterwards, when a<br>> >>>> memory reference is actually made, possibly computed from that address, could the location<br>> >>>> given for the fault (whether line no or just code displacement) be wrong? Very wrong?<br>> >>>><br>> >>>> TYPE A = ARRAY [ 0 .. 121 ] OF INTEGER;<br>> >>>><br>> >>>> PROCEDURE Q ( )<br>> >>>> = VAR Ptr : REF A := NIL;<br>> >>>> BEGIN<br>> >>>> P(Ptr^); <---deref occurs here<br>> >>>> END Q;<br>> >>>><br>> >>>> .... lots of other code, different module, etc. ...<br>> >>>><br>> >>>> PROCEDURE P ( VAR x : A )<br>> >>>> = BEGIN<br>> >>>> x[119] := 17 <---memory ref & segfault don't happen until here.<br>> >>>> END P;<br>> >>>><br>> >>>> Or is this scheme only used in selective places, such as implicit deref<br>> >>>> when putting a subscript onto a pointer? e.g.:<br>> >>>><br>> >>>> Ptr[117] := 43;<br>> >>>><br>> >>>> On 08/25/2015 07:28 PM, Jay K wrote:<br>> >>>>> Of course, my agenda is to remove target-specificity.<br>> >>>>><br>> >>>>><br>> >>>>><br>> >>>>> Target.First_readable_addr is a target-specific optimization<br>> >>>>> to omit null checks. Or maybe range checks..<br>> >>>>><br>> >>>>><br>> >>>>> The assumption is that dereferencing "actual" null is checked<br>> >>>>> by the hardware, so code doesn't have to be generated to check for null.<br>> >>>>><br>> >>>>><br>> >>>>> I'm not even sure I like this -- as the behavior of dereferencing null is not portable.<br>> >>>>><br>> >>>>><br>> >>>>> The assumption is further that accesses to the first page, at least,<br>> >>>>> are subject to the same hardware checks, and can also be optimized away.<br>> >>>>><br>> >>>>><br>> >>>>> At first, glance, I thought this was based on offset + size of a static access.<br>> >>>>><br>> >>>>><br>> >>>>> For example:<br>> >>>>><br>> >>>>> a: ARRAY [0...large] OF CHAR<br>> >>>>><br>> >>>>><br>> >>>>> a[0..4095] no check<br>> >>>>> a[4096 and up] would check<br>> >>>>><br>> >>>>><br>> >>>>> Target.First_deadable_addr is 4k on many targets; 8k on others.<br>> >>>>> Setting it too low would yield extra checks.<br>> >>>>> Setting it too high would yield missing checks and a loss of safety.<br>> >>>>><br>> >>>>><br>> >>>>> Here is what I actually found though.<br>> >>>>><br>> >>>>><br>> >>>>> - The check is based on the size of the type being accessed.<br>> >>>>><br>> >>>>> - It is off by a factor of 8 -- there is confusing between m3middle and m3front<br>> >>>>> as to if it is bit number of a byte number.<br>> >>>>><br>> >>>>><br>> >>>>> small: ARRAY[0..100] OF CHAR<br>> >>>>> large:ARRAY[0..100000] OF CHAR<br>> >>>>><br>> >>>>> no access to small gets checked and every access to larger gets checked.<br>> >>>>><br>> >>>>> Should we do anything about this?<br>> >>>>><br>> >>>>> In m3-sys/m3tests/src/p2/p263:<br>> >>>>> cm3 -realclean<br>> >>>>> cm3 -keep<br>> >>>>> grep fault <target>/*ms<br>> >>>>><br>> >>>>><br>> >>>>> All the accesses are to offset 0.<br>> >>>>> So, by some expectation, no null checks are needed.<br>> >>>>> Null checks are output when the size of the<br>> >>>>> containing type is, for x86, larger than 4096*8.<br>> >>>>><br>> >>>>><br>> >>>>> The checks have been largely but not completely wrong/missing.<br>> >>>>> Safety behooves us to check though.<br>> >>>>><br>> >>>>> - fix the factor of 8?<br>> >>>>> - make it 0?? too slow?<br>> >>>>> - make it 4k on all target? until such time as a target manifests with a smaller page size?<br>> >>>>> - base the checks on access offset + size, not containing size?<br>> >>>>> Containing size is conservative. It checks more than i think is meant.<br>> >>>>><br>> >>>>><br>> >>>>> I couldn't actually figure out the code here, I added various:<br>> >>>>><br>> >>>>> IF RTParams.IsPresent("qual") THEN<br>> >>>>> RTIO.PutText("NilChkExpr.Compile p.offset:" & Fmt.Int(p.offset) & "\n");<br>> >>>>> RTIO.Flush();<br>> >>>>> END;<br>> >>>>><br>> >>>>> and such to m3front to figure it out.<br>> >>>>><br>> >>>>><br>> >>>>> Thanks,<br>> >>>>> - Jay<br>> >>>>><br>> >>>>><br>> >>>>><br>> >>>>> _______________________________________________<br>> >>>>> M3devel mailing list<br>> >>>>> M3devel@elegosoft.com<br>> >>>>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> >>>><br>> >>>> --<br>> >>>> Rodney Bates<br>> >>>> rodney.m.bates@acm.org<br>> >>><br>> >><br>> >> --<br>> >> Rodney Bates<br>> >> rodney.m.bates@acm.org<br>> >> _______________________________________________<br>> >> M3devel mailing list<br>> >> M3devel@elegosoft.com<br>> >> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br>> ><br>> ><br>> <br>> -- <br>> Rodney Bates<br>> rodney.m.bates@acm.org<br>> _______________________________________________<br>> M3devel mailing list<br>> M3devel@elegosoft.com<br>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel<br></div> </div></body>
</html>