On 10/23/2022 3:09 AM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>
>> A 1:64 decoder (6-bits) is all one needs to "decode" My 66000 instructions
>> and of these only 35 entries are assigned instructions--the rest "decode" to
>> UNIMP (raise OPERATION).
>
> There's a bit more to that. Determining the size of the instruction
> including operands includes looking at the bits of the opcodes,
> and two additional bits.
>
> Unless you don't consider that as part of the decoding.

Yeah, decode probably needs to do "something" at least...

Only other alternative would likely be to have "instructions" which map
directly to the internal state of the CPU pipeline.

For BJX2, this would mean, say:
3x 18-bit, for major+minor opcode (2x 6b + 2x 3b control);
6x 7-bit for register ports (combined GPR+SPR+CR space);
3x 33-bit for immediate values.

So, say, a 256 bit instruction word.
With the layout likely changing between implementations.

This would be clearly non-viable though.

I am dealing a little bit as-is with some fall-out from a few "minor"
ABI tweaks (namely, function calls now have a dedicated spill space more
like in MS-style ABIs).

Though I had initially thought I had escaped without any real adverse
effect from the tweak, but it seems it creates a binary compatibility
issue with TKGDI calls (which turns out was also prone to break with a
few other compiler options due to having a function which went over the
argument count limit; breaking if the program and shell were built with
different ABI and XGPR flags).

Had modified the internal interface to be less prone to break in the
future, but this change is itself a break.

Otherwise, I have gone and added a few special purpose ops to help with
stack canary values, mostly to make them more secure. With the old
mechanism, if a binary was not rebuilt it would be possible (in premise)
to figure out and then forge the canary values when making use of a
buffer overflow. I have added some new instructions to hopefully
sidestep this issue (a pure software solution would have had a higher
runtime overhead).

But, alas...

....

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>> |PLAs differ from programmable array logic devices (PALs and GALs) in
>> |that both the AND and OR gate planes are programmable.
>>
>> Hmm, sounds like DG could have replaced the PALs with PLAs if their
>> source for PALs dried up, but maybe PLAs of the needed capacity were
>> not available.
>
>But wouldn't that have required a redesign?

It depends. If they are worried that their source dries up, they can
prepare for that eventuality by putting the PALs on a separate board
(or separate boards), and preparing a drop-in replacement. A friend
of mine who has had supply chain problems in recent years has gone
that path. But of course this incurs additional cost, and, as
discussed, might have slowed the Eagle down.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Thomas Koenig <tkoenig@netcologne.de> writes:
>David Schultz <david.schultz@earthlink.net> schrieb:
>> I have read the book a couple of times and still remember the
>> description of the prototypes. All wire wrapped. Corrections were done
>> with a different color wire and the book describes the back of the board
>> gradually changing color. There were a lot of changes.
>
>Compare that to the first HP-PA implementation, done in TTL, where they
>went to printed circuit boards right from the beginning. If this was
>due to better methodology, better simulation tools a few years later,
>or RISC vs. CISC is unclear.

It may just have been good-enough turn-around times for printing and
otherwise preparing a new circuit board.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

David Schultz <david.schultz@earthlink.net> writes:

> On 10/22/22 5:06 PM, Joe Pfeiffer wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> |PLAs differ from programmable array logic devices (PALs and GALs) in
>>> |that both the AND and OR gate planes are programmable.
>>>
>>> Hmm, sounds like DG could have replaced the PALs with PLAs if their
>>> source for PALs dried up, but maybe PLAs of the needed capacity were
>>> not available.
>> But wouldn't that have required a redesign?
>
> Most likely. Unless they were pin compatible. The reason for using
> PALs was that fixing a bug didn't always require moving a wire.

I guess I wasn't even considering redesigning the board, just
reprogramming all the logic in the PAL (PLA). With a PAL/PLA that's
where most of the design takes place.

On Sunday, October 23, 2022 at 3:09:21 AM UTC-5, Thomas Koenig wrote:
> MitchAlsup <Mitch...@aol.com> schrieb:
> > A 1:64 decoder (6-bits) is all one needs to "decode" My 66000 instructions
> > and of these only 35 entries are assigned instructions--the rest "decode" to
> > UNIMP (raise OPERATION).
<
> There's a bit more to that. Determining the size of the instruction
> including operands includes looking at the bits of the opcodes,
> and two additional bits.
<
Given a 1-wide implementation and a pointer into the inst-buffer all the size
logic can be done "later", the register specification fields routed directly to
the register file ports. The output of that 1:64 decoder is then used to select
from {PRED, Shift, Mem, 2-OP, 3-OP, 1-OP, major} "what is selected on the data-"
"path" 1st cycle select lines.
<
So, the main job of the 1:64 decoder is to enable the "other decoders" which
are all merged (OR) into selections to be asserted next cycle.
<
Meanwhile forwarding compares and find firsts are performed; so, proper
data arrives on the operand busses.
>
> Unless you don't consider that as part of the decoding.
<
Routing constants to the operand busses is the easy part; as is determining
instruction length.

