On Friday, September 10, 2021 at 7:58:19 PM UTC-5, John Levine wrote:
> According to JimBrakefield <jim.bra...@ieee.org>:
> >Explore extending a byte code ISA to a two byte ISA.
> >gives both a stack operator and a stack reference
> >and with the few remaining bits one can concoct all manner
> >of extras: replace result into stack reference, pop/push the stack,
> >indirect addressing through the stack reference, apply indexing
> >to the stack reference as an address
> > I.e. use the stack frame of mind/reference to add features which
> >map into RISC instructions easily.
<
> Sounds a lot like a PDP-11.
<
Which died because its successor was too hard to pipeline.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

According to MitchAlsup <MitchAlsup@aol.com>:
>> Sounds a lot like a PDP-11.
><
>Which died because its successor was too hard to pipeline.

The PDP-11 was a really good design for the late 1960s, when memory
was starting to be affordable and microcode ROM was still a lot faster
than core.

The VAX was also a good design for the late 1960s but unfortunately it
was introduced in the late 1970s. It wasn't just that it was too hard
to pipeline. The instruction set was full of overcomplicated
microcoded instructions that were often slower than a sequence of
simple instructions, and they somehow didn't notice that memory was
getting a lot cheaper, with a super-dense super-general instruction
set intended for assembler programmers, and tiny 512 byte pages that
even at the time were obviously too small.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, September 10, 2021 at 8:17:02 PM UTC-5, John Levine wrote:
> According to MitchAlsup <Mitch...@aol.com>:
> >> Sounds a lot like a PDP-11.
> ><
> >Which died because its successor was too hard to pipeline.
> The PDP-11 was a really good design for the late 1960s, when memory
> was starting to be affordable and microcode ROM was still a lot faster
> than core.
>
> The VAX was also a good design for the late 1960s but unfortunately it
> was introduced in the late 1970s. It wasn't just that it was too hard
> to pipeline. The instruction set was full of overcomplicated
> microcoded instructions that were often slower than a sequence of
> simple instructions, and they somehow didn't notice that memory was
> getting a lot cheaper, with a super-dense super-general instruction
> set intended for assembler programmers, and tiny 512 byte pages that
> even at the time were obviously too small.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

So, reinvent the VAX:
keep most of the op-codes, encoded in 8-bits
limit memory references to one operand or result except for mem-mem move
eliminate the double indirect addressing modes
all fits nicely into 24-bits (except for immediate values): op, R1, R2, D, adr-mode

A thing of beauty made practical.

John Levine <johnl@taugh.com> wrote:
> According to MitchAlsup <MitchAlsup@aol.com>:
>>> Sounds a lot like a PDP-11.
>> <
>> Which died because its successor was too hard to pipeline.
>
> The PDP-11 was a really good design for the late 1960s, when memory
> was starting to be affordable and microcode ROM was still a lot faster
> than core.
>
> The VAX was also a good design for the late 1960s but unfortunately it
> was introduced in the late 1970s. It wasn't just that it was too hard
> to pipeline.

> The instruction set was full of overcomplicated
> microcoded instructions that were often slower than a sequence of
> simple instructions,

A Myth what was promoted by RISC proponents, which has been debunked.

RISC only made sense for a decade back in the ancient history of the
1980’s.

Today if I wanted to build a better 16 or 32 bit processor the first step
would be to find what micro coded instructions I could add to reduce
instruction density, and thus win the lowest cost war.

The 8086 with hard coded registers was quite good for the era, but we can
do better today, by micro coding much more complicated sequences.

The first instruction I would add is a one instruction memcpy loop, which
would use three hard coded registers to make the instruction short. The
data register would not be visible so that I could use vector registers if
I wanted. And there would be several variants for copy size and alignment.
And a bit to decide if the count is part of the instruction.

Another instruction I would add is add plus store, etc.

The case for load plus add is harder, and might not make the cut due to
transistor implementation cost outweighing memory transistor savings.
Load compare and branch is in the same boat and has to be added to the
total system cost of load compute.

I seriously think a new 16 or 32 bit processor with micro coded
instructions could win market share, by simple expedient of smaller total
size with code included.

My template is a pipelined 386 with 32 registers and far more complex and
longer micro code instructions.

There is a major company that went for an updated 386, but did not improve
anything besides instruction encoding and minor fixes. Failed to go big and
so failed, go big or go home.

> and they somehow didn't notice that memory was
> getting a lot cheaper, with a super-dense super-general instruction
> set intended for assembler programmers, and tiny 512 byte pages that
> even at the time were obviously too small.
>

Brett <ggtgp@yahoo.com> schrieb:
> John Levine <johnl@taugh.com> wrote:
>> According to MitchAlsup <MitchAlsup@aol.com>:
>>>> Sounds a lot like a PDP-11.
>>> <
>>> Which died because its successor was too hard to pipeline.
>>
>> The PDP-11 was a really good design for the late 1960s, when memory
>> was starting to be affordable and microcode ROM was still a lot faster
>> than core.
>>
>> The VAX was also a good design for the late 1960s but unfortunately it
>> was introduced in the late 1970s. It wasn't just that it was too hard
>> to pipeline.
>
>> The instruction set was full of overcomplicated
>> microcoded instructions that were often slower than a sequence of
>> simple instructions,
>
> A Myth what was promoted by RISC proponents, which has been debunked.

^1 ^2

^1 = Dubious, discuss
^2 = Citation needed

In article <shhl98$3vo$1@dont-email.me>, ggtgp@yahoo.com (Brett) wrote:

> There is a major company that went for an updated 386, but did not
> improve anything besides instruction encoding and minor fixes.
> Failed to go big and so failed, go big or go home.

Citation?

John

