Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #2391 > unrolled thread

Re: The Indexed Instruction Problem Solved!

Back to article view | Back to comp.arch

Contents

  Re: The Indexed Instruction Problem Solved! MitchAlsup <MitchAlsup@aol.com> - 2011-07-06 14:12 -0700
    Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-06 15:48 -0700
    Re: The Indexed Instruction Problem Solved! EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-06 20:36 -0400
    Re: The Indexed Instruction Problem Solved! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-06 23:29 -0700
      Re: The Indexed Instruction Problem Solved! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-06 23:31 -0700
        Re: The Indexed Instruction Problem Solved! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-06 23:38 -0700
          Re: The Indexed Instruction Problem Solved! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-06 23:39 -0700
            Re: The Indexed Instruction Problem Solved! timcaffrey@aol.com (Tim McCaffrey) - 2011-07-14 01:36 +0000
          Re: The Indexed Instruction Problem Solved! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-07-07 08:12 -0700
          Re: The Indexed Instruction Problem Solved! EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-07 12:24 -0400
            Re: The Indexed Instruction Problem Solved! John Levine <johnl@iecc.com> - 2011-07-08 01:29 +0000
              Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-07 18:53 -0700
                Re: The Indexed Instruction Problem Solved! John Levine <johnl@iecc.com> - 2011-07-08 02:17 +0000
              Re: The Indexed Instruction Problem Solved! EricP <ThatWouldBeTelling@thevillage.com> - 2011-07-09 13:15 -0400
                Re: The Indexed Instruction Problem Solved! John Levine <johnl@iecc.com> - 2011-07-09 18:37 +0000
                  Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-09 11:53 -0700
                    Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-09 11:55 -0700
                Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-09 11:49 -0700
                Re: The Indexed Instruction Problem Solved! Chris Jones <clj@panix.com> - 2011-07-09 16:21 -0400
          Re: The Indexed Instruction Problem Solved! Joe Chisolm <jchisolm6@earthlink.net> - 2011-07-07 13:19 -0500
            Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-07 12:11 -0700
            Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-07 12:13 -0700
              Re: The Indexed Instruction Problem Solved! jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-07 19:32 +0000
        Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-07 04:09 -0700
    Re: The Indexed Instruction Problem Solved! Brett Davis <ggtgp@yahoo.com> - 2011-07-12 18:31 -0500
      Re: The Indexed Instruction Problem Solved! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-13 22:31 -0700
      Re: The Indexed Instruction Problem Solved! mac <acolvin@efunct.com> - 2011-07-17 15:31 +0000
        Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-17 09:50 -0700
          Re: The Indexed Instruction Problem Solved! Andrew Reilly <areilly---@bigpond.net.au> - 2011-07-17 23:26 +0000
            Re: The Indexed Instruction Problem Solved! Brett Davis <ggtgp@yahoo.com> - 2011-07-17 19:52 -0500
            Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-17 18:22 -0700
              Re: The Indexed Instruction Problem Solved! "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-17 21:33 -0700
                Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-18 06:34 -0700
                  Re: The Indexed Instruction Problem Solved! Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-07-18 09:22 -0700
                Re: The Indexed Instruction Problem Solved! nmm1@cam.ac.uk - 2011-07-18 14:13 +0100
                  Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-18 07:27 -0700
                    Re: The Indexed Instruction Problem Solved! nmm1@cam.ac.uk - 2011-07-18 16:22 +0100
                      Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-18 09:56 -0700
                        Re: The Indexed Instruction Problem Solved! nmm1@cam.ac.uk - 2011-07-18 17:43 +0100
                          Re: The Indexed Instruction Problem Solved! Quadibloc <jsavard@ecn.ab.ca> - 2011-07-18 14:58 -0700
                            Re: The Indexed Instruction Problem Solved! nmm1@cam.ac.uk - 2011-07-19 07:22 +0100

Page 1 of 3  [1] 2 3  Next page →

#2391 — Re: The Indexed Instruction Problem Solved!