On 10/23/2022 4:39 AM, Thomas Koenig wrote:
> BGB <cr88192@gmail.com> schrieb:
>> On 10/22/2022 2:51 PM, MitchAlsup wrote:
>>> On Saturday, October 22, 2022 at 1:17:39 PM UTC-5, BGB wrote:
>>>> On 10/22/2022 12:02 PM, Thomas Koenig wrote:
>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
>>>>>> Thomas Koenig <tko...@netcologne.de> writes:
>>>>>>> They used PLAs in the HP design, which were just becoming available
>>>>>>> in the late 1970s (their availability being a gamble that was
>>>>>>> described in "The Soul of a New Machine")
>>>>>>
>>>>>> The Eagle described in "The Soul of a New Machine" "gambled" on PALs
>>>>>> <https://en.wikipedia.org/wiki/Programmable_Array_Logic> (at that
>>>>>> point there was only one source for PALs), not PLAs
>>>>>> <https://en.wikipedia.org/wiki/Programmable_logic_array>.
>>>>>
>>>>> OK, that distiction had escaped me. Seems that both have the
>>>>> same function (in general), to provide logic functions, but with
>>>>> a different implementation.
>>>>>
>>>>>> |PLAs differ from programmable array logic devices (PALs and GALs) in
>>>>>> |that both the AND and OR gate planes are programmable.
>>>>>>
>>>>>> Hmm, sounds like DG could have replaced the PALs with PLAs if their
>>>>>> source for PALs dried up, but maybe PLAs of the needed capacity were
>>>>>> not available.
>>>>>
>>>>> It seems PLAs are slower than PALs. Looking at the 1976 National
>>>>> Data Handbook, it says that for their DM7575 chip, it takes 100
>>>>> microseconds for a transition from high to low. The Eclipse MV was
>>>>> a 5 MHz machine with internal 10 MHz on the CPU (first cycle for
>>>>> microcode, second cycle for actually doing things), that would have
>>>>> made it infeasable. Seems that the 74330/74331 was a bit faster,
>>>>> with 70 ns maximum time.
>>>>>
>>>>> Coming back to the hypothetical late 1970s RISC machine, using
>>>>> a PLA for some decoding would have been feasible, but could have
>>>>> limited cycle times.
>>>> Seems like, depending on the ISA, one could map the decode process to a
>>>> few cascaded EPROMs.
>>>>
>>>>
>>>> Say, for a 3R RISC with 32-bit instructions and with no opcode bits
>>>> overlapping registers:
>>>> 128K ROM, Major Opcode (Function Unit)
>>> <
>>> Since you said 3R RISC above::
>>> <
>>> A 1:64 decoder (6-bits) is all one needs to "decode" My 66000 instructions
>>> and of these only 35 entries are assigned instructions--the rest "decode" to
>>> UNIMP (raise OPERATION). Pretty sure you don't need a ROM for this. Almost
>>> all of these are single pipeline cycle execution and the 2 which are not have
>>> easy 1st cycle pipeline operation.
>>> <
>>> Also note: The decoder of the Mc 88100 was a single NOR plane.
>>> <
>>
>> I was thinking of ROMs mostly as an "efficient" way to map an input
>> pattern to an output pattern, at least a lot more so than doing it with
>> a crapton of NAND gate ICs or something.
>
> Do you know espresso? It is a logic minimization program developed
> at MIT and available from
> https://github.com/classabbyamp/espresso-logic .
>
> You can build up a bit table of an ISA and give the results
> according to instruction format, type of instruction, etc.
> The size of the resulting decoding PLA is something you can use
> as a rough measure of the complexity of an ISA (and would be
> more direct if you used a NOR plane).

Not heard of it.

But, yeah, for something like I had imagined here (with a ROM), it might
sense to try to cram nearly all of the opcode bits into a shared 17-bit
blob, say:
ZZZZ-ZZZZ-ZZZn-nnnn ssss-sttt-ttZZ-ZZZZ (3R)
ZZZZ-ZZZZ-ZZZn-nnnn ssss-siii-iiZZ-ZZZZ (3RI, Imm5)
Maybe (if resources allow):
ZZZZ-ZZZZ-ZZZn-nnnn ssss-siii-iiii-iiii (3RI, Imm11)
ZZZZ-ZZZZ-ZZZn-nnnn iiii-iiii-iiii-iiii (2RI, Imm16)

With Rn/Rs/Rt mostly unable to participate in opcode selection.

Though, one may find that, often, 3R encodings may be overkill (if only
a 2R or 1R encoding is needed). But, decoding these increases the number
of bits that need to be considered for the opcode.

Or, possibly, 6b reg fields:
ZZZZ-ZZZZ-ZZnn-nnnn ssss-sstt-tttt-ZZZZ (3R)
ZZZZ-ZZZZ-ZZnn-nnnn ssss-ssii-iiii-ZZZZ (3RI, Imm6)
ZZZZ-ZZZZ-ZZnn-nnnn ssss-ssii-iiii-iiii (3RI, Imm10)
ZZZZ-ZZZZ-ZZnn-nnnn iiii-iiii-iiii-iiii (2RI, Imm16)
Using a 14-bit ROM space for opcodes.

Where, say:
R0 ..R31: Pure GPRs
R32..R47: SPRs (ZR, LR, GBR, SP, ...)
R48..R63: CRs

At least for BJX2:

Though, I have noted that in my case, cost and complexity (at least on
an FPGA) seems to be more dominated by the function units and EX stages
than by the decoder. The code for the decoder is kinda bulky (due to
lots of instructions), but seemingly not too terrible (mostly maps input
instructions to the output opcode numbers and some other numbers which
encode how to decode the register arguments).

