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

Groups > comp.arch > #1413 > unrolled thread

No Promises

Back to article view | Back to comp.arch

Contents

  No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-09 18:23 -0700
    Re: No Promises MitchAlsup <MitchAlsup@aol.com> - 2011-05-09 20:00 -0700
      Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-09 20:30 -0700
        Re: No Promises MitchAlsup <MitchAlsup@aol.com> - 2011-05-10 09:34 -0700
          Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-10 15:46 -0700
            Re: No Promises MitchAlsup <MitchAlsup@aol.com> - 2011-05-10 17:56 -0700
              Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-10 18:32 -0700
              Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-11 15:27 -0700
                Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-14 02:48 -0700
                Re: No Promises MitchAlsup <MitchAlsup@aol.com> - 2011-05-14 09:58 -0700
                  Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-14 10:32 -0700
                    Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-05-14 11:07 -0700
                      Re: No Promises "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 17:07 -0700
              Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-07-03 09:42 -0700
                Re: No Promises "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-07-03 11:35 -0700
                  Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-07-03 17:17 -0700
                  Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-07-03 18:03 -0700
                  Re: No Promises Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 09:31 -0700

#1413 — No Promises

Admitting that the implementation of an architecture is more valuable
than a mere description, I have given thought to the matter, and have
come up with a drastically simplified architecture that still allows
the most important parts of the power and flexibility of my baroque
architecture...

http://www.quadibloc.com/arch/mpuint.htm

As can be seen, this is not very original - I just take the System/
360, and shrink the base register field to two bits (only GR12, 13,
14, and 15 can be base registers) so that memory is divided up into
16K byte units instead of 4K byte units.

Originally, I was going to use a scheme where the units were 32 bits -
the first bit in the address part indicating if indexing was needed;
if it was, registers 0-4 would be the destination register, GR1
through 7 could be index registers, and GR8 through 15 could be base
registers. While what this would have done to the SS format would have
been tolerable - I would have just made it four halfwords long,
ignored that first bit, and allowed indexing of both operands - it
would have killed the RS format and the LM and STM instructions - so,
while 16K is small, I accepted it.

And on the next page

http://www.quadibloc.com/arch/mpu01.htm

I get my feet wet. There is a pretty picture of a full adder, and some
Verilog code for a full adder.

It will, of course, be a _long_ time, if *ever*, before I finish this
section... but it's something I might putter around with when I feel
energetic.

John Savard

[toc] | [next] | [standalone]

#1416

On May 9, 8:23 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> And on the next page
>
> http://www.quadibloc.com/arch/mpu01.htm
>
> I get my feet wet. There is a pretty picture of a full adder, and some
> Verilog code for a full adder.
>
> It will, of course, be a _long_ time, if *ever*, before I finish this
> section... but it's something I might putter around with when I feel
> energetic.

How about I just send you a gate-level schematic of a 9-gate delay 64-
bit carry select adder.

Mitch

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

#1417

On May 9, 9:00 pm, MitchAlsup <MitchAl...@aol.com> wrote:

> How about I just send you a gate-level schematic of a 9-gate delay 64-
> bit carry select adder.

I'll hardly need _that_. Elsewhere on my web page,

http://www.quadibloc.com/comp/cp0202.htm

I've already laid the groundwork for going rather quickly from a full
adder to a Sklansky adder and a Wallace Tree multiplier and so on.

That part is "trivial".

It's the out-of-order pipelined control unit that has me kind of
worried...

John Savard

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

#1422

On May 9, 10:30 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> It's the out-of-order pipelined control unit that has me kind of
> worried...

Do you want the Reservation Station model, the ScoreBoard model, or
the Dispatch Stack model?

Mitch

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

#1428

On May 10, 10:34 am, MitchAlsup <MitchAl...@aol.com> wrote:
> On May 9, 10:30 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>
> > It's the out-of-order pipelined control unit that has me kind of
> > worried...
>
> Do you want the Reservation Station model, the ScoreBoard model, or
> the Dispatch Stack model?

I'll probably pass on the CDC 6600 Scoreboard model; I suspect that my
thinking is likely closer to the Dispatch Stack model than to the
original System/360 Model 91 Reservation Station model - but I'll have
to admit I'm not sure. The references I have really don't go as deeply
as I'd like into control unit design, which is why I feel hazy and
lost.

In any event, this dialogue inspired me to go back to the page

http://www.quadibloc.com/comp/cp0202.htm

and now in addition to already having a pretty picture of a carry-
select adder there, I've now added a (gate-level!) schematic of a
carry *look-ahead* adder. While I found other accounts difficult, the
one in Hennessy and Patterson was clear enough that after sufficient
meditation I could reach understanding.

