[M3devel] Target.First_readable_addr

[Jay K]

At the very least, can we use the same number for all targets, 4K?

I don't like this inconsistency:

 IF RTParams.IsPresent("checked") THEN    EVAL F4096x8p2.F1(NIL); (* large -- gets null checked *) END; IF RTParams.IsPresent("unchecked") THEN    EVAL F0.F1(NIL); (* small -- does not get null check *) END;

jair:p263 jay$ ./I386_DARWIN/pgm @M3checked

****** runtime error:***    Attempt to reference an illegal memory location.***    file "../F4096x8p2.m3", line 8***
Abort trap: 6jair:p263 jay$ ./I386_DARWIN/pgm @M3unchecked

****** runtime error:***    Segmentation violation - possible attempt to dereference NIL***    pc = 0xb8dc5 = F1 + 0x6 in ../F0.m3***

I wonder if we have even implemented this for Windows, the unchecked form.The inefficient checked form is easy.Notice how "large" gives the file/line of the null deref, "small" does not.

What do Java, gcj, C#, mono, .NET Native, go, rust do?

(Extra credit to anyone who can show meboth their compiler outputting the checksand their generated code in a debugger..For Modula-3/cm3cg, grep for fault in the *ms files for *.c files)

 - Jay


Subject: Re: [M3devel] Target.First_readable_addr
From: hosking at purdue.edu
Date: Wed, 26 Aug 2015 14:44:30 +1000
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

This optimization has some performance benefit.Surely we can simply fix the problems rather than removing the capability.
On Aug 26, 2015, at 10:28 AM, Jay K <jay.krell at cornell.edu> wrote:Of course, my agenda is to remove target-specificity.


Target.First_readable_addr is a target-specific optimizationto omit null checks. Or maybe range checks..

The assumption is that dereferencing "actual" null is checkedby the hardware, so code doesn't have to be generated to check for null.

I'm not even sure I like this -- as the behavior of dereferencing null is not portable. 

The assumption is further that accesses to the first page, at least,are subject to the same hardware checks, and can also be optimized away.

At first, glance, I thought this was based on offset + size of a static access.

For example:
a: ARRAY [0...large] OF CHAR

a[0..4095]   no checka[4096 and up] would check

Target.First_deadable_addr is 4k on many targets; 8k on others.Setting it too low would yield extra checks.Setting it too high would yield missing checks and a loss of safety.

Here is what I actually found though.

 - The check is based on the size of the type being accessed.
 - It is off by a factor of 8 -- there is confusing between m3middle and m3front  as to if it is bit number of a byte number.

small: ARRAY[0..100] OF CHARlarge:ARRAY[0..100000] OF CHAR
no access to small gets checked and every access to larger gets checked.
Should we do anything about this?
In m3-sys/m3tests/src/p2/p263:cm3 -realcleancm3 -keepgrep fault <target>/*ms

All the accesses are to offset 0.So, by some expectation, no null checks are needed.Null checks are output when the size of thecontaining type is, for x86, larger than 4096*8.

The checks have been largely but not completely wrong/missing.Safety behooves us to check though.
 - fix the factor of 8? - make it 0?? too slow? - make it 4k on all target? until such time as a target manifests with a smaller page size? - base the checks on access offset + size, not containing size?   Containing size is conservative. It checks more than i think is meant.

I couldn't actually figure out the code here, I added various:
    IF RTParams.IsPresent("qual") THEN      RTIO.PutText("NilChkExpr.Compile p.offset:" & Fmt.Int(p.offset) & "\n");      RTIO.Flush();    END;
and such to m3front to figure it out.

Thanks,- Jay
_______________________________________________M3devel mailing listM3devel at elegosoft.comhttps://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150826/a64bdab0/attachment-0002.html>