Both the C (emulator) version and Verilog version have a loosely similar
structure for the front-end part:
A split between decoding 16 and 32 bit instructions;
64 and 96 bit merely "extend" the 32-bit format.
Main decoding is pattern/matching via nested switch/case.

Decoding 16-bit ops via a ROM would require mapping all 16 bits through
a ROM, partly because the 30zz block uses all 16 bits. If we ignore the
1R block (3xxx), the ROM would drop to around 8 bits.

It is possible that two cascaded 10b ROMs could also deal with the
decoding space.

Register field mapping depends some on the instruction:
0..F may map to, say:
R0..R15
R16..R31
R1:R0, R17:R16, R3:R2, R19:R18, ...
C0..C15
Imm4
...

For 32-bit ops:
The register fields and immediate values are at least more consistent;
Organized into major blocks (0/1/2/3, 8/9/A/B);
F0, block effectively uses 8-bits for 3R blocks;
Increases to 12 for 2R blocks, and 16 for the 1R block.
F1, uses 4 bits.
F2, uses 4 bits for 3RI, and 8 for 2RI.
F3, reserved for now.
F8, uses 3 bits (2RI), 2-bits for Op96 (LDI/ADD/-/-)
F9, reserved for now.
FA, 0 bits (Imm24)
FB, 0 bits (Imm24)
Many of these blocks add 1 bit as E.Q is used as an opcode bit.

Register types:
R0..R31 or R0..R63 (XGPR)
Though, the F8 block uses a different encoding for Rn.
C0..C31

Excluding the 1R block, the 32-bit BJX2 decoder frontend could likely
fit into a 20-bit ROM:
xxxx-ZxZZ-xxxx-ZZZZ-ZZZZ-Zxxx-ZZZZ-ZZZZ
Where:
x=N/A for opcode, Z=needed for opcode.

Could use possibly use smaller ROMs if the blocks were split up based on
major encoding blocks.

The 32-bit decoder doesn't itself care as much about F/E/7/9, as their
scope is mostly limited to the register fields and predication mode
(thus mostly independent of the main part of the decoder).

The outer "bundle decoder" mostly cares about this, to select output
from the correct decoder (and, with RV mode enabled, needs to deal with
both BJX2 and RISC-V).

The situation isn't quite as bad for LUTs, as LUTs can mostly ignore
"not relevant" bits for "sparse" parts of the ISA, so it seems to make
more sense to divide stuff up into "sparse" and "dense" areas, and to
group similar encodings together (so, densely pack all the 2R spaces,
and all the 1R space into a single block, ...).

So, if a new instruction in the listing uses existing logic, it mostly
"just disappears into the LUTs". But, if it needs new logic in the EX
stages, ..., this is where cost comes in.

Despite being seemingly minor, adding new SPRs or new immediate-decoding
cases, is potentially unexpectedly expensive.

So, for example, had looked into adding a "BRcc Rn, Imm5, Label" case;
but this required a hack to allow passing the immediate in a register
port. This required a new internal SPR, which (while only applied to the
Rs and Rt ports), managed to add ~ 2k LUT to the size of the core (which
led me to reconsider this). Similar issue also exists with adding
instructions for FPU Immediate values.

Though, costs seem to multiply in areas near "hot path" parts of the
code, which basically touches the ID2 stage, ALU, and the SR.T bit,
pretty hard (for SR.T, a fair chunk of "weight" hangs off a single
status-flag bit, so stuff effecting this bit can really "rock the boat"
as it were).

On Wednesday, October 19, 2022 at 8:50:37 PM UTC-4, MitchAlsup wrote:

> Instruction fetch and decode were actually pipelined, the rest (6600) was
> simply concurrent managed by the scoreboard. The 6400 was a 6600
> less the scoreboard.

I don't think that is exactly true. I remember seeing block diagrams and the 6400 was considerably simpler than the 6600
(not to mention considerably smaller, I think a 6600 was about 3-5 times the size of a 6400. This is based on pictures
I've seen of the 6600 and being in the presence of a 6400 & 6500 (the 6500 was two 6400s, and it still wasn't as big as the 6600).

> <
> The scoreboard managed instruction issue (operands ready) and instruction
> retirement (result ready). Without the scoreboard, the 6400 issued the next
> instruction when the current instruction wanted to retire.

And the 6400 didn't have the instruction stack (loop cache) that the 6600 had.

> And then there would be the peripheral processors,...

Actually, there was only one, it just ran 10 threads (barrel processor).

> 6600 (and 6400) were 1-s complement machines.

You can implement 1's complement by doing an end-around-carry. (carry out of the MSB is connected to carry in of the LSB of the ALU).

Probably the biggest problem is implementing the console. Maybe somebody can dig up a couple of the old Vectrex video games...
:)

- Tim