I admit to wading out of my depth, but while I make "no promises", I'm
not _totally_ faking it here.

John Savard

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

#1430

On May 10, 5:46 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:

> I'll probably pass on the CDC 6600 Scoreboard model;

Even if it has solutions for the WAW and being in the shadow of a
branch instruction? (which teh 600 SB did not) And requires no
register renamer? Yet can recover precisely. (That is has left no
problem unsolved that the reservation station with renaming model
solves.)

But back to your ISA. Why a memory to memory vector architecture. The
CDC Star 100 versus the CRAY 1 should have resolved that issue in
favor of the register to register vecvtor model. Leaving the op-code
space to put in gather/scater (i.e. vector indirect, or vector based)
addressing.

Also note: Back in 1980-83 I worked for S.E.L which became Gould
S.E.L. This company had a "good parts" of the 360 architecture encoded
in such a way that the low order bits of the address constant were
used to select the width of the data being loaded or stored (saving
ISA space) and dropped the string/edit/scan stuff. In any event, this
machine used an op-code bit to select the memory reference 'kind' and
thus was relegated to using only 1/2 of the registers as base-able
registers. This, in my compiler* writing opinion, hurt worse than we
modern architects can imagine.

Mitch

(*) which is what I did for them.

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

#1431

On May 10, 6:56 pm, MitchAlsup <MitchAl...@aol.com> wrote:

> But back to your ISA. Why a memory to memory vector architecture. The
> CDC Star 100 versus the CRAY 1 should have resolved that issue in
> favor of the register to register vecvtor model. Leaving the op-code
> space to put in gather/scater (i.e. vector indirect, or vector based)
> addressing.

I may indeed have to look at that. My idea was that the register
vector model _is_ better, but there might be cheaper implementations
that couldn't support it properly. I wasn't even sure I could fit in a
register vector model without making the architecture overly
complicated.

> Also note: Back in 1980-83 I worked for S.E.L which became Gould
> S.E.L. This company had a "good parts" of the 360 architecture encoded
> in such a way that the low order bits of the address constant were
> used to select the width of the data being loaded or stored (saving
> ISA space) and dropped the string/edit/scan stuff.

I'm familiar with that architecture; I thought it was a clever idea,
and used it when I finally decided to settle on just _one_ ISA,
instead of over 64 variations on how the addressing modes worked, for
my baroque ISA - because I was in desperate need of ISA space,
desiring to make lots of different instructions all short.

> In any event, this
> machine used an op-code bit to select the memory reference 'kind' and
> thus was relegated to using only 1/2 of the registers as base-able
> registers. This, in my compiler* writing opinion, hurt worse than we
> modern architects can imagine.

And here I thought only using 1/4 of the registers as base registers -
but expanding the size of the pages they point to by 4 - would make
life simpler. One base register for code, one for data, and little
need to use multiple base registers to span larger program or data
areas. (I would have preferred to be able to use eight base registers
- and have them point to 64 K areas - but I had to compromise to allow
the ISA to be more 360-like.)

As an illustrative example, though, I'm hoping that it would be simple
for someone to change the ISA and still use much of the code that I
might someday write.

John Savard

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

#1468

On May 10, 6:56 pm, MitchAlsup <MitchAl...@aol.com> wrote:
> This company had a "good parts" of the 360 architecture encoded
> in such a way that the low order bits of the address constant were
> used to select the width of the data being loaded or stored (saving
> ISA space) and dropped the string/edit/scan stuff. In any event, this
> machine used an op-code bit to select the memory reference 'kind' and
> thus was relegated to using only 1/2 of the registers as base-able
> registers. This, in my compiler* writing opinion, hurt worse than we
> modern architects can imagine.

If you're talking about the SEL 32, from which I, as I noted, copied
the idea of using the low-order bits of the address constant to
indicate the width of the data, _originally_, there was a two-bit
field in the instruction that indicated the _index_ register in use -
either 0, for no indexing, or 1, 2, or 3, to allow registers 1, 2, or
3 to be used as index registers.

Presumably, it had eight registers - as the destination field was
three bits wide.

A later version, from Gould, had a "base register" mode - the SEL 32
also had an extended addressing mode, but I couldn't find a
description of it in the SEL 32 manual from Bitsavers - in which the
indirect bit was added to the index register field, so that all the
registers (except for register 0) could be index registers - and the
first three bits of the address field were used to indicate a base
register, so that addresses could be wider than the address field
(which allowed for 512 kbytes of memory originally).

I can see that only having three index registers is a limitation.

John Savard

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

#1566

On May 11, 4:27 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:

