[comp.arch] incremental compilation and code as data

henry@utzoo.uucp (Henry Spencer) (05/02/89)

In article <46500061@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
>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...

Without having seen the discussion, that I recall, I think Doug's views
are probably being misrepresented here.  What he probably was saying was
not that it's a bad idea, but that not all machines do it, and the ones
that do it often have private wrinkles in just how it should be done,
so *relying* on it is a bad idea.

Incremental compilation is clearly important for a general-purpose machine.
But not everybody realized that, and not everybody was originally trying
to build general-purpose machines.
-- 
Mars in 1980s:  USSR, 2 tries, |     Henry Spencer at U of Toronto Zoology
2 failures; USA, 0 tries.      | uunet!attcan!utzoo!henry henry@zoo.toronto.edu

dave@lethe.UUCP (Dave Collier-Brown) (05/03/89)

In article <46500061@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes:
| 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. 
 
In article <1989May1.213448.11347@utzoo.uucp> henry@utzoo.uucp (Henry
| Spencer) writes: Without having seen the discussion, that I recall, I
| think Doug's views are probably being misrepresented here. What he
| probably was saying was not that it's a bad idea, but that not all
| machines do it, and the ones that do it often have private wrinkles in
| just how it should be done, so *relying* on it is a bad idea. 
| Incremental compilation is clearly important for a general-purpose
| machine. But not everybody realized that, and not everybody was
| originally trying to build general-purpose machines.

  Well, one part of the problem will have to be dealt with by
anyone who wants to provide "public" or "shared" libraries in their
version of Unix.  The other part has been dealt with by people who
wish to debug running programs.
  Regrettably, each problem has been solved (various ways) is isolation.
Net result? "Ya kent git there from here. Ya got `t go back to Boston and
start out on the other side of the river".

  By the way, you probebly don't need to access the memory as both code and
data at the **same time** unless you actually intend to debug or test
interactively. You might look at lisp implementations as an example of
solutions to the problems, as even Multics Lisp could be a mixture
of compiled and interpreted code.  And that was a **while** ago!

--dave (wheels reinvented while you wait) c-b
-- 
David Collier-Brown,  | {toronto area...}lethe!dave
72 Abitibi Ave.,      |  Joyce C-B:
Willowdale, Ontario,  |     He's so smart he's dumb.
CANADA. 223-8968      |