On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:
> On Wednesday, October 19, 2022 at 8:50:37 PM UTC-4, MitchAlsup wrote:
>
> > Instruction fetch and decode were actually pipelined, the rest (6600) was
> > simply concurrent managed by the scoreboard. The 6400 was a 6600
> > less the scoreboard.
> I don't think that is exactly true. I remember seeing block diagrams and the 6400 was considerably simpler than the 6600
> (not to mention considerably smaller, I think a 6600 was about 3-5 times the size of a 6400. This is based on pictures
> I've seen of the 6600 and being in the presence of a 6400 & 6500 (the 6500 was two 6400s, and it still wasn't as big as the 6600).
> > <
> > The scoreboard managed instruction issue (operands ready) and instruction
> > retirement (result ready). Without the scoreboard, the 6400 issued the next
> > instruction when the current instruction wanted to retire.
> And the 6400 didn't have the instruction stack (loop cache) that the 6600 had.
> > And then there would be the peripheral processors,...
> Actually, there was only one, it just ran 10 threads (barrel processor).
> > 6600 (and 6400) were 1-s complement machines.
> You can implement 1's complement by doing an end-around-carry. (carry out of the MSB is connected to carry in of the LSB of the ALU).
>
> Probably the biggest problem is implementing the console. Maybe somebody can dig up a couple of the old Vectrex video games...
> :)
>
>
> - Tim

There exists somewhere on the internet:
"6000 Training Supplement preliminary edition January 1968" as a scanned document.
On page 6 there is a chassis frame by frame physical diagram of the 6600
"central processor layout"
that diagrams the allocation of the frames (16 total, called "chassis" in the document).
Eight are allocated to memory, each frame holding 20 4K by 12 core memory modules.
One is allocated to the peripheral processors, one is empty and the remaining six constitute the 6600 CPU.

The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)

The document, although marked obsolete, appears to be a through introduction to the 6600 micro architecture.
There are other 6600 documents that describe the micro-architecture in detail, this is the only
one I have that provides a chassis allocation diagram.
The possibility exists that the diagram is not strict, in that empty spaces in the frames where used
for hardware patches and overflow from the diagram's allocation?

On Tuesday, October 25, 2022 at 8:18:12 PM UTC-5, JimBrakefield wrote:
> On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:

> There exists somewhere on the internet:
> "6000 Training Supplement preliminary edition January 1968" as a scanned document.
> On page 6 there is a chassis frame by frame physical diagram of the 6600
> "central processor layout"
> that diagrams the allocation of the frames (16 total, called "chassis" in the document).
> Eight are allocated to memory, each frame holding 20 4K by 12 core memory modules.
> One is allocated to the peripheral processors, one is empty and the remaining six constitute the 6600 CPU.
<
"The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
>
> The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)
<
A second PP is believable, a 6400 CPU would imply that a 6400 was 1/5th the size of a 66000.
{A 6600 'core' is 5-bays in the figure given above--in comparison: memory is 8 bays, and the PPs
are 1 bay. But I don't understand the frame labeled PP and another frame labeled Peripheral.
Is the PP the processors and Peripheral the connections points, the read/write pyramid ???}
<
CPU control is the scoreboard.
>
> The document, although marked obsolete, appears to be a through introduction to the 6600 micro architecture.
> There are other 6600 documents that describe the micro-architecture in detail, this is the only
> one I have that provides a chassis allocation diagram.
> The possibility exists that the diagram is not strict, in that empty spaces in the frames where used
> for hardware patches and overflow from the diagram's allocation?

On Wednesday, October 26, 2022 at 12:22:53 PM UTC-5, MitchAlsup wrote:
> On Tuesday, October 25, 2022 at 8:18:12 PM UTC-5, JimBrakefield wrote:
> > On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:
>
> > There exists somewhere on the internet:
> > "6000 Training Supplement preliminary edition January 1968" as a scanned document.
> > On page 6 there is a chassis frame by frame physical diagram of the 6600
> > "central processor layout"
> > that diagrams the allocation of the frames (16 total, called "chassis" in the document).
> > Eight are allocated to memory, each frame holding 20 4K by 12 core memory modules.
> > One is allocated to the peripheral processors, one is empty and the remaining six constitute the 6600 CPU.
> <
> "The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
> >
> > The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)
> <
> A second PP is believable, a 6400 CPU would imply that a 6400 was 1/5th the size of a 66000.
> {A 6600 'core' is 5-bays in the figure given above--in comparison: memory is 8 bays, and the PPs
> are 1 bay. But I don't understand the frame labeled PP and another frame labeled Peripheral.
> Is the PP the processors and Peripheral the connections points, the read/write pyramid ???}
> <
> CPU control is the scoreboard.
> >
> > The document, although marked obsolete, appears to be a through introduction to the 6600 micro architecture.
> > There are other 6600 documents that describe the micro-architecture in detail, this is the only
> > one I have that provides a chassis allocation diagram.
> > The possibility exists that the diagram is not strict, in that empty spaces in the frames where used
> > for hardware patches and overflow from the diagram's allocation?

|>"The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
Ah, yes. However it is not as detailed as the one in 6000 Training Supplement:

The Training Supplement shows peripheral controllers included in the memory bank chassis (all eight of them).

