Xref: utzoo comp.lang.c:11542 comp.arch:5761
Path: utzoo!utgpu!attcan!uunet!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.lang.c,comp.arch
Subject: Re: Self-modifying code
Message-ID: <485@m3.mfci.UUCP>
Date: 28 Jul 88 16:53:09 GMT
References: <5262@june.cs.washington.edu> <260@thor.wright.EDU> <479@m3.mfci.UUCP>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 52

In article <61781@sun.uucp> guy@gorodish.Sun.COM (Guy Harris) writes:
[Guy, how come you always delete the previous correspondent's name?
Are you trying to save me embarrassment?]

[lots of interesting questions and points to ponder removed...I think
this forum has run out of gas on a topic this complex, so in true
Usenet style I'm going to pick nits instead.  I'll try to get back to 
your 432 questions when I get a chance.]

>I'm certainly willing to believe that there are applications now that could use
>a "protected" processor, but I'm not sure I'm willing to believe that there
>aren't applications that, at present, couldn't use a "protected" processor if
>it were 4x slower than a "conventional" one.  In this case, a useful question
>to ask might be "can I get the same level of protection with an adequate level
>of performance if I don't put all the protection in the instruction set?"

If you think of the 432 as merely a "protected processor" you've not
fully grasped what they created there.  It was an *environment*, of
which the central processor was just a component.  You, as a
programmer, did not see the 432 programming environment as a
processor running with a certain amount of memory, a set of
registers, some available OS calls, a certain type of virtual memory,
etc.  You the programmer were given a new universe in which all the
pieces obeyed the same rules, and the rules were simple and few and
not derived from hardward or language artifacts (by and large,
anyway).  I do not believe you can get this environment piecemeal.
(But you can get closer to it than we currently are, and we probably
agree on both the feasibility and desireability of this.)

>(BTW, I infer from the paper "Engineering a RISC Compiler System", by some
>people at MIPS, that their compiler can optimize register usage across
>procedure boundaries even when the calling and called procedures were
>separately compiled - they keep Ucode around for multiple compilation units, so
>that information for both calling and called procedure is available to the
>optimizer - so the claim made in "Fast Object-Oriented Procedure Calls:
>Lessons from the Intel 432" that "Clearly, the same approach (interprocedural
>register allocation) is inapplicable to separately compiled modules." is
>false.  It may be true in some cases - for example, if the modules are bound
>together at run time - but it is hardly clear that it is always true.  I
>believe David Wall has worked on link-time register allocation as well.)

We were talking about procedure calls made within an object-based
programming environment, and I don't think the claim is false.  In
such an environment you do not want to tie your parameter-passing
abstraction, with its expected runtime type-checking, to whatever
register convention happens to be the current fashion.  We didn't say
you couldn't do it -- we meant you don't want to.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090