Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site amdcad.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!amdcad!tim
From: tim@amdcad.UUCP (Tim Olson)
Newsgroups: net.arch
Subject: Re: Addressing modes (1702)
Message-ID: <10693@amdcad.UUCP>
Date: Sun, 16-Mar-86 16:05:30 EST
Article-I.D.: amdcad.10693
Posted: Sun Mar 16 16:05:30 1986
Date-Received: Mon, 17-Mar-86 04:25:58 EST
References: <187@anwar.UUCP> <1161@mmintl.UUCP> <460@ccivax.UUCP>
Organization: AMDCAD, Sunnyvale, CA
Lines: 57
Summary: "RISCness" of the 1802

In article <460@ccivax.UUCP>, rb@ccivax.UUCP (rex ballard) writes:
> For any who might remember the RCA 1702 COSMAC VIP computer, there was
> a strange way to get immediate addressing.  The VIP would let you switch
> which register would work as a program counter and when that register
> was used for instruction fetches or anything else, it would cause the
> register to be incremented.  If R7 was your PC register, you could say
> MOV R6,(R7), and the result was the same as move imediate instruction,
> because R7 would be incremented automatically.
> This may have been a bug, but it was a useful bug (All instructions
> had to be a uniform number of cycles, and immediate mode took too many
> cycles).  Actually, the 1702 had a lot of "cute" features, it would be
> interesting to see a 32 bit version.  Does anybody familiar with this
> chip consider it RISC?  It was certainly a good learning tool.

	I don't remember a 1702, but it sounds much like the RCA 1802.  This
processor had sixteen 16-bit general purpose registers, which could also be
used as thirty-two 8-bit registers.  However, except for INC and DEC, all
operations (including moves) had to be performed 8 bits at a time using the
accumulator.  Two 4-bit registers, P and X, pointed to the general-purpose
registers to be used for the program counter and index register, respectively.

	There were a few things that made the 1802 sort of "RISC-like".  One
was the large number of general-purpose registers available.  Another was the
small number of addressing modes: loads and stores were either register
indirect or implied ("double-indirect" through the 4-bit X register), and all
arithmetic and logical operations were performed using the accumulator (D) and
an implied (double-indirect through X) memory operand.  Note that the registers
could NOT be used as operands in arithmetic or logical operations! :-( 

	Another interesting feature was the absence of a subroutine call
instruction.  Instead, coroutines were implemented, each with a separate
program counter.  To call a coroutine, the P register was simply changed to
point to the new program counter register.  A subroutine was a coroutine that
ran to completion, then jumped to an SEP (set P register) instruction just
before the subroutine entry point.  This instruction "returned" to the calling
procedure, incrementing the subroutine's program counter to point to the entry
point again.  This coroutine method also made for fast interrupt handling.
The interrupt handler had a dedicated program counter (register 1).  When an
interrupt occurred, the 4-bit P and X registers were copied into an 8-bit 
T register, then P was forced to 1.  A return instruction copied back the P and
X registers.  In both these cases (subroutines and interrupts), only the basic
primitives were supplied; the user could build the required subroutine call or
interrupt convention from them, using these building blocks.  This approach of
building complex instructions from simple primatives can also be viewed as
"RISC-like".

	All of these "double-indirect" operations had a cost, however.  Most
instructions took 16 clock cycles to execute (8 for instruction fetch, 8 for
execution), and a few took 24.  To build a competitive 32-bit, single-cycle,
pipelined RISC machine using this architecture would require a lot of
complexity, especially in the register file, which would have to be a 7-port,
4-read, 3-write structure!  The 1802 certainly had some interesting concepts
for its time, however.

	Tim Olson
	Advanced Micro Devices
	ihnp4!amdcad!tim