On 9/11/2021 7:37 AM, John Dallman wrote:
> In article <shhl98$3vo$1@dont-email.me>, ggtgp@yahoo.com (Brett) wrote:
>
>> There is a major company that went for an updated 386, but did not
>> improve anything besides instruction encoding and minor fixes.
>> Failed to go big and so failed, go big or go home.
>
> Citation?
>
> John
>

I am starting to think about the possibility of a core which only
natively does a restricted subset of x86 and then does a special trap
for cases. The trap likely executes code with a modified ISA and
expanded register set (potentially, REX prefixes are supported during a
trap, but used mostly for the trap handler to have scratch registers).

The trap would be to a special ROM address.

Say, Mod/RM, Mod:
00: [Reg] //MOV Only (Native, 1)
01: [Reg+Disp8] //MOV Only (Native, 1)
10: [Reg+Disp32] //MOV Only (Native, 1)
11: Reg //General Ops

SIB byte:
Mod=00, all index values allowed.
Mod=01/10, only None allowed.

*1:
OP Reg, Mem
Splits into a 2-op sequence on decode:
MOV Ri, Mem
OP Reg, Ri
Where Ri is an internal register.

Ops with memory as a destination would likely split into 3 ops in the
decode stage:
MOV Ri, Mem
OP Ri, Reg
MOV Mem, Ri

Goal would be an x86 variant that could be "usefully" implemented on an
FPGA without being too slow to be usable.

There were apparently a few x86 on FPGA attempts, but many of the
"usable" ones were non-pipelined and generally too slow even to run most
MS-DOS era games. Some others generally required big/expensive FPGAs
(apparently the developers were renting them via a cloud server).

The idea in this case would be to shoe-horn x86 into a RISC-style pipeline.

The Mem-Cache would be able to Stall, ID1 and ID2 would both be able to
trigger interlocks (ID2 for registers, ID1 for decomposing instructions).

Opcode:
Most: 1-Byte Base
0F, F0, F2, F3, 64, 65, 66, 67, 26, 36, 2E, 3E, D8..DF: 2-byte Base

Bytes 2+3 or 3+4, Lookup table for Mod/RM/SIB extension.
Added to Base for encodings which use Mod/RM.
Another table can be used for Byte Word/DWord immediates.

Eg:
04, 0C, 14, 1C, ...: Byte Immed
05, 0D, 15, 1D, ...: Word Immed
80, 83: Byte Immed
81, Word Immed
...

Likely, the IF stage would need to figure out opcode length and would
produce results "unpacked" into a fixed-length format, say:
Opcode: 12 Bits (Prefix Merged)
ModRM / SIB: 20 bits
Imm: 32-bits (Sx/Zx)

This would be followed by another Decode and Register Fetch stage.
EIP would be semi-looped, where IF figures out the next EIP (EIP_1), but
other logic has the ability to override it. This EIP_1 would be captured
for use by EIP-relative instructions.

FPU: Partial Emulation
The Actual FPU would be MM0..MM7, FADD/FSUB/FMUL, ...
Most other FPU instructions are emulated via a trap.
....

MMX/SSE: Probably not supported.

Hardware memory Map:
00000000 .. 0010FFFF: Mimic DOS memory map.
00110000 .. 00FFFFFF: Mix of RAM and ISA hardware addresses.
01000000 .. 7FFFFFFF: More RAM, wraps around.
C0000000 .. FFFFFFFF: PCI emulation, ROM, ...

This would be along with the A20 line and all that other fun.

Goal would be to mostly support enough of the ISA to hopefully run Doom
and Quake and similar, and hopefully run MS-DOS, ...

I guess the debate is whether such a thing could be worthwhile.

I had previously also imagined potentially JIT compiling x86 to BJX2,
but this project hasn't gone very far as of yet (and I have doubts as to
whether it could give satisfactory results). Software emulation could
likely support a larger part of the ISA than would seem realistic via a
hardware implementation.

A JIT would have a slightly easier time as one doesn't necessarily need
to fake all the hardware, but could instead limit things to "userland
only" and then mimic OS level APIs.

I once started on such a project to try to emulate a limited subset of
the Win32 API, but this effort kinda fizzled out without too much results.

Another possibility, granted, would be trying to port DOSBox or similar.
I suspect performance would be pretty terrible though, given that ARM
ports are seemingly unable to do a passable job running Doom or similar
(2), so DOSBox on BJX2 would probably be pretty much hopeless...

*2: RasPi 4 does kinda OK, but older RasPi's and my phones tend to give
what is basically a slide-show.

According to Brett <ggtgp@yahoo.com>:
>> The instruction set was full of overcomplicated
>> microcoded instructions that were often slower than a sequence of
>> simple instructions,
>
>A Myth what was promoted by RISC proponents, which has been debunked.

Dunno how old you are but I wrote programs for Vaxen in the 1970s.

Instructions were an opcode followed by some number of operands, each
of which was a one byte code followed by zero to four bytes of data,
the data length depending on both the operand specifier and the
opcode. It had to decode instructions a byte at a time since you
couldn't tell where the code for operand N+1 was until you knew how
many data bytes followed opeand N. It was also hard to overlap address
calculations since a register autoincement or decrement could affect a
register used in a later operand. Today we could throw millions of
transistors at it with an umpteen stage pipeline that turns the whole
thing into micro-ops, but good luck doing that in 1980.

DEC had super all purpose procedure call and return instructions
which were super slow and overimplemented, so Unix systems never
used them. There were lots of complex instructions that as far as
I can tell nobody used.

Compare that to the IBM 360 where you can tell from the first two
bits of the opcode how long the instruction is, and for the most
part where the memory addresses and register operands are. The 360
wasn't perfect but it certainly aged a lot better.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Dallman <jgd@cix.co.uk> wrote:
> In article <shhl98$3vo$1@dont-email.me>, ggtgp@yahoo.com (Brett) wrote:
>
>> There is a major company that went for an updated 386, but did not
>> improve anything besides instruction encoding and minor fixes.
>> Failed to go big and so failed, go big or go home.
>
> Citation?

