🚀 go-pugleaf

I have been having a moderately heated (for Usenet, especially
for comp.lang.c) discussion with Doug Gwyn about architectures
(hardware or software) that prevent a given program from 
accessing the same information as both code and data. The context of
the discussion is that I want(ed) the ANSI C standard to REQUIRE
that one be able to access a given object as both data and code.
He seems to think that this is a "Bad Idea". I think it is not 
only a "Good Idea", but that it is vitally important to some of my
programs. I want to start a discussion here.

I am NOT - read my lips - referring to what is usually called
"self modifying code", but rather "incremental compilation".

What my programs do is to take user input in the form of arithmetic
expressions, usually moderately complicated ones, and convert them
by a simple compilation process into code. This code is then executed
repeatedly inside big loops of numerical integrators. Tests show that
using an interpreter scheme is essentially too slow. I could probably
use some sort of scheme like p-code, but even that would still be
slower than compilation.  Popular "compile and go" environments
like Turbo Pascal also seem to use this concept.

I would like to know why some designers would like to prohibit this.
I can not see ANY reason why it would be desirable to prevent it.
I can understand the reasons why it might take a system call at 
run time (like in OS/2) or a specific declaration at link time
(like in VMS) and why on some architectures (80286, 80386) one
would have to use two overlapped segments, and even why on some
machine there might need to be a cache flush. But I cannot see
any possible ADVANTAGE to the designer in preventing it - why
remove from the list of possible purchasers of your hardware or
OS those users who need it?

Is it just basically that some designers are rooted in the 
old fashioned "compile now, run later" philosophy that they can't
even conceive of this? That is the only RATIONAL answer I can think of.

Doug McDonald