[inforoots] bits again

[Michael Albaugh]

On 11/28/06, Ed Thelen <ed at ed-thelen.org> wrote:

> From: "Michael Albaugh" <m.e.albaugh at gmail.com>

> > I believe that the ability to execute an instruction from a register
> > pre-dates the B-Box, but could be wrong.
>
> I heard the Brits invented the "B-Box",

Manchester, IIRC.

>      later renamed "index register".

Possibly by IBM, who patented it in the US. This
led to both a nice revenue stream from the other
"major" computer makers, and a flowering of other
schemes to achieve the goal of variable addresses
without infringing, among the smaller players.
Indirect addressing fits well with small-word machines,
gives one the equivalent of "pointer" registers, and can
be as  nice as index registers, especially if one has moved
on past static allocation of data structures. Most modern
machines are more likely to have the form

(full-size base-address in register) + (smaller offset in instruction)

rather than the opposite. Because most modern architectures
afre far more likely to be referencing slots in a stack-frame,
or member variables of an object, than they are to be stepping
across the element of an array at a fixed address.


> > Also, subroutine linkage
> > by way of a single "return address" or "return jump" location pre-dates
> > the use of a stack for that purpose.
>
> Yes indeed, but most
>      Store P and Branch
>   type of  instructions modified the program by storing the incremented
>    P counter into the 1st word of the subroutine.

I have personally used machines with a wide variety of such
instructions, from purely software convention (store the
return address in the canonical place, then jump), to
the CDC 6x00 "Return Jump" instruction that stored
an actual jump instruction at the target. Smaller machines
tended to store only the address, and use a "jump with
indirect address" as a return. And some machines did
not have a programmer-accessible return-address register
(e.g. the 1620 "Branch and Transmit", which led to the
actual use of software convention). Some had an equally
invisible "return stack" (e.g. Intel 8008). You can imagine the
fun when an invisble pointer to an invisble stack overflowed.

Distinct outliers would include the NatSemi SCMP which
not only pre-incremented the PC (so you would store P, not
P+1), but basically swapped the PC with a pointer-reg.
Also the RCA 180[12], where any of the 16 registers could
be the PC. You selected which by settting a separate 4-bit
register, and the called function could just set it back
to the "normal" value. Of course, software nesting conventions
allowed more flexibility, whether via a bog-standard linear
array "stack", or a linked list of "activation records"

>    I figure this was self modifying code, because it did change
>    the contents of the subroutine - and prevented reentrancy.

I would consider it to be what I had numbered as (3) in my previous
message. "self modifying", but to a relatively mundane end, rather
than (4), actual extensibility of the program. Getting a bit far
afield, but you might also consider the relationship to purely
thread-safe code, which not only refrains from modifying itself,
but from modifying any globally-visible data.

   But that's another thread. :-)

>    A stack turned out to be a nicer way to call subroutines,
>     and allowed reentrancy.

The linked-list of activation records was even nicer, but did
not allow certain sorts of "unwarranted chumminess with the
compiler" that were the earmark of much 1970's programming.
Sigh.

  Mike


-- 
Keep in mind the experimental nature of gmail,
and the security implications.