Renesas RX CPU
Has byte opcodes with 16 registers and is little endian.
Basically an improved incompatible 386.

> John
>

John Levine <johnl@taugh.com> wrote:
> According to Brett <ggtgp@yahoo.com>:
>>> The instruction set was full of overcomplicated
>>> microcoded instructions that were often slower than a sequence of
>>> simple instructions,
>>
>> A Myth what was promoted by RISC proponents, which has been debunked.
>
> Dunno how old you are but I wrote programs for Vaxen in the 1970s.
>
> Instructions were an opcode followed by some number of operands, each
> of which was a one byte code followed by zero to four bytes of data,
> the data length depending on both the operand specifier and the
> opcode. It had to decode instructions a byte at a time since you
> couldn't tell where the code for operand N+1 was until you knew how
> many data bytes followed opeand N. It was also hard to overlap address
> calculations since a register autoincement or decrement could affect a
> register used in a later operand. Today we could throw millions of
> transistors at it with an umpteen stage pipeline that turns the whole
> thing into micro-ops, but good luck doing that in 1980.

Having horrible instruction encoding has nothing to do with modern
microcode.

Not proposing add instructions where all three operands are memory indirect
addressing. VAX stupidly need not apply.

> DEC had super all purpose procedure call and return instructions
> which were super slow and overimplemented, so Unix systems never
> used them. There were lots of complex instructions that as far as
> I can tell nobody used.

So microcode the shorter call sequence, one wonders why no one with a brain
at DEC did this.

VAX had bad instruction density, same as RISC which tells you how horrible
it was.

> Compare that to the IBM 360 where you can tell from the first two
> bits of the opcode how long the instruction is, and for the most
> part where the memory addresses and register operands are. The 360
> wasn't perfect but it certainly aged a lot better.

Thomas Koenig <tkoenig@netcologne.de> wrote:
> Brett <ggtgp@yahoo.com> schrieb:
>> John Levine <johnl@taugh.com> wrote:
>>> According to MitchAlsup <MitchAlsup@aol.com>:
>>>>> Sounds a lot like a PDP-11.
>>>> <
>>>> Which died because its successor was too hard to pipeline.
>>>
>>> The PDP-11 was a really good design for the late 1960s, when memory
>>> was starting to be affordable and microcode ROM was still a lot faster
>>> than core.
>>>
>>> The VAX was also a good design for the late 1960s but unfortunately it
>>> was introduced in the late 1970s. It wasn't just that it was too hard
>>> to pipeline.
>>
>>> The instruction set was full of overcomplicated
>>> microcoded instructions that were often slower than a sequence of
>>> simple instructions,
>>
>> A Myth what was promoted by RISC proponents, which has been debunked.
>
> ^1 ^2
>
> ^1 = Dubious, discuss
> ^2 = Citation needed

One example I know of is the VAX divide microcode which was 2 cycles slower
than the assembly macro, but this was because the assembly macro cheated on
the last carry and so was half a bit less accurate.

In order to pull off the microcode is slower scam you have to compare a
pipelined compiler output on a pipelined processor to a non-pipelined micro
coded processor, which is cheating. X86 has done just fine with enough
money piled into pipelining the micro ops.

John Levine <johnl@taugh.com> writes:
[VAX]
>Compare that to the IBM 360 where you can tell from the first two
>bits of the opcode how long the instruction is, and for the most
>part where the memory addresses and register operands are. The 360
>wasn't perfect but it certainly aged a lot better.

And yet the 801 project found that they could outperform the 360
descendants by moving to a load/store architecture.

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

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>John Levine <johnl@taugh.com> writes:
>[VAX]
>>Compare that to the IBM 360 where you can tell from the first two
>>bits of the opcode how long the instruction is, and for the most
>>part where the memory addresses and register operands are. The 360
>>wasn't perfect but it certainly aged a lot better.
>
>And yet the 801 project found that they could outperform the 360
>descendants by moving to a load/store architecture.

Sure, but that was 40 years ago. The 801 also only had 24 bit
registers because that how big the memory addresses were at the time.
The point of the 801 wasn't that it was load/store but that the
instructions were simple enough to implement without microcode with a
1980 transistor budget, and that they found that compilers rarely used
the more complex instructions anyway. In the 1960s ROMs were faster
than core memory so even with multiple microinstructions it could keep
the main memory running at full speed, but by 1980 we had
semiconductor RAM and caches so a microcode cycle was no faster than a
main memory cycle.

Descendants of the 801 added back a certain amount of stuff that
turned out to be useful like 32 bit registers and some support for
packed decimal.

