Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/5/84; site mordor.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!mhuxn!mhuxr!ulysses!bellcore!decvax!decwrl!amdcad!lll-crg!mordor!ehj
From: ehj@mordor.UUCP (Eric H Jensen)
Newsgroups: net.arch
Subject: Re: Addressing modes (conditional branches)
Message-ID: <5681@mordor.UUCP>
Date: Wed, 26-Feb-86 17:16:10 EST
Article-I.D.: mordor.5681
Posted: Wed Feb 26 17:16:10 1986
Date-Received: Sat, 1-Mar-86 04:49:39 EST
References: <546@tekcrl.UUCP> <426@utastro.UUCP>
Reply-To: ehj@mordor.UUCP (Eric H Jensen)
Distribution: net
Organization: S-1 Project, LLNL
Lines: 53

In article <426@utastro.UUCP> nather@utastro.UUCP (Ed Nather) writes:
>In article <546@tekcrl.UUCP>, patc@tekcrl.UUCP (Pat Caudill) writes:
>> 	We now look down on self modifying code, but at that time
>> it was considered a great step forward. Ahh, those were the good old days.
>> 
>It will return; it's too neat an idea to stay dead.  What we lack is ...
>                            ... I was able to find no other way to meet
>the required conditions (animated display using a slow computer) and no
>one else has either -- though several have tried.

Let's hope it dosen't....

If you allow self-modifying code everyone would have to have a
seperate copy of their task.  Swap space is not that cheap - with a
lot of people running emacs and maybe a lisp underneath it, kiss your
swap area and probably system performance (unless you buy more main
memory) goodbye....   

I can't see how you could effectively manage a POLICY of
"self-modifying code is okay" in a statically linked environment.
Every sub-system that linked in a routine that modified its own code
would inherit the 'impure' curse.   Perhaps this would not be such
a problem in a dynamically linked environment.

Hardware-wise the key here is "... using a SLOW computer" (emphasis
mine).  Once a computer is targeted to perform above a certain level,
the design must resort to having separate instruction and data caches
(unless you can get those 3ns 16k rams that the Japanese are using in
a dual port configuration). A virtually addressed, read-only (the
piece of logic that writes it is the miss handler) icache (instruction
cache) is a very simple and compact design. Btw the icache is usually
in one of the critical paths of the machine - pc setup for branches.

A store into the icache is going to cost at the very least one dead
cycle unless more memory chips are added to play odd even games (i.e.
access the odd words while writing the even words) but now there is
more hair (defered writes) and possibly a sacrifice in speed (longer
logic paths).  A cache coherency problem also arises - the write to
the icache must also be reflected in the dcache (data cache).  I can
think of a number of approaches to this problem but either they are
messy or the create dead machine cycles (no computation takes place
while the update is made). In any event the design gets a lot larger
and it is dubious that any performance is gained.

I would opt for effcient indexed address modes and instructions that
keep the requirement for konstant operands to a minimum (i.e. the
amount to shift by for the shift instruction).  Aren't these the items
that made self modifing code passe?

-- 
eric h. jensen        (S1 Project @ Lawrence Livermore National Laboratory)
Phone: (415) 423-0229 USMail: LLNL, P.O. Box 5503, L-276, Livermore, Ca., 94550
ARPA:  ehj@angband    UUCP:   ...!decvax!decwrl!mordor!angband!ehj