🚀 go-pugleaf

maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:

>reindorf@us-es.sel.de (Charles Reindorf) writes:
>>Some people say that they "don't like" trampolenes, but don't seem to give any
>>reason for it. 
>
>	Separation of code and data is an important machine
>principle for safety. Some machines (all the good ones :-) do not
>allow executing things in the data area.

That in itself is not a problem, so long as you are allowed to modify
things in the code area ;-)

Seriously, trampolines are not in the least bit unsafe.
Being able to modify the code area can in general be "unsafe", but then there
are many other things that are unsafe: pointers, array indexing,
dynamic allocation, unions, etc. etc.
Do these same hand-holding operating systems only allow you to program in
Ada? (Just kidding :-)

>	Trampolines feel a bit like the Cobol ALTER statement:
>dangerous hacks.

So do these same operating systems prevent efficient implementations of the
COBOL ALTER statement?

>>The main objection I can see is that on some operating systems
>>you are not allowed to do any run-time code generation. 
>
>	Some OS may not grant the user the priviledges required
>to generate and execute code on the fly. This is because
>it is close to 'self-modifying' code, which is not
>generally considered very safe.

Again, why is this less safe than, say, using function pointers?

>>But there again, in 
>>these architectures there do exist other, 
>>addmittedly less efficient workarounds
>>to this problem, surely.
>
>	Such as? I would LOVE to hear of one that did not require
>the standard C/C++ function pointers to double in size.

An approach that doesn't require the ability
to write to code space at runtime is as follows:
	At compile time, the programmer must specify the maximum depth
	of the trampoline stack.
	The compiler allocates space for N pairs of data+code pointers and
	writes out code for N trampolines each of which refer indirectly to the
	corresponding pair of pointers.
	Since these pointers are in the data area, they can be written
	to at runtime with no problem. The trampoline code itself does not
	have to be modified at runtime.

The only problem with this scheme is the requirement that you specify the
trampoline stack depth in advance.  Many systems, eg. DOS, have had this
requirement for the normal data stack, so people using inflexible
operating systems should be able to put up with it for the
trampoline stack.

If you can make the code for all the trampolines the same (eg. by reading the
IP or using IP-relative addressing to determine the location of the
corresponding pair of pointers in the data area) and you also have 
the ability to map a single code page to successive linearly
addressable locations, then you could dynamically extend the trampoline
stack, thus avoiding the need to specify the maximum size in advance.

>>... This
>>surely makes member function closures an impracticable and unworkable addition
>>to the language?
>
>	No, one can just leave it up to the user to delete the
>trampoline---as for other dynamically allocated objects.

This would require an extension to the language, whereas so far what we
have just been discussing only requires relaxing some restrictions.
What syntax would you use for allocating and deallocating member function
closures?

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!