The 360 wasn't perfect, e.g., the 12 bit displacements were too small,
branches should have been PC-relative, addresses should have been 32
rather than 24 bits, and the floating point gave awful results, all
things they fixed in later interations of the architecture. But it
seems to me that the 360 lends itself to a pipelined implmentation way
better than a Vax-like design. It can tell the length and format of an
instruction from the first byte (and mostly from the first two bits),
and it can compute the addresses in parallel since address
calculations don't change anything else.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Sunday, September 12, 2021 at 12:10:02 PM UTC-5, John Levine wrote:
> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >John Levine <jo...@taugh.com> writes:
> >[VAX]
> >>Compare that to the IBM 360 where you can tell from the first two
> >>bits of the opcode how long the instruction is, and for the most
> >>part where the memory addresses and register operands are. The 360
> >>wasn't perfect but it certainly aged a lot better.
> >
> >And yet the 801 project found that they could outperform the 360
> >descendants by moving to a load/store architecture.
> Sure, but that was 40 years ago. The 801 also only had 24 bit
> registers because that how big the memory addresses were at the time.
> The point of the 801 wasn't that it was load/store but that the
> instructions were simple enough to implement without microcode with a
> 1980 transistor budget, and that they found that compilers rarely used
> the more complex instructions anyway. In the 1960s ROMs were faster
> than core memory so even with multiple microinstructions it could keep
> the main memory running at full speed, but by 1980 we had
> semiconductor RAM and caches so a microcode cycle was no faster than a
> main memory cycle.
>
> Descendants of the 801 added back a certain amount of stuff that
> turned out to be useful like 32 bit registers and some support for
> packed decimal.
>
> The 360 wasn't perfect, e.g., the 12 bit displacements were too small,
> branches should have been PC-relative, addresses should have been 32
> rather than 24 bits, and the floating point gave awful results, all
> things they fixed in later interations of the architecture. But it
> seems to me that the 360 lends itself to a pipelined implmentation way
> better than a Vax-like design.
<
Yes, ti did.
<
> It can tell the length and format of an
> instruction from the first byte (and mostly from the first two bits),
<
This, BTW, has NOTHING to do with 360 being pipelineable. The RR and
RX formats have everything to do with it being pipelineable.
<
> and it can compute the addresses in parallel since address
> calculations don't change anything else.
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

John Levine wrote:
> According to Brett <ggtgp@yahoo.com>:
>>> The instruction set was full of overcomplicated
>>> microcoded instructions that were often slower than a sequence of
>>> simple instructions,
>> A Myth what was promoted by RISC proponents, which has been debunked.
>
> Dunno how old you are but I wrote programs for Vaxen in the 1970s.
>
> Instructions were an opcode followed by some number of operands, each
> of which was a one byte code followed by zero to four bytes of data,
> the data length depending on both the operand specifier and the
> opcode. It had to decode instructions a byte at a time since you
> couldn't tell where the code for operand N+1 was until you knew how
> many data bytes followed opeand N. It was also hard to overlap address
> calculations since a register autoincement or decrement could affect a
> register used in a later operand. Today we could throw millions of
> transistors at it with an umpteen stage pipeline that turns the whole
> thing into micro-ops, but good luck doing that in 1980.
>
> DEC had super all purpose procedure call and return instructions
> which were super slow and overimplemented, so Unix systems never
> used them. There were lots of complex instructions that as far as
> I can tell nobody used.
>
> Compare that to the IBM 360 where you can tell from the first two
> bits of the opcode how long the instruction is, and for the most
> part where the memory addresses and register operands are. The 360
> wasn't perfect but it certainly aged a lot better.

One thing the VAX did do was spur the investigation in 1985-87
by Yale Patt, Wen-mei Hwu, Michael Shebanow, and others,
called HPS (High Performance Substrate) as a way to work
around VAX's pipeline problems.

Based on Tomasulo and others, HPS looks to be the basis for modern
OoO when picked up by Pentium and others.

HPS, A New Microarchitecture Rationale And Introduction, 1985
http://impact.crhc.illinois.edu/Shared/Papers/Micro-85-HPS_a_new_microarchitecture.pdf

Critical Issues Regarding HPS, A High Performance Microarchitecture, 1985
http://impact.crhc.illinois.edu/shared/papers/Micro-85-HPS_critical_issues.pdf

(and other papers)

Comp.arch tie-in: Mitch co-authors a paper with Pratt, Shebanow, et al.
Single Instruction Stream Parallelism Is Greater than Two, 1991
and co-invents some patents with Shebanow at Motorola,
possibly drawing on the HPS approach for the 88100 design.

John Levine <johnl@taugh.com> writes:
> Sure, but that was 40 years ago. The 801 also only had 24 bit
> registers because that how big the memory addresses were at the time.
> The point of the 801 wasn't that it was load/store but that the
> instructions were simple enough to implement without microcode with a
> 1980 transistor budget, and that they found that compilers rarely used
> the more complex instructions anyway. In the 1960s ROMs were faster
> than core memory so even with multiple microinstructions it could keep
> the main memory running at full speed, but by 1980 we had
> semiconductor RAM and caches so a microcode cycle was no faster than a
> main memory cycle.

801/ROMP ... originally going to be displaywriter followon running CP.r
and programmed in PL.8 ... didn't have any hardware protection domain
.... claim was that PL.8 would only generate "correct" programs and CP.r
would only load/execute correct PL.8 programs. Everything was trusted
and so things that nominally required kernel call to change modes, could
be done inline code. It nominally had 32bit addressing ... top four bits
indexed content of 12bit "segment" register ... with 28bit displacement.
Since the segment registers were 12bits ... they claimed it was 40bit
virtual address ... 28bit displacement appended to the 12 bit contents
of the segment register value (claiming that inline application code
could change the contents of any segment register as easily as pointer
in general register could be changed).

In effect, treating machine as a single 40bit virtual address space,
with 16 segment registers that could each "window" 28bits of that
virtual address space at a time.

when displaywriter followon was killed, they decided to retarget to the
unix workstation market ... having to adopt the hardware to unix
programming paradigm ... including privilege / non-privilege (PC/RT) ...
and getting the company that did AT&T Unix port to IBM/PC for PC/IX to
do one for ROMP (AIX) ... but documentation still would periodically
reference "40-bit" addressing ... sort of being able to map a 32bit
virtual address space into a specific portion of 40-bit machine address
space (theoritically 40-32=8 or 256 32-bit virtual address spaces)
possibly reserving specific 12bit segment register values for "shared
memory" segments.

For RIOS (used in RS/6000) they extended segment registers to 24bits and
documentation would periodically reference 52bit address (i.e. 24+28
instead of the ROMP 12+28 40bit).

