Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ll-xn!ames!necntc!pec
From: pec@necntc.NEC.COM (Paul Cohen)
Newsgroups: comp.arch
Subject: Re: Japanese 32-bit CPUs ( NEC V70 )
Message-ID: <4016@necntc.NEC.COM>
Date: Wed, 6-May-87 10:27:27 EDT
Article-I.D.: necntc.4016
Posted: Wed May  6 10:27:27 1987
Date-Received: Sat, 9-May-87 00:45:44 EDT
References: <3810030@nucsrl.UUCP> <491@necis.UUCP> <3530@spool.WISC.EDU>
Reply-To: pec@necntc.UUCP (Paul Cohen)
Organization: NEC Electronics Inc.  Natick, MA 01760
Lines: 81
Keywords: V60, V70

In article <1157@cottage.WISC.EDU> lm@cottage.WISC.EDU (Larry McVoy) writes:

>In article <491@necis.UUCP> geo@necis.UUCP (George Aguiar ext. 219) writes:
>>The V-70 looks like a hell-of-a-chip.  Some other misc. hype:

>>	- 32 General Registers ( all 32 bits of course )
>>	- Symmetric Instruction Set
>>	- 20 Addressing modes

Actually there are 21 addressing modes for addressing bytes.  Eighteen
of these addressing modes can also be used for addressing bits.

>>	- Variable Byte Length Format

>Ummm, not to rain on your parade or anything - but I have real problems with 
>the last two.  20 addressing modes?  That's a lot of logic.  And I'll bet
>they support stuff like embedded displacements in the instruction stream (I'm
>not talking about 4 bit constants, I'm talking about things like National 
>and Motorola do with the top bits of their byte, word, and long word 
>displacements).  That can cost you - you might not know off the top how long
>the instruction is so your decoder might start decoding the previous 
>instructions displacement(s).

The V60/V70 instruction set uses orthogonal encodings.  From the first 
byte the decoder can determine the number of operands and where the operand
encodings begin.  The operands themselves are encoded separately 
(orthogonally) and may vary considerably in size.  No doubt this increases
the complexity of the decoder, but it also improves code density (the
importance of this is not primarily to save on memory space but so that
it is not necessary to fetch as much code).  

As an example, consider the following COMPILED C code for the V60/V70:


		_______________________________________________
		| struct sttyp {
		|	unsigned first, second, third;
		|	struct sttyp *fourth;
		|	double fifth, a,b,c,d,e;} *stru
C code:		|
		|
		| stru->fourth->fourth->third = 2;
		|==============================================
		| mov.w _stru+0xc,r0	# &(stru->fourth) in R0
Assembly Code:	|
		| mov.w #2,0x8[0xc[r0]]	# stru->fourth->
		|			#    fourth->third = 2;
		|______________________________________________
		

No doubt about it, the V70 is a complex chip; it is also fast.  It packs 
a great deal of functionality to provide high performance at a reasonable 
cost in a real system.  

>It looks like the 29K may have made some smart moves....

It depends on its objectives.  The 29K requires two separate
paths to memory, one for code and another for data.  The memory must be
extremely fast (read expensive) to service the CPU without wait states.
It also expects some specialized bus monitoring hardware in the memory
system:  

  >From: tim@amdcad.AMD.COM (Tim Olson)
  >Subject: Re: AM29000 memory management (was flame)

  >The "best" place for the referenced and changed bits, however, are in 
  >an external memory array, which "watches" the bus and automatically 
  >updates the R & C bits.  This array can also be read from or written
  >to via I/O space to read or clear the bits.

Also, taking advantage of the AMD RISC style architecture places some
uncomfortable demands on compiler developers.

I'm not knocking the AMD part.  It is an interesting processor and I'll
be interested in seeing what it does in a real system but I'll also be
interested in seeing what such a system costs.

If system cost does is no concern to you then disregard my comments but 
if a good cost/performance ratio seems important to you (not to mention 
V30 software compatibility) I suggest that you take another look at the 
V70 and the V60.