<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'>Of course, my agenda is to remove target-specificity.<div><br></div><div><br></div><div><br></div><div>Target.First_readable_addr is a target-specific optimization</div><div><span style="font-size: 12pt;">to omit null checks. Or maybe range checks..</span></div><div><br></div><div><br></div><div>The assumption is that dereferencing "actual" null is checked</div><div>by the hardware, so code doesn't have to be generated to check for null.</div><div><br></div><div><br></div><div>I'm not even sure I like this -- as the behavior of dereferencing null <span style="font-size: 12pt;">is not portable. </span></div><div><br></div><div><br></div><div>The assumption is further that accesses to the first page, at least,</div><div>are subject to the same hardware checks, and can also be optimized away.</div><div><br></div><div><br></div><div>At first, glance, I thought this was based on offset + size of a static access.</div><div><br></div><div><br></div><div>For example:</div><div><br></div><div>a: ARRAY [0...large] OF CHAR</div><div><br></div><div><br></div><div>a[0..4095] no check</div><div>a[4096 and up] would check</div><div><br></div><div><br></div><div>Target.First_deadable_addr is 4k on many targets; 8k on others.</div><div>Setting it too low would yield extra checks.</div><div>Setting it too high would yield missing checks and a loss of safety.</div><div><br></div><div><br></div><div>Here is what I actually found though.</div><div><br></div><div><br></div><div> - The check is based on the size of the type being accessed.</div><div><br></div><div> - It is off by a factor of 8 -- there is confusing between m3middle and m3front</div><div> as to if it is bit number of a byte number.</div><div><br></div><div><br></div><div>small: ARRAY[0..100] OF CHAR</div><div>large:ARRAY[0..100000] OF CHAR</div><div><br></div><div>no access to small gets checked and every access to larger gets checked.</div><div><br></div><div>Should we do anything about this?</div><div><span style="font-size: 12pt;"><br></span></div><div><span style="font-size: 12pt;">In m3-sys/m3tests/src/p2/p263:</span></div><div><span style="font-size: 12pt;">cm3 -realclean</span></div><div><span style="font-size: 12pt;">cm3 -keep</span></div><div><span style="font-size: 12pt;">grep fault <target>/*ms</span></div><div><span style="font-size: 12pt;"><br></span></div><div><span style="font-size: 12pt;"><br></span></div><div><span style="font-size: 12pt;">All the accesses are to offset 0.</span></div><div><font size="3">So, by some expectation, no </font>null<font size="3"> checks are needed.</font></div><div><font size="3">Null checks are output when the size of the</font></div><div><font size="3">containing type is, for x86, larger than 4096*8.</font></div><div><font size="3"><br></font></div><div><br></div><div>The checks have been largely but not completely wrong/missing.</div><div>Safety behooves us to check though.</div><div><br></div><div> - fix the factor of 8?</div><div> - make it 0?? too slow?</div><div> - make it 4k on all target? until such time as a target manifests with a smaller page size?</div><div> - base the checks on access offset + size, not containing size?</div><div> Containing size is conservative. It checks more than i think is meant.</div><div><br></div><div><br></div><div>I couldn't actually figure out the code here, I added various:</div><div><br></div><div><div> IF RTParams.IsPresent("qual") THEN</div><div> RTIO.PutText("NilChkExpr.Compile p.offset:" & Fmt.Int(p.offset) & "\n");</div><div> RTIO.Flush();</div><div> END;</div></div><div><br></div><div>and such to m3front to figure it out.</div><div><br></div><div><br></div><div>Thanks,</div><div><span style="font-size: 12pt;">- Jay</span></div><div><br></div> </div></body>
</html>