there was internal advanced technology conference where we presented a
design for 16processor tightly coupled 370 multiprocessor and the 801
group presented 801/risc, CP.r & PL.8. One of their people claimed that
they had looked at existing operating system code and claimed that it
didn't support 16-way (implying that we couldn't write new code) so I
criticized them for how could they (efficiently) support shared memory
segments ... since their segment size was so large and there were only
16.

I had done a page-mapped filesystem for CP67/CMS and made extensive use
of shared semgnets. When the development group morphed CP67->VM370, they
greatly simplified and/or dropped (like multiprocessor support) a lot of
stuff. By 1975, I had migrated lots of the dropped CP67/CMS stuff to
VM370 (including my page-mapped filesystem stuff with extensive shared
segment sharing as well as multiprocessor support). One of my hobbies
after joining IBM was enhanced production operating systems for internal
datacenters ... and I continued to work on 370 stuff all during the
Future System period ... even perodically ridiculing how they were doing
stuff (FS was completely different than 370 and going to completely
replace it ... lack of new 370 during the FS period is credited with
giving the clone 370 makers their market foothold). some FS info
http://www.jfsowa.com/computer/memo125.htm

I've periodically claimed that John Cocke had taken 801 to the opposite
extreme from FS complexity.

--
virtualization experience starting Jan1968, online at home since Mar1970

On Sunday, September 12, 2021 at 1:03:43 PM UTC-5, EricP wrote:
> John Levine wrote:
> > According to Brett <gg...@yahoo.com>:
> >>> The instruction set was full of overcomplicated
> >>> microcoded instructions that were often slower than a sequence of
> >>> simple instructions,
> >> A Myth what was promoted by RISC proponents, which has been debunked.
> >
> > Dunno how old you are but I wrote programs for Vaxen in the 1970s.
> >
> > Instructions were an opcode followed by some number of operands, each
> > of which was a one byte code followed by zero to four bytes of data,
> > the data length depending on both the operand specifier and the
> > opcode. It had to decode instructions a byte at a time since you
> > couldn't tell where the code for operand N+1 was until you knew how
> > many data bytes followed opeand N. It was also hard to overlap address
> > calculations since a register autoincement or decrement could affect a
> > register used in a later operand. Today we could throw millions of
> > transistors at it with an umpteen stage pipeline that turns the whole
> > thing into micro-ops, but good luck doing that in 1980.
> >
> > DEC had super all purpose procedure call and return instructions
> > which were super slow and overimplemented, so Unix systems never
> > used them. There were lots of complex instructions that as far as
> > I can tell nobody used.
> >
> > Compare that to the IBM 360 where you can tell from the first two
> > bits of the opcode how long the instruction is, and for the most
> > part where the memory addresses and register operands are. The 360
> > wasn't perfect but it certainly aged a lot better.
> One thing the VAX did do was spur the investigation in 1985-87
> by Yale Patt, Wen-mei Hwu, Michael Shebanow, and others,
> called HPS (High Performance Substrate) as a way to work
> around VAX's pipeline problems.
>
> Based on Tomasulo and others, HPS looks to be the basis for modern
> OoO when picked up by Pentium and others.
>
> HPS, A New Microarchitecture Rationale And Introduction, 1985
> http://impact.crhc.illinois.edu/Shared/Papers/Micro-85-HPS_a_new_microarchitecture.pdf
>
> Critical Issues Regarding HPS, A High Performance Microarchitecture, 1985
> http://impact.crhc.illinois.edu/shared/papers/Micro-85-HPS_critical_issues.pdf
>
> (and other papers)
>
> Comp.arch tie-in: Mitch co-authors a paper with Pratt, Shebanow, et al.
> Single Instruction Stream Parallelism Is Greater than Two, 1991
> and co-invents some patents with Shebanow at Motorola,
> possibly drawing on the HPS approach for the 88100 design.
<
Yes, indeed, HPS was, in reality, not a whole lot more than Tomasulo with
multiple common data busses and branch prediction.
<
And we were using many of the ideas, but with entirely different underpinnings
than HPS. For example, we used a physical register file rather than a RAT, and
created a way to backup a branch misprediction and issue on the alternate path
in the same cycle.
<
This was for the 88100 architecture and for the 88120 design point.

According to Anne & Lynn Wheeler <lynn@garlic.com>:
>when displaywriter followon was killed, they decided to retarget to the
>unix workstation market ... having to adopt the hardware to unix
>programming paradigm ... including privilege / non-privilege (PC/RT) ...
>and getting the company that did AT&T Unix port to IBM/PC for PC/IX to
>do one for ROMP (AIX) ...

Yeah, that was me. I worked for Interactive and wrote the ROMP assembler
and linker for AIX. It sat on top of an IBM monitor called the VRM which
provided us 28 bit segments we could map in and out of a process address
space, which was fine except the VRM was dog slow.

Someone else did a native BSD port which worked a lot better.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <johnl@taugh.com> writes:
> Yeah, that was me. I worked for Interactive and wrote the ROMP assembler
> and linker for AIX. It sat on top of an IBM monitor called the VRM which
> provided us 28 bit segments we could map in and out of a process address
> space, which was fine except the VRM was dog slow.
>
> Someone else did a native BSD port which worked a lot better.

I was working with the people doing the BSD port ... the Austin people
claimed that it was quicker, less resources and cheaper for them to
build a VRM with abstract virtual machine and then have you do the AT&T
port to the abstract virtual machine ... than having you do the AT&T
port directly to the bare hardware. Actually I think they had 200 PL.8
programmers and they needed something for them to do (aka the VRM).

The Palo Alto group was doing BSD port to VM370 virtual machine
mainframe when they got retargeted to do it directly port directly to
bare machine. I think the BSD port directly to bare PC/RT hardware was
1/10th the effort (or less) to do (just) the VRM.

