[M3devel] function pointers and comparison to nil? mis-typed function pointers?

[Rodney M. Bates]

Jay wrote:
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
> 
> What is the danger in "mistaking" "real code" for a "trampoline"?
> They are both "real code".

This mistake would break correct implementation of the language.  It
would mean a runtime error, called for by the language semantics,
would go undetected.

(2.3.1: Since there is no way to determine statically whether the
value of a procedure parameter is local or global, assigning a local
procedure is a runtime rather than a static error.)

> The differences are:
>   - trampoline has limited lifetime -- unless it is heap allocated and

Not sure if this is what you meant, but the needed lifetime of either a
M3 closure or a trampoline are the same.  Either way, it is created on
the stack during a call to which a nested procedure is passed as parameter.
In Modula-3, the only reason to heap allocate would be if it is a trampoline,
to get around the possible non-executable state of the stack on some targets.
There is no need for heap lifetime semantics.

> garbage collected
>     ("real code" also has "limited lifetime", but relatively much 
> longer, if code can be unloaded, which it can be in many environments)
>   - the "real code" of nested functions has a different calling 
> convention than "real code" for non nested functions; it has an extra 
> parameter "somewhere", for the "static link"; in gcc C nested functions 
> on Cygwin/x86, this is in ecx

Again, this difference in calling convention is entirely independent of
whether M3 closures or trampolines are used.  They are different ways of
getting the environment pointer (ecx, on x86) loaded, before actually
transferring to the callee's code.

>  
> What do folks think about putting trampolines in executable garbage 
> collected heap?
> I think that's inefficient but I'm usually in the minority here 
> regarding the heap being inefficient.
>  
> One way or another, gcc makes C nested functions fairly portable, except 
> Apple's gcc on Darwin.
> Portability of -1 as a marker denoting "not code" is also dubious.
>  
> I think it stinks either way.
>  
> Anyone think coming up with "better" per-architecture markers is reasonable?

If we keep M3-style closures, the only architecture dependence is the value of
the marker word, that would be a dependence I could live with.  Trampolines,
in contrast, would have target opcodes in them, the bit layout of the trampoline
would vary, and the two pointers would almost surely be unaligned on many targets,
making m3gdb's job a lot harder.

>  
>  - Jay
> 
> ------------------------------------------------------------------------
> 
>  > Date: Mon, 26 May 2008 15:47:53 -0500
>  > From: rodney.bates at wichita.edu
>  > To: m3devel at elegosoft.com
>  > Subject: Re: [M3devel] function pointers and comparison to nil? 
> mis-typed function pointers?
>  >
>  >
>  >
>  > Jay wrote:
>  > > It stinks either way imho.
>  > > The portability is handled, somehow or another, by gcc's support for
>  > > nested functions.
>  > > For example on OpenBSD, they call mprotect to make the trampoline
>  > > executable -- expensive! and leaves a bit of a security hole.
>  > > On Linux you can sometimes mark the .exe as needing an executable 
> stack
>  > > or not. Similarly on Windows, linker has /nxcompat, /nxcompat:no 
> switch.
>  > > ATL on Windows puts trampolines in the heap and specifically makes 
> them
>  > > executable -- since the heap isn't necessarily executable either.
>  > > The -1 marker is also a bit of a portability problem but I guess in
>  > > practise it works out.
>  >
>  > Using trampolines would make this problem worse, perhaps much worse.
>  > Mistaking the function's real code for a closure is a lot less likely
>  > than mistaking the function's real code for a trampoline. A trampoline
>  > is, after all, always valid machine code on the executing processor.
>  > Not necessarily so for -1.
>  >
>  > > I'd be curious to see how it decodes on various processors.
>  > >
>  > > - Jay
>  > >
>  > --
>  > -------------------------------------------------------------
>  > Rodney M. Bates, retired assistant professor
>  > Dept. of Computer Science, Wichita State University
>  > Wichita, KS 67260-0083
>  > 316-978-3922
>  > rodney.bates at wichita.edu
> 

-- 
-------------------------------------------------------------
Rodney M. Bates, retired assistant professor
Dept. of Computer Science, Wichita State University
Wichita, KS 67260-0083
316-978-3922
rodney.bates at wichita.edu