[M3devel] -check_procs?

[Jay K]

Calling NIL on NT/x86 is very well defined.It is the same as reading/writing NIL.You get a "structured exception" that you can catch using __try/__except.

 > Why does it not work to use exception on NIL call for that target?   Who says it doesn't? Our current implementation suggests it doesn't, but that doesn't mean anything. Current implementation is often backwards. 
Maybe we install signal handlers on other platforms, but we don't put in the equivalant high-level __try/__except on NT/x86.Maybe we should provide a "ThreadBase" in C. 
But it's not like the process just jumps off into the weeds and does random stuff.Debuggers break right and show a callstack. Without all that extra Modula-3 runtime stuff...

  - Jay

Subject: Re: [M3devel] -check_procs?
From: hosking at cs.purdue.edu
Date: Fri, 14 Sep 2012 11:05:37 -0400
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu

The question is: what does calling a NIL procedure do on the target?  I suggest leave it for now as is for the targets that don’t do the check.  What is the exception handling story for NT/x86?  Why does it not work to use exception on NIL call for that target?


On Sep 14, 2012, at 4:41 AM, Jay K <jay.krell at cornell.edu> wrote:The front end has a lot of internal options.


Here is one: -check_procs.
It has one effect:

PROCEDURE Gen_Call_indirect (t: Type;  cc: CallingConvention) =  BEGIN    IF Host.doProcChk THEN Check_nil (RuntimeError.BadMemoryReference); END;

Does it really make sense that we use this for NT/x86 and only NT/x86?I kind of think we should use it never or use it always.Or use it on all but NT/x86 -- where the exception handling mechanism is pretty well defined and easy to program. We use it on NT/x86 only (the opposite of my suggestion).

Using it always would bloat our code but trivially give us "safe" portable/consistent behavior.The Modula-3 code would stop right away by calling portable code.Instead of triggering whatever platform-specific signal/exception.

I happened on this code...looking at other stuff...obvious reasons if you look around...

 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120914/d410b86d/attachment-0002.html>