Just one of the less obvious downsides that Austin ran into was device
drivers for new hardware 1st had to be done in C for unix ... and then
repeated in PL.8 for VRM.

trivia: I had been working with one of the people in Los Gatos VLSI
tools group using (metaware) TWS and did Pascal for IBM mainframe
(original for internal VLSI tools, later released as vs/pascal)... to
work on C language front-end. I left for a summer lecture tour in Europe
.... when I got back he had left IBM and was working for Metaware. I
talked the Palo Alto people into hiring Metaware to do the C-compiler
for the BSD mainframe port ... which they then had Metaware do ROMP
backend when they were redirected to PC/RT port ("AOS").

Note the Palo Alto group was also working with UCLA and doing LOCUS
ports ... which was eventually released as AIX/370 and AIX/386.
https://en.wikipedia.org/wiki/LOCUS

aka an "AIX" having nothing to do with PC/RT AIX or RS/6000 AIX.

--
virtualization experience starting Jan1968, online at home since Mar1970

Anne & Lynn Wheeler wrote:
>
> trivia: I had been working with one of the people in Los Gatos VLSI
> tools group using (metaware) TWS and did Pascal for IBM mainframe
> (original for internal VLSI tools, later released as vs/pascal)... to

Wow!

I once used that vs/pascal to implement large packet Kermit, using up to
a full page (25x80=2000 bytes) of a 3270 emulator as the packet size,
instead of just a single 80-byte line.

The result was file transfers running at the same speed as the 3270/PC
(or the /AT 286 version) while using 3270 protocol emulators to allow
ascii serial port connections.

I remember that Pascal version as being quite nice. :-)

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

John Levine <johnl@taugh.com> writes:
>According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>John Levine <johnl@taugh.com> writes:
>>[VAX]
>>>Compare that to the IBM 360 where you can tell from the first two
>>>bits of the opcode how long the instruction is, and for the most
>>>part where the memory addresses and register operands are. The 360
>>>wasn't perfect but it certainly aged a lot better.
>>
>>And yet the 801 project found that they could outperform the 360
>>descendants by moving to a load/store architecture.
>
>Sure, but that was 40 years ago. The 801 also only had 24 bit
>registers because that how big the memory addresses were at the time.
>The point of the 801 wasn't that it was load/store but that the
>instructions were simple enough to implement without microcode with a
>1980 transistor budget, and that they found that compilers rarely used
>the more complex instructions anyway.

The first implementation was "Motorola MECL-10K discrete component
technology on large wire-wrapped custom boards." So the transistor
budget was not limited by what fit on a single chip. So what limited
the transistor budget? Or was it that they just wanted to leave out
everything that they could do without, making it easier to make the
rest fast? They certainly made it really fast.

>In the 1960s ROMs were faster
>than core memory so even with multiple microinstructions it could keep
>the main memory running at full speed, but by 1980 we had
>semiconductor RAM and caches so a microcode cycle was no faster than a
>main memory cycle.

The IBM 801 ran at 15MHZ, the Vax 11/780 at 5MHZ and had a 2KB cache,
so apparently the main memory was too slow for 5MHz (but cache was
probably at the same speed as the microcode store). The IBM 801 (as
describe by Radin
<https://course.ece.cmu.edu/~ece447/s12/lib/exe/fetch.php?media=wiki:801-radin-1982.pdf>,
which is already the 32-bit version) had a split instruction and data
cache with 32-byte cache lines. I have not found cache sizes;
associativity seems to be at least 2-way (they mention LRU
replacement).

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

Anton Ertl wrote:
> John Levine <johnl@taugh.com> writes:
>> According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>>> John Levine <johnl@taugh.com> writes:
>>> [VAX]
>>>> Compare that to the IBM 360 where you can tell from the first two
>>>> bits of the opcode how long the instruction is, and for the most
>>>> part where the memory addresses and register operands are. The 360
>>>> wasn't perfect but it certainly aged a lot better.
>>> And yet the 801 project found that they could outperform the 360
>>> descendants by moving to a load/store architecture.
>> Sure, but that was 40 years ago. The 801 also only had 24 bit
>> registers because that how big the memory addresses were at the time.
>> The point of the 801 wasn't that it was load/store but that the
>> instructions were simple enough to implement without microcode with a
>> 1980 transistor budget, and that they found that compilers rarely used
>> the more complex instructions anyway.
>
> The first implementation was "Motorola MECL-10K discrete component
> technology on large wire-wrapped custom boards." So the transistor
> budget was not limited by what fit on a single chip. So what limited
> the transistor budget? Or was it that they just wanted to leave out
> everything that they could do without, making it easier to make the
> rest fast? They certainly made it really fast.

ECL was invented by IBM in 1956. Originally called current-steering logic,
it was used in the Stretch, IBM 7090, and IBM 7094 computers (circa 1959).
MECL is Motorola's integrated circuit ECL logic developed starting in 1962.
By 1971 Motorola had their MECL 10,000 series.

The IBM 801 was circa 1976.

https://en.wikipedia.org/wiki/Emitter-coupled_logic#history

"MECL III in 1968 with 1-nanosecond gate propagation time and 300 MHz
flip-flop toggle rates, and the 10,000 series (with lower power
consumption and controlled edge speeds) in 1971."

ECL has a fan-out of 20 (up to 80) and allows wired-OR logic.
MECL 10K series is similar to TTL with DIP packages for things like
quad 2-input NOR, dual flip-flop, 8-1 mux, 64-bit RAM, 4-bit ALU, etc.

The design rules for ECL are different from TTL.
I've never worked with ECL but from what I read wire reflections are a
major consideration. There are different rules for PCB layout, grounding.
Wire-wrap could have issues with wire length (~2-3ns per foot),
long wires need damping resistors, and each wrap connection has
to be perfect or you get resistance reflections
(so you might have to scope each connection).