And shows chassis #12 housing the display controllers and peripheral controller(s).
Leaving only five chassis (#s 2, 5, 6, 7 & 8)holding the 6600 CPU.
#6 holds the two multiplication units sans exponent adders.
#7 and half of #8 hold the multi- port register files; leading me to wonder how Thornton squeezed the 6400 CPU into a single chassis?

6400 presumably used an ALU similar to the one in the CDC1604 with single bit shifting by one on
multiply, divide, normalize and shift clock cycles.
The 6400 was a single issue multi-clock cycle device (e.g. worked on one instruction at a time)?

On Wednesday, October 26, 2022 at 4:28:09 PM UTC-5, JimBrakefield wrote:
> On Wednesday, October 26, 2022 at 12:22:53 PM UTC-5, MitchAlsup wrote:
> > On Tuesday, October 25, 2022 at 8:18:12 PM UTC-5, JimBrakefield wrote:
> > > On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:
> >
> > > There exists somewhere on the internet:
> > > "6000 Training Supplement preliminary edition January 1968" as a scanned document.
> > > On page 6 there is a chassis frame by frame physical diagram of the 6600
> > > "central processor layout"
> > > that diagrams the allocation of the frames (16 total, called "chassis" in the document).
> > > Eight are allocated to memory, each frame holding 20 4K by 12 core memory modules.
> > > One is allocated to the peripheral processors, one is empty and the remaining six constitute the 6600 CPU.
> > <
> > "The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
> > >
> > > The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)
> > <
> > A second PP is believable, a 6400 CPU would imply that a 6400 was 1/5th the size of a 66000.
> > {A 6600 'core' is 5-bays in the figure given above--in comparison: memory is 8 bays, and the PPs
> > are 1 bay. But I don't understand the frame labeled PP and another frame labeled Peripheral.
> > Is the PP the processors and Peripheral the connections points, the read/write pyramid ???}
> > <
> > CPU control is the scoreboard.
> > >
> > > The document, although marked obsolete, appears to be a through introduction to the 6600 micro architecture.
> > > There are other 6600 documents that describe the micro-architecture in detail, this is the only
> > > one I have that provides a chassis allocation diagram.
> > > The possibility exists that the diagram is not strict, in that empty spaces in the frames where used
> > > for hardware patches and overflow from the diagram's allocation?
>
> |>"The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
> Ah, yes. However it is not as detailed as the one in 6000 Training Supplement:
>
> The Training Supplement shows peripheral controllers included in the memory bank chassis (all eight of them).
>
> And shows chassis #12 housing the display controllers and peripheral controller(s).
> Leaving only five chassis (#s 2, 5, 6, 7 & 8)holding the 6600 CPU.
> #6 holds the two multiplication units sans exponent adders.
> #7 and half of #8 hold the multi- port register files; leading me to wonder how Thornton squeezed the 6400 CPU into a single chassis?
<
My guess is that the 2R1W 6400 register file is a LOT smaller than the {6R4W X register file of the 6600,
the 4R2W B file, and the 2R1W A file:: 12 read ports and 7 write ports} By a very large margin (maybe
10× smaller) 1 INC unit, 1 multiplier (perhaps a smaller re-used tree), and a commensurately slower divider,
no stunt box, and less aggessive fetch.
>
> 6400 presumably used an ALU similar to the one in the CDC1604 with single bit shifting by one on
> multiply, divide, normalize and shift clock cycles.
<
Divide and normalize, sure. Maybe a 6×60 multiplier "tree" to prevent multiply from becoming a
bottleneck.
<
> The 6400 was a single issue multi-clock cycle device (e.g. worked on one instruction at a time)?
<
Overlapping only fetch, with 1 concurrent outstanding memory ref.

On 10/26/2022 2:55 PM, MitchAlsup wrote:
> On Wednesday, October 26, 2022 at 4:28:09 PM UTC-5, JimBrakefield wrote:
>> On Wednesday, October 26, 2022 at 12:22:53 PM UTC-5, MitchAlsup wrote:
>>> On Tuesday, October 25, 2022 at 8:18:12 PM UTC-5, JimBrakefield wrote:
>>>> On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:
>>>
>>>> There exists somewhere on the internet:
>>>> "6000 Training Supplement preliminary edition January 1968" as a scanned document.
>>>> On page 6 there is a chassis frame by frame physical diagram of the 6600
>>>> "central processor layout"
>>>> that diagrams the allocation of the frames (16 total, called "chassis" in the document).
>>>> Eight are allocated to memory, each frame holding 20 4K by 12 core memory modules.
>>>> One is allocated to the peripheral processors, one is empty and the remaining six constitute the 6600 CPU.
>>> <
>>> "The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
>>>>
>>>> The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)
>>> <
>>> A second PP is believable, a 6400 CPU would imply that a 6400 was 1/5th the size of a 66000.
>>> {A 6600 'core' is 5-bays in the figure given above--in comparison: memory is 8 bays, and the PPs
>>> are 1 bay. But I don't understand the frame labeled PP and another frame labeled Peripheral.
>>> Is the PP the processors and Peripheral the connections points, the read/write pyramid ???}
>>> <
>>> CPU control is the scoreboard.
>>>>
>>>> The document, although marked obsolete, appears to be a through introduction to the 6600 micro architecture.
>>>> There are other 6600 documents that describe the micro-architecture in detail, this is the only
>>>> one I have that provides a chassis allocation diagram.
>>>> The possibility exists that the diagram is not strict, in that empty spaces in the frames where used
>>>> for hardware patches and overflow from the diagram's allocation?
>>
>> |>"The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
>> Ah, yes. However it is not as detailed as the one in 6000 Training Supplement:
>>
>> The Training Supplement shows peripheral controllers included in the memory bank chassis (all eight of them).
>>
>> And shows chassis #12 housing the display controllers and peripheral controller(s).
>> Leaving only five chassis (#s 2, 5, 6, 7 & 8)holding the 6600 CPU.
>> #6 holds the two multiplication units sans exponent adders.
>> #7 and half of #8 hold the multi- port register files; leading me to wonder how Thornton squeezed the 6400 CPU into a single chassis?
> <
> My guess is that the 2R1W 6400 register file is a LOT smaller than the {6R4W X register file of the 6600,
> the 4R2W B file, and the 2R1W A file:: 12 read ports and 7 write ports} By a very large margin (maybe
> 10× smaller) 1 INC unit, 1 multiplier (perhaps a smaller re-used tree), and a commensurately slower divider,
> no stunt box, and less aggessive fetch.
>>
>> 6400 presumably used an ALU similar to the one in the CDC1604 with single bit shifting by one on
>> multiply, divide, normalize and shift clock cycles.
> <
> Divide and normalize, sure. Maybe a 6×60 multiplier "tree" to prevent multiply from becoming a
> bottleneck.
> <
>> The 6400 was a single issue multi-clock cycle device (e.g. worked on one instruction at a time)?
> <
> Overlapping only fetch, with 1 concurrent outstanding memory ref.

@Mitch: test followup post

On Friday, October 28, 2022 at 3:56:19 PM UTC-5, Ivan Godard wrote:
> On 10/26/2022 2:55 PM, MitchAlsup wrote:
> > On Wednesday, October 26, 2022 at 4:28:09 PM UTC-5, JimBrakefield wrote:
> >> On Wednesday, October 26, 2022 at 12:22:53 PM UTC-5, MitchAlsup wrote:
> >>> On Tuesday, October 25, 2022 at 8:18:12 PM UTC-5, JimBrakefield wrote:
> >>>> On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:
> >>>
> >>>> There exists somewhere on the internet:
> >>>> "6000 Training Supplement preliminary edition January 1968" as a scanned document.
> >>>> On page 6 there is a chassis frame by frame physical diagram of the 6600
> >>>> "central processor layout"
> >>>> that diagrams the allocation of the frames (16 total, called "chassis" in the document).
> >>>> Eight are allocated to memory, each frame holding 20 4K by 12 core memory modules.
> >>>> One is allocated to the peripheral processors, one is empty and the remaining six constitute the 6600 CPU.
> >>> <
> >>> "The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
> >>>>
> >>>> The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)
> >>> <
> >>> A second PP is believable, a 6400 CPU would imply that a 6400 was 1/5th the size of a 66000.
> >>> {A 6600 'core' is 5-bays in the figure given above--in comparison: memory is 8 bays, and the PPs
> >>> are 1 bay. But I don't understand the frame labeled PP and another frame labeled Peripheral.
> >>> Is the PP the processors and Peripheral the connections points, the read/write pyramid ???}
> >>> <
> >>> CPU control is the scoreboard.
> >>>>
> >>>> The document, although marked obsolete, appears to be a through introduction to the 6600 micro architecture.
> >>>> There are other 6600 documents that describe the micro-architecture in detail, this is the only
> >>>> one I have that provides a chassis allocation diagram.
> >>>> The possibility exists that the diagram is not strict, in that empty spaces in the frames where used
> >>>> for hardware patches and overflow from the diagram's allocation?
> >>
> >> |>"The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
> >> Ah, yes. However it is not as detailed as the one in 6000 Training Supplement:
> >>
> >> The Training Supplement shows peripheral controllers included in the memory bank chassis (all eight of them).
> >>
> >> And shows chassis #12 housing the display controllers and peripheral controller(s).
> >> Leaving only five chassis (#s 2, 5, 6, 7 & 8)holding the 6600 CPU.
> >> #6 holds the two multiplication units sans exponent adders.
> >> #7 and half of #8 hold the multi- port register files; leading me to wonder how Thornton squeezed the 6400 CPU into a single chassis?
> > <
> > My guess is that the 2R1W 6400 register file is a LOT smaller than the {6R4W X register file of the 6600,
> > the 4R2W B file, and the 2R1W A file:: 12 read ports and 7 write ports} By a very large margin (maybe
> > 10× smaller) 1 INC unit, 1 multiplier (perhaps a smaller re-used tree), and a commensurately slower divider,
> > no stunt box, and less aggessive fetch.
> >>
> >> 6400 presumably used an ALU similar to the one in the CDC1604 with single bit shifting by one on
> >> multiply, divide, normalize and shift clock cycles.
> > <
> > Divide and normalize, sure. Maybe a 6×60 multiplier "tree" to prevent multiply from becoming a
> > bottleneck.
> > <
> >> The 6400 was a single issue multi-clock cycle device (e.g. worked on one instruction at a time)?
> > <
> > Overlapping only fetch, with 1 concurrent outstanding memory ref.
> @Mitch: test followup post
<
@Ivan: I see you.

On Wednesday, October 26, 2022 at 1:22:53 PM UTC-4, MitchAlsup wrote:
> On Tuesday, October 25, 2022 at 8:18:12 PM UTC-5, JimBrakefield wrote:
> > On Tuesday, October 25, 2022 at 5:47:48 PM UTC-5, timca...@aol.com wrote:
>

> "The Design of a Computer", Thornton; has an overhead view on page 35 as figure 26.
> >
> > The empty frame can be used for a second set of peripheral processors or a 6400 CPU (my inference)

The 6700 was a 6600 + 6400. Not sure how many were sold. IIRC, the OS ran on the 6400 and the 6600
only ran user programs. This was a continuing problem at CDC, where they kept putting the OS on the slowest
processors (originally, most of the OS ran on the PPs, that was a BIG mistake).

> <
> A second PP is believable, a 6400 CPU would imply that a 6400 was 1/5th the size of a 66000.
> {A 6600 'core' is 5-bays in the figure given above--in comparison: memory is 8 bays, and the PPs
> are 1 bay. But I don't understand the frame labeled PP and another frame labeled Peripheral.
> Is the PP the processors and Peripheral the connections points, the read/write pyramid ???}

AFAIK, the second PP wasn't added until (maybe?) the 7600. They were certainly there by the
Cyber 170/7xx era (late 70s). Note that the 170/750 was basically a 7600 CPU internally, just
missing a few 7600 features (like the CPU being able to do I/O without the PPs). It was physically
about the size of the 6400 if I remember right.

The Peripheral Processors were different than the controllers. The PPs connected to the controllers
using channels. IIRC, any PP could talk to any channel, I'm not sure if the channels were statically assigned
to controllers or not, or they worked on some kind of shared bus.

On Monday, October 17, 2022 at 10:27:29 AM UTC-7, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> And it was, it just was a step into the wrong direction. And I think
> that if the VAX architects had the RISC papers available, they would
> have recognized that and designed the VAX differently. Maybe not as a
> RISC (after all, it should also support PDP-11 code), but maybe more
> like a 32-bit PDP-11 with more registers and maybe some addressing
> modes deprecated.
> >In effect, VAX and 432 started the pendulum swinging away
> >from CISC towards RISC.

No, and No.

In high school and college I was a big fan of computer architecture which became a prime interest. I used a UIUC PDP 11/70 (Unix v7) in high school and Vax 11/750's and 11/780's (BSD 4.15 and BSD 4.2) in college and graduate school.

In the 1970's memory was horribly expensive and slow. Cache memories were not very popular because they were only fast if integrated onto a custom chip, so virtually nobody had cache memories. Under the circumstances of very high memory costs, very dense highly efficient instruction sets can help cut the von Neumann bottleneck in half. It didn't look like things would get better in the 1980's. And then Japan and MITI came along and suddenly in the mid 1980's Japan leapfrogged the USA memory makers and memory was suddenly cheap as dirt, and FAST :

https://www.youtube.com/watch?v=bwhU9goCiaI&t=703s

Under these circumstances, wide low-density instruction sets (RISC) suddenly become affordable for your computer design. The advent of the 801 minicomputer and MIPS processor weren't so much "The right idea at the right time". They were the "The right idea before it was time" and Japan just happened to change all of our futures shortly after these papers published and the projects were promoted.

- Don Gillies, PhD CS
Bluescape, Inc.

D Gillies wrote:
> On Monday, October 17, 2022 at 10:27:29 AM UTC-7, Anton Ertl wrote:
>> MitchAlsup <Mitch...@aol.com> writes:
>> And it was, it just was a step into the wrong direction. And I think
>> that if the VAX architects had the RISC papers available, they would
>> have recognized that and designed the VAX differently. Maybe not as a
>> RISC (after all, it should also support PDP-11 code), but maybe more
>> like a 32-bit PDP-11 with more registers and maybe some addressing
>> modes deprecated.
>>> In effect, VAX and 432 started the pendulum swinging away
>> >from CISC towards RISC.
>
> No, and No.
>
> In high school and college I was a big fan of computer architecture which became a prime interest. I used a UIUC PDP 11/70 (Unix v7) in high school and Vax 11/750's and 11/780's (BSD 4.15 and BSD 4.2) in college and graduate school.
>
> In the 1970's memory was horribly expensive and slow. Cache memories were not very popular because they were only fast if integrated onto a custom chip, so virtually nobody had cache memories. Under the circumstances of very high memory costs, very dense highly efficient instruction sets can help cut the von Neumann bottleneck in half. It didn't look like things would get better in the 1980's. And then Japan and MITI came along and suddenly in the mid 1980's Japan leapfrogged the USA memory makers and memory was suddenly cheap as dirt, and FAST :
>
> https://www.youtube.com/watch?v=bwhU9goCiaI&t=703s
>
> Under these circumstances, wide low-density instruction sets (RISC) suddenly become affordable for your computer design. The advent of the 801 minicomputer and MIPS processor weren't so much "The right idea at the right time". They were the "The right idea before it was time" and Japan just happened to change all of our futures shortly after these papers published and the projects were promoted.
>
> - Don Gillies, PhD CS
> Bluescape, Inc.

VAX 780 had a cache: 8 kB with parity, 2 way set assoc, combined I & D.
It was built from 93425A/74S214 1 kb x 1 SRAMS, 50 ns, 500 mW.
42 chips for the index, 72 for the data on two PCB's.

D Gillies <dwgillies@gmail.com> writes:
>In the 1970's memory was horribly expensive and slow. Cache memories were =
>not very popular because they were only fast if integrated onto a custom ch=
>ip, so virtually nobody had cache memories. Under the circumstances of ver=
>y high memory costs, very dense highly efficient instruction sets can help =
>cut the von Neumann bottleneck in half.

It's not clear that VAX is a "very dense highly efficient instruction
set". Looking at results from my code size measurement postings. And
ARM T32 demonstrates that RISCs can have a very dens instruction set
<2017Aug9.140559@mips.complang.tuwien.ac.at>.

And yes, given the memory prices of the late 1970s, I would expect a
RISC design that's targeted more towards code density than we saw
later. Interestingly, ARM started with the not very dense A32
instruction set, and only added the original Thumb later (and T32
(Thumb2) even later). Decoding such an instruction set would still be
quite a bit easier than decoding the VAX instruction set.

With a pipelined implementation of such an instruction set with the
memory subsystem of the VAX, I expect the implementation to run faster
and require significantly less

>It didn't look like things would g=
>et better in the 1980's.

Moore's law was well-known and it applied nicely to DRAM:

http://www.singularity.com/images/charts/DynamicRamPrice.jpg

The Japanese may have accelerated the development a little, but it was
already happening while the US companies dominated the DRAM market.

So memory was about 30 times more expensive in 1977 (when the VAX was
released) than in 1986 (when MIPS and SPARC were released) or in 1987
(when the Acorn Archimedes 305 was introduced at GBP 799 with 512KB
RAM and the 310 at GBP 875 with 1MB DRAM). I don't know what the VAX
11/780 cost in 1977, but I expect that it's more than 30 times more
than the Archimedes A310 cost in 1987 (admittedly, the VAX 11/780 has
an MMU and was more extensible, so the better comparison might be the
Archimedes A440 (4MB DRAM, 20MB hard disk, GBP 2299).
<https://news.ycombinator.com/item?id=10685739> reports that a VAX
11/780 with 3 RM80 drives (each 121MB), but less than 4MB of memory
cost USD 350k in 1979.

I continue to think that in 1977 one could have implemented a
pipelined CPU with less cost and more performance than a VAX 11/780 by
learning things from the RISC papers (if the RISC papers had
time-traveled into the early 1970s), and the instruction set would
look much more like a RISC than like VAX; maybe it would have looked
like T32 or RV32GC.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Sunday, November 13, 2022 at 12:34:43 PM UTC-6, Anton Ertl wrote:
> D Gillies <dwgi...@gmail.com> writes:
> >In the 1970's memory was horribly expensive and slow. Cache memories were =
> >not very popular because they were only fast if integrated onto a custom ch=
> >ip, so virtually nobody had cache memories. Under the circumstances of ver=
> >y high memory costs, very dense highly efficient instruction sets can help =
> >cut the von Neumann bottleneck in half.
<
> It's not clear that VAX is a "very dense highly efficient instruction
> set". Looking at results from my code size measurement postings. And
> ARM T32 demonstrates that RISCs can have a very dens instruction set
> <2017Aug...@mips.complang.tuwien.ac.at>.
<
Somewhat to be expected. It had but 16 registers, and with defined SP, FP
pre-allocated, it should suffer 15%-18% in the instruction count department.
Furthermore, due to the addressing modes, several strength reducing
compilation techniques were less likely to be employed as these trade
more registers for fewer instructions.
<
So, one might expect VAX to have 20% instruction disadvantage compared
to a register RISC design.
>
> And yes, given the memory prices of the late 1970s, I would expect a
> RISC design that's targeted more towards code density than we saw
> later. Interestingly, ARM started with the not very dense A32
> instruction set, and only added the original Thumb later (and T32
> (Thumb2) even later). Decoding such an instruction set would still be
> quite a bit easier than decoding the VAX instruction set.
>
> With a pipelined implementation of such an instruction set with the
> memory subsystem of the VAX, I expect the implementation to run faster
> and require significantly less
>
> >It didn't look like things would g=
> >et better in the 1980's.
<
> Moore's law was well-known and it applied nicely to DRAM:
>
> http://www.singularity.com/images/charts/DynamicRamPrice.jpg
>
> The Japanese may have accelerated the development a little, but it was
> already happening while the US companies dominated the DRAM market.
>
> So memory was about 30 times more expensive in 1977 (when the VAX was
> released) than in 1986 (when MIPS and SPARC were released) or in 1987
> (when the Acorn Archimedes 305 was introduced at GBP 799 with 512KB
> RAM and the 310 at GBP 875 with 1MB DRAM). I don't know what the VAX
> 11/780 cost in 1977, but I expect that it's more than 30 times more
> than the Archimedes A310 cost in 1987 (admittedly, the VAX 11/780 has
> an MMU and was more extensible, so the better comparison might be the
> Archimedes A440 (4MB DRAM, 20MB hard disk, GBP 2299).
> <https://news.ycombinator.com/item?id=10685739> reports that a VAX
> 11/780 with 3 RM80 drives (each 121MB), but less than 4MB of memory
> cost USD 350k in 1979.
>
> I continue to think that in 1977 one could have implemented a
> pipelined CPU with less cost and more performance than a VAX 11/780 by
> learning things from the RISC papers (if the RISC papers had
> time-traveled into the early 1970s), and the instruction set would
> look much more like a RISC than like VAX; maybe it would have looked
> like T32 or RV32GC.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>