On Tuesday, July 5, 2011 5:58:12 PM UTC-5, Quadibloc wrote:
> But I'm surprised that the 68020 and the VAX are not included among
> those that "got it right", because I was pretty sure they did have
> full base + index + displacement addressing.

In the case of the 68020, while id did have a useful set of addressing modes, their performance was lower than not using the addressing modes. That is microcoded addressing modes were slower than more instructions being used.

PDP-11, VAX, 68K family, National 32K family all got the auto-increment and autodecrement wrong:: in that in many codes there are as many postdecrements as there are predecrements. Favoring one over the others is problematic (even though these directly support stack structures.

>                                               The 360 had a short
> displacement, and unlike other architectures (including the 68020),
> there was no option to implicitly shift the index register left to
> match the data item size. 

I basically want all address modes to take the same amount of time in the address generation pipeline.

The 360 is only burdened with 12-bit positive only offsets, and we saw a significant benefit to 16-bit +/- offsets in the RISC days; and it was not until the x86-64 days that I became fully aware of how powerful the x86 instruction set was when powered by multiple full width instruction decoders (that give the property of the previous paragraph).

In a RICS-like instruction set one must fundamentally choose the width of the offset field (typically 16 but occasionally something strange like 13). Not so with a x86-like instruction set and offsets (n.e. displacements) can be 8, 16, 32 bits wide dynamically selected by modes and prefix codes. But they all retain the "take the same time" property in the address generation stage.

I suspect that a modern VAX-like instruction set with a tripple ported data cache could be facillitated to have the necessary property that all address generations take the same amount of time (by dropping the indirect modes, and leaving out the COBOL support instructions.) VAX was HEAVILY burdened <to its demise> with the high overhead CALL/RET instructions.

Mitch

[toc] | [next] | [standalone]

#2392

On Jul 6, 3:12 pm, MitchAlsup <MitchAl...@aol.com> wrote:

> The 360 is only burdened with 12-bit positive only offsets,

Ah. While I found 12-bit offsets to be a problem, my imaginary
architecture has 16-bit positive-only offsets. I noticed that offsets
could be negative on the 68000, and considered that the waste of a
good bit.

After all, one can always subtract what one wishes *from* the offset
in an instruction, but loading the base register with the starting
address of a program segment instead of that address plus 32,768 just
seems so much easier to understand. My goal was to optimize the
_usual_ use of a base register, not provide facilities that might lend
themselves to creative uses.

John Savard

[toc] | [prev] | [next] | [standalone]

#2394

MitchAlsup wrote:
> On Tuesday, July 5, 2011 5:58:12 PM UTC-5, Quadibloc wrote:
>> But I'm surprised that the 68020 and the VAX are not included among
>> those that "got it right", because I was pretty sure they did have
>> full base + index + displacement addressing.
> 
> In the case of the 68020, while id did have a useful set of addressing modes, their performance was lower than not using the addressing modes. That is microcoded addressing modes were slower than more instructions being used.
> 
> PDP-11, VAX, 68K family, National 32K family all got the auto-increment and autodecrement wrong:: in that in many codes there are as many postdecrements as there are predecrements. Favoring one over the others is problematic (even though these directly support stack structures.

In my instruction set designs I usually include an 'add dest, tiny_constant'.
If the ISA has 16 registers then a tiny value is a 4 bit constant with
the values -8..-1, +1..+8 (no zero value for tiny constants).

I envisioned this implemented by sign extending the 4 bit field,
and routing sign bit (bit 3) back, complementing it, and feeding
it back in as a carry_in to the address adder.

sign extend <-- b3 b2 b1 b0<-carry_in<-
                  |                    |
                  >-not---------------->

=====================================================
I envisioned this would be handled in a compiler by just generating
<ADD dest, const> instructions as needed, then using a bog-standard
LALR0 peephole optimizer to optimize for the ISA.

If the const value fits into a tiny value, use that.
If const is 1/-1 and there are INC or DEC instructions use them.
If an addressing instruction is preceeded/followed by an add/sub const 1/2/4
and there are pre-dec/post-inc for B/W/D, then fold the instructions together.

So the auto inc/dec address modes get used when available in a ISA,
else the most appropriate inc/dec/add_constant.

So whether an ISA favored auto-preincrement and auto postdecrement or
how constants are implemented would just be a peephole optimizer issue.

Eric

[toc] | [prev] | [next] | [standalone]

#2398

On 7/6/2011 2:12 PM, MitchAlsup wrote:
> On Tuesday, July 5, 2011 5:58:12 PM UTC-5, Quadibloc wrote:
>> But I'm surprised that the 68020 and the VAX are not included among
>> those that "got it right", because I was pretty sure they did have
>> full base + index + displacement addressing.
>
> In the case of the 68020, while id did have a useful set of addressing modes, their performance was lower than not using the addressing modes. That is microcoded addressing modes were slower than more instructions being used.

This is why I called my undergrad computer project RAMM/RISC/SEISM,
where RAMM stood for "Reduced Addressing Mode Machine".

(I never bought in to the RISC deprecation of divide or FP.)


> PDP-11, VAX, 68K family, National 32K family all got the auto-increment and autodecrement wrong:: in that in many codes there are as many postdecrements as there are predecrements. Favoring one over the others is problematic (even though these directly support stack structures.

Except that pre-increment/decre more general form:

mem_reference[  address_reg := address_reg+scale*index_reg + offset ]

is a form of CSE (Common Subexpression Elimination), saving the result 
of the address calculatgion for future use,
whereas post-incrementdecrement is not.

Even if you think of it as

mem_reference[  (old = address_reg,
                 address_reg = address_reg+scale*index_reg + offset,
                 old)
              ]

it still costs more hardware - another bus to carry the address, as well 
as the writeback.


>
>>                                                The 360 had a short
>> displacement, and unlike other architectures (including the 68020),
>> there was no option to implicitly shift the index register left to
>> match the data item size.
>
> I basically want all address modes to take the same amount of time in the address generation pipeline.
>
> The 360 is only burdened with 12-bit positive only offsets, and we saw a significant benefit to 16-bit +/- offsets in the RISC days; and it was not until the x86-64 days that I became fully aware of how powerful the x86 instruction set was when powered by multiple full width instruction decoders (that give the property of the previous paragraph).
>
> In a RICS-like instruction set one must fundamentally choose the width of the offset field (typically 16 but occasionally something strange like 13). Not so with a x86-like instruction set and offsets (n.e. displacements) can be 8, 16, 32 bits wide dynamically selected by modes and prefix codes. But they all retain the "take the same time" property in the address generation stage.
>
> I suspect that a modern VAX-like instruction set with a tripple ported data cache could be facillitated to have the necessary property that all address generations take the same amount of time (by dropping the indirect modes, and leaving out the COBOL support instructions.) VAX was HEAVILY burdened<to its demise>  with the high overhead CALL/RET instructions.
>
> Mitch

[toc] | [prev] | [next] | [standalone]

#2399

On 7/6/2011 11:29 PM, Andy "Krazy" Glew wrote:
> On 7/6/2011 2:12 PM, MitchAlsup wrote:

>
>> PDP-11, VAX, 68K family, National 32K family all got the
>> auto-increment and autodecrement wrong:: in that in many codes there
>> are as many postdecrements as there are predecrements. Favoring one
>> over the others is problematic (even though these directly support
>> stack structures.
>
> Except that pre-increment/decre more general form:
>
> mem_reference[ address_reg := address_reg+scale*index_reg + offset ]
>
> is a form of CSE (Common Subexpression Elimination), saving the result
> of the address calculatgion for future use,
> whereas post-incrementdecrement is not.


http://semipublic.comp-arch.net/wiki/Address_Generation_Writeback


= Hardware Motivation for Address Register Modifying Addressing Modes =

Apart from the software datastructure motivation,
there is a hardware motivation for addressing modes such as 
pre-increment or decrement.

In more generality - addressing modes that calculate an address, and 
then save the results of that calculation
in a register - typically one of the registers involved in the 
addressing mode.

Consider [[Mitch Alsup's Favorite Addressing Mode]],
the x86's [[Base+Scaled-Index+Offset]].

A succession of such instructions might look like:

;an [[RMW]]
   r1 := load( M[ rB+rO*4+offset1 ] )
   r1 := ... some calculation involving r1 ...
   store( M[ rB+rO*4+offset1 ] := r1 )

or

; nearby loads
   r1 := load( M[ rB+rO*4+offset1 ] )
   r2 := load( M[ rB+rO*4+offset2 ] )
   r3 := load( M[ rB+rO*4+offset3 ] )

Notice the possibility of [[CSE (Common Subexpression Elimination)]]:

For the [[RMW]] case, this is straightforward:

   rAtmp := [[lea]]( M[ rB+rO*4+offset1 ] )
   r1 := load( rAtmp ] )
   r1 := ... some calculation involving r1 ...
   store( M[ rAtmp ] := r1 )

Is this a win? It depends:
* in terms of performance, on a classic RISC, probably note: the extra 
instruction adds latency, probably costs a cycle.
* in terms of power, possibly

For the nearby load case, we could do:

   rAtmp := lea( M[ rB+rO*4 ] )
   r1 := load( M[ rAtmp+offset1 ] )
   r2 := load( M[ rAtmp*4+offset2 ] )
   r3 := load( M[ rAtmp*4+offset3 ] )

or

   rAtmp := lea( M[ rB+rO*4+offset1 ] )
   r1 := load( M[ rAtmp ] )
   r2 := load( M[ rAtmp*4+(offset2-offset1) ] )
   r3 := load( M[ rAtmp*4+(offset3-offset1) ] )

Is this a win? Again, it depends:
* probably not in performance
* possibly in terms of power.

<UL>
As an aside, let me note that if the base address rB+rO*4 is aligned,
then the subsequent addresses could use [[OR indexing]] rather than 
[[ADD indexing]].
Which may further save power.
At the cost of yet another piece of crap in the instruction set.
</UL>

To avoid conundrums like this - is it better to [[CSE]] the addressing 
mode or not?
- processors like the [[AMD 29K]]
abandoned addressing modes except for [[absolute addressing mode]] and 
[[register indirect addressing mode]]
- so to form any nomn-trivial address you had to save the results to a 
register, and thereby were
encouraged to CSE it whenever possible.

Generalized pre-increment/decrement is a less RISCy approach to this.
Instead of encouraging CSE via separate instructions,
it encourages CSE by making it "free" to save the result ofthe 
addressing mode calculation.

:Let's call this [[Address Generation Saving]], or, if it modifies a 
register used in the addressing mode, [[Address Register Modification]]:

In our examples:

;RMW
   rAtmp := [[lea]]( M[ rB+rO*4+offset1 ] )
   r1 := load( rAtmp := rB+rO*4+offset1 ] )
   r1 := ... some calculation involving r1 ...
   store( M[ rAtmp ] := r1 )

; nearby load
   r1 := load( M[ rAtnp :=rB+rO*4+offset1 ] )
   r2 := load( M[ rAtmp*4+(offset2-offset1) ] )
   r3 := load( M[ rAtmp*4+(offset3-offset1) ] )

Note  that the nearby case that changes the offsets is simpler than the 
nearby case that saves only part ofthe address calculation:

;Using C's comma expression:
   r1 := load( M[ (rAtmp := rB+rO*4, rAtmp+offset1) ] )
   r2 := load( M[ rAtmp*4+offset2 ] )
   r3 := load( M[ rAtmp*4+offset3 ] )

:: Again, [[OR indexing]] may benefit, for addressing mode 
[[(Base+Scaled-Index)}Offset]]

What is the probem with this?
* Writeback ports

Such an [[Address Generation Saving]] requires an extra writeback port, 
in addition to the result of an instruction like load.

For this reason, some instruction sets have proposed to NOT have 
[[address generation writeback]] for instructions that write other 
results, such as load,
but only to have [[address generation writeback]] for instructions that 
do not have a normal writeback, such as a store.

: Glew opinion: workable, minor benefit, but ugly.

Except that pre-increment/decre more general form:

Post-increment and decrement goes further, generalized in this way:
then the address calculation looks like

    { old := address_reg; address_reg := new_address; return old }

Not only does this require a writeback port for the updated address 
register,
but it also requires two paths from the AGU or RF to where the address 
is used
- one for the address, the other for the updated address_reg.

OVERALL OBSERVATION:  addressing modes begin the slippery slope to VLIW.

[toc] | [prev] | [next] | [standalone]

#2400

By the way, I am also collecting addressing modes for a different article.

The standard ones.

But especially the less standard address modes, such as

* Double Indirect  M[ M[reg+offset] +offset ]
      which I suggested long ago back in the days of AI architectures,
      as an optimization for "handles"

      along with a doubly indirect cache,
      to eliminate the pointer dereferencing.


What other blasts from the past?  VAX and M68K and NS32K...

[toc] | [prev] | [next] | [standalone]

#2401

On 7/6/2011 11:38 PM, Andy "Krazy" Glew wrote:
> By the way, I am also collecting addressing modes for a different article.
>
> The standard ones.
>
> But especially the less standard address modes, such as
>
> * Double Indirect M[ M[reg+offset] +offset ]
> which I suggested long ago back in the days of AI architectures,
> as an optimization for "handles"
>
> along with a doubly indirect cache,
> to eliminate the pointer dereferencing.
>
>
> What other blasts from the past? VAX and M68K and NS32K...




I'm also collecting instructions - although I have a list started that I 
have been meaning to post.

Realized just now that I had forgotten LEA.

[toc] | [prev] | [next] | [standalone]

#2506

In article <4E155490.70503@SPAM.comp-arch.net>, andy@SPAM.comp-arch.net 
says...
>
>On 7/6/2011 11:38 PM, Andy "Krazy" Glew wrote:
>> By the way, I am also collecting addressing modes for a different article.
>>
>> The standard ones.
>>
>> But especially the less standard address modes, such as
>>
>> * Double Indirect M[ M[reg+offset] +offset ]
>> which I suggested long ago back in the days of AI architectures,
>> as an optimization for "handles"
>>
>> along with a doubly indirect cache,
>> to eliminate the pointer dereferencing.
>>
>>
>> What other blasts from the past? VAX and M68K and NS32K...
>
>
>
>
>I'm also collecting instructions - although I have a list started that I 
>have been meaning to post.
>
>Realized just now that I had forgotten LEA.

Don't forget the 68000 PUSHEA

	- Tim

[toc] | [prev] | [next] | [standalone]

#2408

On 7/6/2011 11:38 PM, Andy "Krazy" Glew wrote:
> By the way, I am also collecting addressing modes for a different article.
>
> The standard ones.
>
> But especially the less standard address modes, such as
>
> * Double Indirect M[ M[reg+offset] +offset ]
> which I suggested long ago back in the days of AI architectures,
> as an optimization for "handles"
>
> along with a doubly indirect cache,
> to eliminate the pointer dereferencing.
>
>
> What other blasts from the past? VAX and M68K and NS32K...

If you are trying for a pretty complete list, don't forget the various 
forms of indirect addressing used in older systems.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

#2409

Andy "Krazy" Glew wrote:
> By the way, I am also collecting addressing modes for a different article.
> 
> The standard ones.
> 
> But especially the less standard address modes, such as
> 
> * Double Indirect  M[ M[reg+offset] +offset ]
>      which I suggested long ago back in the days of AI architectures,
>      as an optimization for "handles"
> 
>      along with a doubly indirect cache,
>      to eliminate the pointer dereferencing.
> 
> 
> What other blasts from the past?  VAX and M68K and NS32K...

Data General Nova:
32k of 16 bit words (word address only).
lsb of address says whether referenced value is
0=data or 1=indirect address (loop ad infinitum)

from Nova programmers manual:

Effective Address Calculation

There are six instructions in the NOVA line instruction
set that directly reference memory using word addressing.
These instructions use eleven bits in the instruction to
define the address of the desired word. These eleven bits
do not directly specify the address, but are used in a
calculation which results in the address of the desired word.
The resultant address is called the "effective address" or "E" ,
and the calculation is called "effective address calculation".

The eleven bits in an instruction that are used in the effective
address calculation, are bits 5-15. Their format is shown below.

   ooooo@iidddddddd
   0123456789012345

   o = opcode bits
   @ = indirect bit
   i = index register bits
   d = displacement bits

If the index bits are 00, the displacement is used as an unsigned
8-bit number to address one of the first 256 words in memory.
This is called "page zero addressing" and this first block of 256
words is known as "page zero".

If the index bits are 01, the displacement is treated as a signed,
two's complement number, which is added to the address of the instruction
address to produce a memory address. This is called "relative addressing".
By relative addressing, any instruction which uses the effective address
calculation can directly address any word in storage whose address is in
the range -128 to +l27 from the instruction.

If the index bits are 10, accumulator 2 is used as an index register.
If the index bits are 11, accumulator 3 is used as an index register.
In this form of word addressing, known as "index register addressing",
the displacement is treated as a signed, two's complement number which
is added to the contents of the selected index register to produce a
memory address. In index register addressing, the addition of the
displacement to the contents of index register does not change the
value contained in the index register.

The result of the addition performed in relative addressing and
index register addressing is "clipped" to 15 bits. In other words,
the high-order bit of the result is set to O. For example,
if accumulator 2 is to be used as an index register and contains
the number 077774, and the displacement bits contain the number 012,
then the result of the addition would be 000006, not 100006.

After one of the three types of addresses has been computed
from the index and displacement bits, the indirect bit is tested.
If this bit is zero, the address already computed is taken as the
effective address. If the indirect bit is one, the word addressed
by the result of the index and displacement bits is assumed to
contain an address. In this word bit 0 is the indirect bit and
bits 1-15 contain an address. If bit 0 of the referenced word is 1,
another level of indirection is indicated, and bits 1-15 contain
the address of the next word in the indirection chain.
The processor will continue to follow this chain of indirect
addresses until a word is retrieved with bit 0 set to 0.
Bits 1-15 of this word are taken to be the effective address.

If an indirect address points to a location in the range
20-27 (auto-increment locations), that word is fetched,
the contents of the word are incremented by one and written
back into the location. This updated value is then used to continue
the addressing chain. If an indirect address points to a location in
the range 30-37 (auto—decrement locations), that word is fetched,
the contents of the word are decremented by one and written back into the
location. The updated value is then used to continue the addressing chain.

NOTE When referencing auto-increment and auto-decrement locations,
the state of bit 0 before the increment or decrement is the condition
upon which the continuation of the indirection chain is based.
For example: if an auto-increment location contains 177777,
and the location is referenced as part of an indirection chain,
location 0 will be the next address in the chain.

Eric

[toc] | [prev] | [next] | [standalone]

#2418

>> What other blasts from the past?  VAX and M68K and NS32K...
>
>Data General Nova:
>32k of 16 bit words (word address only).
>lsb of address says whether referenced value is
>0=data or 1=indirect address (loop ad infinitum)

The Nova was basically a souped up PDP-8 or PDP-9.  DEC decided to use
Gordon Bell's much more radical architecture for the 16 bit PDP-11, so
designer Ed Decastro went off and started his own minicomputer
company.

On the 12-bit PDP-5 and PDP-8, there were 7 bits of address in the 12
bit instruction, a page bit which said whether the address was in the
current 128 word memory page or page zero, and an indirect bit which
said to use the addressed word as a pointer.  Locations 10-17 (octal)
were auto-increment, preincremented if you used them as an indirect
address.  That was very handy, and we always thought carefully about
what to put there.  The 18-bit PDP-7 and PDP-9 were pretty much the
same with 18 bit words and bigger addresses, the PDP-15 was a PDP-9
with an index register, implemented in MSI rather than SSI.

R's,
John

[toc] | [prev] | [next] | [standalone]

#2419

On Jul 7, 7:29 pm, John Levine <jo...@iecc.com> wrote:

> The Nova was basically a souped up PDP-8 or PDP-9.  DEC decided to use
> Gordon Bell's much more radical architecture for the 16 bit PDP-11, so
> designer Ed Decastro went off and started his own minicomputer
> company.

It's true enough that DEC used a different architecture, proposed by
Gordon Bell, than that which became the architecture of the Nova.

But the HP 2114/2116 architecture, or the Honeywell 316/516
architectures... *those* could fairly be called architectures that
were basically the same as that of the PDP-5/8 or the PDP-4/7/9/15.

The architecture of the Nova might not have been quite as radical an
advance as that of the PDP-11, but it still was significantly
different from that kind of architecture.

John Savard

[toc] | [prev] | [next] | [standalone]

#2421

>But the HP 2114/2116 architecture, or the Honeywell 316/516
>architectures... *those* could fairly be called architectures that
>were basically the same as that of the PDP-5/8 or the PDP-4/7/9/15.

Hey, I said the Nova was a souped up PDP-8/9. You're right, the
Honeywell machines basically took a PDP-8 and stuck some more
bits in the middle and added an index register.

>The architecture of the Nova might not have been quite as radical an
>advance as that of the PDP-11, but it still was significantly
>different from that kind of architecture.

It was an interesting design, the end of the line for word addresed
radial I/O minis, but as soon as it was evident that it was practical
to build a PDP-11, it was destined to win.

R's,
John

[toc] | [prev] | [next] | [standalone]

#2441

John Levine wrote:
>>> What other blasts from the past?  VAX and M68K and NS32K...
>> Data General Nova:
>> 32k of 16 bit words (word address only).
>> lsb of address says whether referenced value is
>> 0=data or 1=indirect address (loop ad infinitum)
> 
> The Nova was basically a souped up PDP-8 or PDP-9.  DEC decided to use
> Gordon Bell's much more radical architecture for the 16 bit PDP-11, so
> designer Ed Decastro went off and started his own minicomputer
> company.
> 
> On the 12-bit PDP-5 and PDP-8, there were 7 bits of address in the 12
> bit instruction, a page bit which said whether the address was in the
> current 128 word memory page or page zero, and an indirect bit which
> said to use the addressed word as a pointer.  Locations 10-17 (octal)
> were auto-increment, preincremented if you used them as an indirect
> address.  That was very handy, and we always thought carefully about
> what to put there.  The 18-bit PDP-7 and PDP-9 were pretty much the
> same with 18 bit words and bigger addresses, the PDP-15 was a PDP-9
> with an index register, implemented in MSI rather than SSI.
> 
> R's,
> John
> 

I guess they were trying to offload operations
to memory due to the paucity of registers
(at least Nova was register challenged:
4 accumulator registers + PC, SP, FP).

Presumably this was because 7474 flip-flops came
2 to a 14 pin package so doing a 16*16 register bank
would take a fair amount of board real estate.

If that is the case then I think the TI 9900 approach
would be a better with all its registers in memory and
an 'address of register bank' pointer register in the cpu.
Much cleaner and cheaper.

Speaking of cheap:
I saw a wiring diagram for one model of a Nova
(back when computers came with such)
and it had only a single 74181 4-bit ALU.

Eric

[toc] | [prev] | [next] | [standalone]

#2443

>I guess they were trying to offload operations
>to memory due to the paucity of registers
>(at least Nova was register challenged:
>4 accumulator registers + PC, SP, FP).

The PDP-8 and 9 were single accumulator, so four registers
seemed pretty advanced, at least until you saw the 6 2/3 registers
on the -11.  (Two of the 8 registers were reserved as SP and PC.)

>If that is the case then I think the TI 9900 approach would be a
>better with all its registers in memory and an 'address of register
>bank' pointer register in the cpu.  Much cleaner and cheaper.

Slower, too, I would expect.  On the PDP-6 and KA10, the standard
confguration put the 16 registers in memory, and the flip-flop
registers were an option.  I don't think they ever sold a computer
without that option, though.

>Speaking of cheap: I saw a wiring diagram for one model of a Nova
>(back when computers came with such) and it had only a single 74181
>4-bit ALU.

Anyone have diagrams for the bit serial PDP-8/S?  Opinons varied on
whether the S stood for Serial or Slower than Sh*t, but it did take
90us to do a worst case ISZ instruction that used an indirect address
of an auto-increment location that turned to zero so the instruction
skipped, due to the three trips through the adder.

R's,
John

[toc] | [prev] | [next] | [standalone]

#2444

On Jul 9, 12:37 pm, John Levine <jo...@iecc.com> wrote:

> Anyone have diagrams for the bit serial PDP-8/S?

I see that Bitsavers has those for the original 8, and possibly the 8/
i, but, regrettably, not the 8/S.

They also have the schematics for the FPP-8.

John Savard

[toc] | [prev] | [next] | [standalone]

#2446

On Jul 9, 12:53 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:

> They also have the schematics for the FPP-8.

Oh, sorry - the FPP-12.

John Savard

[toc] | [prev] | [next] | [standalone]

#2445

On Jul 9, 11:15 am, EricP <ThatWouldBeTell...@thevillage.com> wrote:

> Speaking of cheap:
> I saw a wiring diagram for one model of a Nova
> (back when computers came with such)
> and it had only a single 74181 4-bit ALU.

I haven't seen the wiring diagram, but I did read that fact on a
website somewhere recently. In the case of the PDP-8/S, I remember
reading that the added control logic meant that the savings in
circuitry from the serial design were limited. In the case of the
Nova, given the circuit technology used then, I am more astonished,
because that would seem, almost certainly, to have led to a need for
more, rather than less, components.

John Savard

[toc] | [prev] | [next] | [standalone]

#2447

EricP <ThatWouldBeTelling@thevillage.com> writes:

> John Levine wrote:
>>>> What other blasts from the past?  VAX and M68K and NS32K...
>>> Data General Nova:
>>> 32k of 16 bit words (word address only).
>>> lsb of address says whether referenced value is
>>> 0=data or 1=indirect address (loop ad infinitum)
>>
>> The Nova was basically a souped up PDP-8 or PDP-9.  DEC decided to use
>> Gordon Bell's much more radical architecture for the 16 bit PDP-11, so
>> designer Ed Decastro went off and started his own minicomputer
>> company.

[...]

> I guess they were trying to offload operations
> to memory due to the paucity of registers
> (at least Nova was register challenged:
> 4 accumulator registers + PC, SP, FP).

The original Nova did not have a stack pointer (SP) or a frame pointer
(FP).  The Data General Eclipse (upward compatible with the Nova) did,
available in memory in locations 40 and 41 (octal, as was natural with
15 address bits) respectively.  There were added instructions to push
and pop values to/from the stack, and to establish a frame on the stack
after a subroutine call and to remove it and return from a subroutine
(and analogous operations for entering and leaving an interrupt service
routine on some Eclipses).

[toc] | [prev] | [next] | [standalone]

#2412

On Wed, 06 Jul 2011 23:38:18 -0700, Andy \"Krazy\" Glew wrote:

> By the way, I am also collecting addressing modes for a different
> article.
> 
> The standard ones.
> 
> But especially the less standard address modes, such as
> 
> * Double Indirect  M[ M[reg+offset] +offset ]
>       which I suggested long ago back in the days of AI architectures,
>       as an optimization for "handles"
> 
>       along with a doubly indirect cache,
>       to eliminate the pointer dereferencing.
> 
> 
> What other blasts from the past?  VAX and M68K and NS32K...


Dont forget the Honeywell L66 and follow on DPS8.  There is an entire
section in the assembly instruction manual on address modification. There
is 40 something pages on address generation then another 20 something on
plugging that address into the virtual memory addressing option.



-- 
Joe Chisolm

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch

csiph-web