Other than wire length, I can't think of anything that would
otherwise limit the physical size and therefore the complexity.

>> In the 1960s ROMs were faster
>> than core memory so even with multiple microinstructions it could keep
>> the main memory running at full speed, but by 1980 we had
>> semiconductor RAM and caches so a microcode cycle was no faster than a
>> main memory cycle.
>
> The IBM 801 ran at 15MHZ, the Vax 11/780 at 5MHZ and had a 2KB cache,
> so apparently the main memory was too slow for 5MHz (but cache was
> probably at the same speed as the microcode store). The IBM 801 (as
> describe by Radin
> <https://course.ece.cmu.edu/~ece447/s12/lib/exe/fetch.php?media=wiki:801-radin-1982.pdf>,
> which is already the 32-bit version) had a split instruction and data
> cache with 32-byte cache lines. I have not found cache sizes;
> associativity seems to be at least 2-way (they mention LRU
> replacement).
>
> - anton

Bitsavers has two IBM Company Confidential docs from 1976 which
might provide more insight as why they made the decisions they did.
The overview says they had a project team of 20.

The 801 Minicomputer - An Overview, 1976
http://bitsavers.org/pdf/ibm/system801/The_801_Minicomputer_an_Overview_Sep76.pdf

IBM System 801 Principles of Operation, 1976
http://bitsavers.org/pdf/ibm/system801/System_801_Principles_of_Operation_Jan76.pdf

They definitely refer to it as a minicomputer and a prototype.
In a big company like IBM with many entrenched products,
not appearing to threaten other products and thereby step
on toes is a career consideration, part of the unwritten rules.
It can conjecture that they might have had to get "permission"
to move from 24 to 32 bits.

On Monday, September 13, 2021 at 8:16:51 AM UTC-5, EricP wrote:
> Anton Ertl wrote:
> > John Levine <jo...@taugh.com> writes:
> >> According to Anton Ertl <an...@mips.complang.tuwien.ac.at>:
> >>> John Levine <jo...@taugh.com> writes:
> >>> [VAX]
> >>>> Compare that to the IBM 360 where you can tell from the first two
> >>>> bits of the opcode how long the instruction is, and for the most
> >>>> part where the memory addresses and register operands are. The 360
> >>>> wasn't perfect but it certainly aged a lot better.
> >>> And yet the 801 project found that they could outperform the 360
> >>> descendants by moving to a load/store architecture.
> >> Sure, but that was 40 years ago. The 801 also only had 24 bit
> >> registers because that how big the memory addresses were at the time.
> >> The point of the 801 wasn't that it was load/store but that the
> >> instructions were simple enough to implement without microcode with a
> >> 1980 transistor budget, and that they found that compilers rarely used
> >> the more complex instructions anyway.
> >
> > The first implementation was "Motorola MECL-10K discrete component
> > technology on large wire-wrapped custom boards." So the transistor
> > budget was not limited by what fit on a single chip. So what limited
> > the transistor budget? Or was it that they just wanted to leave out
> > everything that they could do without, making it easier to make the
> > rest fast? They certainly made it really fast.
> ECL was invented by IBM in 1956. Originally called current-steering logic,
> it was used in the Stretch, IBM 7090, and IBM 7094 computers (circa 1959).
> MECL is Motorola's integrated circuit ECL logic developed starting in 1962.
> By 1971 Motorola had their MECL 10,000 series.
>
> The IBM 801 was circa 1976.
>
> https://en.wikipedia.org/wiki/Emitter-coupled_logic#history
>
> "MECL III in 1968 with 1-nanosecond gate propagation time and 300 MHz
> flip-flop toggle rates, and the 10,000 series (with lower power
> consumption and controlled edge speeds) in 1971."
>
> ECL has a fan-out of 20 (up to 80) and allows wired-OR logic.
> MECL 10K series is similar to TTL with DIP packages for things like
> quad 2-input NOR, dual flip-flop, 8-1 mux, 64-bit RAM, 4-bit ALU, etc.
>
> The design rules for ECL are different from TTL.
> I've never worked with ECL but from what I read wire reflections are a
> major consideration. There are different rules for PCB layout, grounding.
<
ECL has its major voltage of -5.2 (that is MINUS 5.2V) and Gnd is 0V.
All of the load comes from the Gnd <plane>.
<
> Wire-wrap could have issues with wire length (~2-3ns per foot),
> long wires need damping resistors, and each wrap connection has
> to be perfect or you get resistance reflections
> (so you might have to scope each connection).
<
You had 3 choices, 1) wires shorter than 5", 2) parallel damping,
3) series damping. In series damping one puts a resistor equal
to the characteristic impedance near the driving gate and a high
value (1K Ohms) resistor at the terminating end of the wire. In
parallel damping one puts a resistor at the terminating end the
resistance equaling the characteristic impedance to -2.0V.
<
Both arrangements result in no overshoot/undershoot on the logic
wire.
<
>
> Other than wire length, I can't think of anything that would
> otherwise limit the physical size and therefore the complexity.
<
Indeed, Cray built refrigerator sized wire wrap boards that ran at
80 MHz with sub nanosecond clock delay+skew+jitter.
<
> >> In the 1960s ROMs were faster
> >> than core memory so even with multiple microinstructions it could keep
> >> the main memory running at full speed, but by 1980 we had
> >> semiconductor RAM and caches so a microcode cycle was no faster than a
> >> main memory cycle.
> >
> > The IBM 801 ran at 15MHZ, the Vax 11/780 at 5MHZ and had a 2KB cache,
> > so apparently the main memory was too slow for 5MHz (but cache was
> > probably at the same speed as the microcode store). The IBM 801 (as
> > describe by Radin
> > <https://course.ece.cmu.edu/~ece447/s12/lib/exe/fetch.php?media=wiki:801-radin-1982.pdf>,
> > which is already the 32-bit version) had a split instruction and data
> > cache with 32-byte cache lines. I have not found cache sizes;
> > associativity seems to be at least 2-way (they mention LRU
> > replacement).
> >
> > - anton
> Bitsavers has two IBM Company Confidential docs from 1976 which
> might provide more insight as why they made the decisions they did.
> The overview says they had a project team of 20.
>
> The 801 Minicomputer - An Overview, 1976
> http://bitsavers.org/pdf/ibm/system801/The_801_Minicomputer_an_Overview_Sep76.pdf
>
> IBM System 801 Principles of Operation, 1976
> http://bitsavers.org/pdf/ibm/system801/System_801_Principles_of_Operation_Jan76.pdf
>
> They definitely refer to it as a minicomputer and a prototype.
> In a big company like IBM with many entrenched products,
> not appearing to threaten other products and thereby step
> on toes is a career consideration, part of the unwritten rules.
> It can conjecture that they might have had to get "permission"
> to move from 24 to 32 bits.