> A later version, from Gould, had a "base register" mode - the SEL 32
> also had an extended addressing mode, but I couldn't find a
> description of it in the SEL 32 manual from Bitsavers - in which the
> indirect bit was added to the index register field, so that all the
> registers (except for register 0) could be index registers - and the
> first three bits of the address field were used to indicate a base
> register, so that addresses could be wider than the address field
> (which allowed for 512 kbytes of memory originally).

The research done for this discussion inspired me to expand my brief
description of the addressing modes of the SEL 32 on

http://www.quadibloc.com/comp/cp0304.htm

John Savard

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

#1568

On May 11, 5:27 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On May 10, 6:56 pm, MitchAlsup <MitchAl...@aol.com> wrote:
>
> > This company had a "good parts" of the 360 architecture encoded
> > in such a way that the low order bits of the address constant were
> > used to select the width of the data being loaded or stored (saving
> > ISA space) and dropped the string/edit/scan stuff. In any event, this
> > machine used an op-code bit to select the memory reference 'kind' and
> > thus was relegated to using only 1/2 of the registers as base-able
> > registers. This, in my compiler* writing opinion, hurt worse than we
> > modern architects can imagine.
>
> If you're talking about the SEL 32,

Yes, It was.

> A later version, from Gould, had a "base register" mode - the SEL 32
> also had an extended addressing mode, but I couldn't find a
> description of it in the SEL 32 manual from Bitsavers - in which the
> indirect bit was added to the index register field, so that all the
> registers (except for register 0) could be index registers - and the
> first three bits of the address field were used to indicate a base
> register, so that addresses could be wider than the address field
> (which allowed for 512 kbytes of memory originally).

The SEL 32/87 and 32/67 were the first base register machines. I lead
the team that did the FORTRAN runtime library.

The 32/87 has 19-bit (old mode) and 31-bit (or 32-bit) virtual
addresses, but probably no more than 24-bits of physical address.
32/87 was done in ECL gate arrays while the 32/67 was done in a lower
power gate array technology. These were the first page-table SEL
machines (i.e. with a conventional MMU). These were followed by the
NP-1 series of mini-vector machines.

Mitch

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

#1570

On May 14, 10:58 am, MitchAlsup <MitchAl...@aol.com> wrote:

> The 32/87 has 19-bit (old mode) and 31-bit (or 32-bit) virtual
> addresses, but probably no more than 24-bits of physical address.
> 32/87 was done in ECL gate arrays while the 32/67 was done in a lower
> power gate array technology. These were the first page-table SEL
> machines (i.e. with a conventional MMU). These were followed by the
> NP-1 series of mini-vector machines.

Thank you for this interesting information. I'm going to try to hunt
up information about the Gould NP1, the Gould PowerNode, and the
Concept/32.

John Savard

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

#1571

On May 14, 11:32 am, Quadibloc <jsav...@ecn.ab.ca> wrote:

> Thank you for this interesting information. I'm going to try to hunt
> up information about the Gould NP1, the Gould PowerNode, and the
> Concept/32.

From Btsavers, I quickly found out that the Concept/32 was SEL 32-
compatible. Apparently, so was the PowerNode, although I'm still
holding out some hope that the upper models in the series might have
been NPL compatible instead.

NPL being the series the NP1 belonged to - apparently the NP2 was
never made. BSD was ported to the NP1, I've found, but I have not
found information on the NP1 instruction set by means of that.

John Savard

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

#1579

On 5/14/2011 11:07 AM, Quadibloc wrote:
> On May 14, 11:32 am, Quadibloc<jsav...@ecn.ab.ca>  wrote:
>
>> Thank you for this interesting information. I'm going to try to hunt
>> up information about the Gould NP1, the Gould PowerNode, and the
>> Concept/32.
>
>  From Btsavers, I quickly found out that the Concept/32 was SEL 32-
> compatible. Apparently, so was the PowerNode, although I'm still
> holding out some hope that the upper models in the series might have
> been NPL compatible instead.
>
> NPL being the series the NP1 belonged to - apparently the NP2 was
> never made. BSD was ported to the NP1, I've found, but I have not
> found information on the NP1 instruction set by means of that.
>
> John Savard

IIRC PowerNode was strictly the predecessor to the NP1.  Not instruction 
set compatible.

(I worked at Gould on Real time UNIX and Performance Analysis (i.e. 
running benchmarks)).

Unsure if I have an NP1 manual sitting around.  But, you might try the 
gouldbugs mailing list, on one of yahoo or google groups servers.

There were significant changes between NP1 and NP2.  I think NP2 was 
built; at least, people were paid retention bonuses to stay on until it 
was running.  (Not me: my group was sold to Motorola.)

NP3 was going to be even more different.

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

#2328

On May 10, 6:56 pm, MitchAlsup <MitchAl...@aol.com> wrote:

> Also note: Back in 1980-83 I worked for S.E.L which became Gould
> S.E.L. This company had a "good parts" of the 360 architecture encoded
> in such a way that the low order bits of the address constant were
> used to select the width of the data being loaded or stored (saving
> ISA space)

Incidentally, this particular idea, used on the SEL 32, so favorably
impressed me that I used it - giving them credit, even - in my own
fantasy ISA in order to reserve large expanses of opcode space for
instructions that, in one way or another, would allow the computer to
do more of its work with instructions that were only 16 bits long
instead of 32 bits long.

An example is at:

http://www.quadibloc.com/arch/ar010002.htm

John Savard

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

#2331

On 7/3/2011 9:42 AM, Quadibloc wrote:
> On May 10, 6:56 pm, MitchAlsup<MitchAl...@aol.com>  wrote:
>
>> Also note: Back in 1980-83 I worked for S.E.L which became Gould
>> S.E.L. This company had a "good parts" of the 360 architecture encoded
>> in such a way that the low order bits of the address constant were
>> used to select the width of the data being loaded or stored (saving
>> ISA space)
>
> Incidentally, this particular idea, used on the SEL 32, so favorably
> impressed me that I used it - giving them credit, even - in my own
> fantasy ISA in order to reserve large expanses of opcode space for
> instructions that, in one way or another, would allow the computer to
> do more of its work with instructions that were only 16 bits long
> instead of 32 bits long.
>
> An example is at:
>
> http://www.quadibloc.com/arch/ar010002.htm
>
> John Savard


I think this is what you are talking about:

https://semipublic.comp-arch.net/wiki/Extra_bit_mask_trick


I encountered this when I joined Gould in 1985.  I had earlier used it 
in my undergraduate computer project.

I believe that I have found earlier references, but don't have them at 
hand to place in the wiki.

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

#2334

On Jul 3, 12:35 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:

> I think this is what you are talking about:
>
> https://semipublic.comp-arch.net/wiki/Extra_bit_mask_trick

Yes, that is exactly what I am talking about, and in my example
architecture, I use it in a pure and explicit form, whereas with the
Gould machines, the fact that they use a fixed two-bit field at the
end of the word slightly obscures what they are doing.

As I've noted elsewhere, my architecture is the result of my
overwhelming unreasonableness.

The IBM 360 had an address field of only 12 bits.

The Motorola 68020 had an address field of 16 bits, but instructions
increased from 32 bits to 64 bits in size if you wanted to have a base
register, an index register, and a full 16-bit displacement.

I couldn't accept that, and so I worked out an architecture which
allowed classic memory reference instructions to be 32 bits with base,
index, and a 16-bit displacement.

But that wasn't good enough for me - and so I went through gyration
after gyration to allow programs to be even more compact - one way or
another, I wanted something better than a register-to-register
instruction, with eight registers, in a 16-bit instruction.

And, since the market forces which currently work to Intel's advantage
mean that "there can be only one" computer architecture on the
desktop, I decided that I should present an alternative which would
include everything but the kitchen sink... so that nothing would be
lost by only having one architecture.

Cray-I style vector instructions? You've got them!

String and packed decimal instructions, like on an IBM 360? You've got
them!

The ability to work with 36-bit or 48-bit or 60-bit words easily and
conveniently? Yes, you've got even that!!

And, with the billions of transistors they can put on chips these
days, such a thing could actually be implemented... although I suspect
no one would want to.

John Savard

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

#2335

On Jul 3, 12:35 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:

> I encountered this when I joined Gould in 1985.  I had earlier used it
> in my undergraduate computer project.
>
> I believe that I have found earlier references, but don't have them at
> hand to place in the wiki.

The SEL 32 dates from 1976.

So I guess it would be entirely possible that there could be uses of
this principle that predate that.

What *would* surprise me very much, though, is if this principle was
used by anyone prior to April 7, 1964. Which was, of course, the
announcement date of a very famous computer - apparently, as far as
*another* thread here has been able to establish, the first one to
have individually addressable units of storage with a hierarchy of
alignment rules for data items which spanned 2, 4, or 8 of those
storage units.

The IBM 360 had to exist first before people could notice that it was
wasting bits in its addresses.

John Savard

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

#2354

On Jul 3, 12:35 pm, "Andy \"Krazy\" Glew" <a...@SPAM.comp-arch.net>
wrote:

> I believe that I have found earlier references, but don't have them at
> hand to place in the wiki.

While I haven't found anything too close, the KDF 9 jump instructions
had an extra three-bit field to indicate which byte in a word was
used, and the Elliot 803 could jump to the high or low half of a word
using two instructions for that purpose, as someone else informed me -
this is going on in the History of Byte Addressing thread.

John Savard

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web