Brett <ggtgp@yahoo.com> wrote:
> John Levine <johnl@taugh.com> wrote:
>> According to MitchAlsup <MitchAlsup@aol.com>:
>>>> Sounds a lot like a PDP-11.
>>> <
>>> Which died because its successor was too hard to pipeline.
>>
>> The PDP-11 was a really good design for the late 1960s, when memory
>> was starting to be affordable and microcode ROM was still a lot faster
>> than core.
>>
>> The VAX was also a good design for the late 1960s but unfortunately it
>> was introduced in the late 1970s. It wasn't just that it was too hard
>> to pipeline.
>
>> The instruction set was full of overcomplicated
>> microcoded instructions that were often slower than a sequence of
>> simple instructions,
>
> A Myth what was promoted by RISC proponents, which has been debunked.

An alternative or addition is wide packed instructions with chaining.
The example of wide packed is Itanic, but of course they did it wrong.

You would go 256 bits wide and support a variable number of instructions in
the packet and by supporting chaining you save 10 bits of register
specifiers for each chain segment, minus a bit to indicate the chain link.

You would use heads and tails encoding and support jumps into and out of
the packet. Chaining alone should give you the best instruction density and
add some micro coded instructions and you should get dominating instruction
density that makes manufactures take a serious look at your offerings.

A variable width instruction set can support chaining today by just adding
the instructions, I am perplexed as to why no one has.

A new architecture needs a hook to get noticed and dominating instruction
density is one way to get that notice.

> RISC only made sense for a decade back in the ancient history of the
> 1980’s.
>
> Today if I wanted to build a better 16 or 32 bit processor the first step
> would be to find what micro coded instructions I could add to reduce
> instruction density, and thus win the lowest cost war.
>
> The 8086 with hard coded registers was quite good for the era, but we can
> do better today, by micro coding much more complicated sequences.
>
> The first instruction I would add is a one instruction memcpy loop, which
> would use three hard coded registers to make the instruction short. The
> data register would not be visible so that I could use vector registers if
> I wanted. And there would be several variants for copy size and alignment.
> And a bit to decide if the count is part of the instruction.
>
> Another instruction I would add is add plus store, etc.
>
> The case for load plus add is harder, and might not make the cut due to
> transistor implementation cost outweighing memory transistor savings.
> Load compare and branch is in the same boat and has to be added to the
> total system cost of load compute.
>
> I seriously think a new 16 or 32 bit processor with micro coded
> instructions could win market share, by simple expedient of smaller total
> size with code included.
>
> My template is a pipelined 386 with 32 registers and far more complex and
> longer micro code instructions.
>
> There is a major company that went for an updated 386, but did not improve
> anything besides instruction encoding and minor fixes. Failed to go big and
> so failed, go big or go home.
>
>> and they somehow didn't notice that memory was
>> getting a lot cheaper, with a super-dense super-general instruction
>> set intended for assembler programmers, and tiny 512 byte pages that
>> even at the time were obviously too small.

On 9/13/2021 1:38 PM, Brett wrote:
> Brett <ggtgp@yahoo.com> wrote:
>> John Levine <johnl@taugh.com> wrote:
>>> According to MitchAlsup <MitchAlsup@aol.com>:
>>>>> Sounds a lot like a PDP-11.
>>>> <
>>>> Which died because its successor was too hard to pipeline.
>>>
>>> The PDP-11 was a really good design for the late 1960s, when memory
>>> was starting to be affordable and microcode ROM was still a lot faster
>>> than core.
>>>
>>> The VAX was also a good design for the late 1960s but unfortunately it
>>> was introduced in the late 1970s. It wasn't just that it was too hard
>>> to pipeline.
>>
>>> The instruction set was full of overcomplicated
>>> microcoded instructions that were often slower than a sequence of
>>> simple instructions,
>>
>> A Myth what was promoted by RISC proponents, which has been debunked.
>
> An alternative or addition is wide packed instructions with chaining.
> The example of wide packed is Itanic, but of course they did it wrong.
>
> You would go 256 bits wide and support a variable number of instructions in
> the packet and by supporting chaining you save 10 bits of register
> specifiers for each chain segment, minus a bit to indicate the chain link.
>
> You would use heads and tails encoding and support jumps into and out of
> the packet. Chaining alone should give you the best instruction density and
> add some micro coded instructions and you should get dominating instruction
> density that makes manufactures take a serious look at your offerings.
>
> A variable width instruction set can support chaining today by just adding
> the instructions, I am perplexed as to why no one has.

And how is this different from Mill belt?

> A new architecture needs a hook to get noticed and dominating instruction
> density is one way to get that notice.
>