On Monday, June 7, 2021 at 7:39:42 PM UTC-5, Quadibloc wrote:
> On Monday, June 7, 2021 at 4:12:51 PM UTC-6, MitchAlsup wrote:
> > On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
>
> > > Only thing is, it breaks down if one wants to use more than 64K of memory with
> > > it.
>
> > Give a DPD-11 64-bit registers and you will surprised at how good the code density
> > is, right up until you have to branch/call/jump farther than ±32KB.. But I bet there
> > is some kind of "accommodation" to get larger constants that would work fairly well.
> Well, the solution to using a larger address space than 64K was sitting right in
> front of me, as I'm already making use of it extensively in the Concertina II as it
> is.
>
> In addition to combining the PDP-11 (eight registers) with the TI 9900 (but only four
> address modes), I just have to put the IBM System/360 Model 20 into the mix. So the
> programmer's model includes eight base registers, which are mapped to the ones I
> use in the regular instruction set.
<
> > And then there is that "pipelineing" problem.
<
> In my opinion, the cure for that is SMT. That is, yes, this particular dense code format
> gives poor performance - if it's the only thing running on the machine. If it allternates with
> other code, then even in the absence of OoO to fix things, there's no real problem.
>
> So if you're happy to be one of sixteen concurrent threads, use the PDP-11-like format
> for higher code density. If you want to hog the machine all to yourself, make efficient
> use of it by using the VLIW block formats instead.
<
This really kills the caches, predictors, and TLBs.
>
> John Savard

On Monday, June 7, 2021 at 7:55:17 PM UTC-6, MitchAlsup wrote:

> This really kills the caches, predictors, and TLBs.

Oh, dear. Now you tell me.

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

now has a pretty picture of the instruction formats for this new category of
instructions. Doubtless, though, they will only execute badly on _some_ implementations.
Others won't have fancy things like caches, branch predictors, or transaction
look-aside buffers.

John Savard

On 2021-06-07, MitchAlsup wrote:
> On Monday, June 7, 2021 at 12:22:45 PM UTC-5, Quadibloc wrote:
>> On Sunday, June 6, 2021 at 8:00:40 PM UTC-6, MitchAlsup wrote:
>>> On Sunday, June 6, 2021 at 8:51:29 PM UTC-5, Quadibloc wrote:
>>
>>>> What am I up to?
>>
>>> {with only mild sarcasm::}
>>> It appears you are wandering around in the dark without a candle.
>> And why am I doing this, since I _have_ Computer Architecture: A
>> Quantitative Approach readily at hand? Surely that means I'm engaging
>> in _intentional_ perversity?
>>
>> One way my design can be thought of is... as a *marketing-driven*
>> design.
>>
>> You're used to programming an IBM 360 or one of its successors?
>>
>> Well, just like a System/360, we have full base-index addressing in
>> only 32 bits, and memory-to-memory string and packed decimal
>> instructions in only 48 bits!
>>
>> You're used to programming a Motorola 68000, or an x86, or
>> other recent microprocessors?
>>
>> Our instructions have full 16-bit memory displacements!
>>
>> You're used to programming a Cray I, or similar vector machine?
>>
>> Our architecture includes a set of 64 vector registers, each containing
>> 64 scalar values, performing operations similar to those that classic
>> vector architectures based on the Cray offered.
>>
>> You're used to programming a RISC architecture?
>>
>> Our integer and floating-point register banks have 32 registers each.
>> Our register operate instructions include a bit to enable changing the
>> condition codes, so you can place instructions between an operate
>> instruction and a conditional branch based on its result, to reduce the
>> impact of this dependency.
>>
>> You've made use of VLIW DSP processors, like the TMS6000C?
>>
>> We offer the ability to explictly indicate when instructions can execute
>> in parallel, and which instructions depend on the results of which other
>> instructions.
>>
>> So no matter what computer you had been working with before,
>> you'll find the features you were familiar with, and want to see in
>> the next computer you use here in our architecture!
> <
> But the very vast majority of computer users see the computer through a
> high level language and its associated compiler and libraries.
>
> Also note: My 66000 code density seems to be "on par" with x86-64.

Actually I was pleasantly surprised when I discovered that MRISC32 code
is often denser than x86_64 code. When I compare code "quality" (how
efficient code GCC generates) and density I usually compare against
the following bunch: x86_64, AArch64, ARMv7 (Thumb2) and RISC-V. In my
tests x86_64 tends to be the worst in the bunch when it comes to code
density, and ARMv7 tends to be the most compact.

While MRISC32 uses fixed size 32-bit instruction words (I focused
on easily decoded formats), which according to common wisdom should lead
to poor code density, I tried to make those bits count by having
relatively powerful instructions and useful immediate value encodings
(unlike RISC-V, for instance), as well as wide range PC-relative
addressing. And it seems to do the trick.

BTW, I believe that x86_64 code is so spacious because modern
instructions use longer encodings than those from the original
instruction set (e.g. SSE2/AVX mulsd vs x87 fmul). Had it not been
for the baggage it would certainly be possible for x86 to use more
compact encodings.

/Marcus

>>
>> John Savard

On 2021-06-07, MitchAlsup wrote:
> On Monday, June 7, 2021 at 1:08:10 PM UTC-5, BGB wrote:
>> On 6/7/2021 3:45 AM, Marcus wrote:
>>> On 2021-06-04, BGB wrote:
>>>> On 6/4/2021 2:10 PM, Marcus wrote:
>>>>> On 2021-06-04, BGB wrote:
>>>>>>
>>>
>>> [snip]
>>>
>>>>>>
>>>>>
>>>>> I would guess that part of what you're measuring is the compiler
>>>>> maturity level. On my in-order CPU that does not even have I$ nor D$
>>>>> (but a shared single cycle 32-bit BRAM bus), I got something like
>>>>> 0.7-0.8 DMIPS/MHz - but that's using GCC 11 and some hand-optimized
>>>>> C library functions (memcpy etc). Before optimizing the libc routines
>>>>> I got 0.5 DMIPS/MHz.
>>>>>
>>>>> With a proper I$ (that I'm currently working on) I expect to get closer
>>>>> to 1 DMIPS/MHz.
>>>>>
>>>
>>> BTW, my point here is that Dhrystone is very much a compiler and libc
>>> test, not just a CPU test. AFAICT it's perfectly OK to hand-optimize
>>> libc functions (memcpy, memset, strcmp, ...), and using MRISC32 vector
>>> operations in the hot libc functions helped to bump the Dhrystone score
>>> from ~0.5 to ~0.7 IIRC.
>>>
>> Yeah.
>>
>> My case, memcpy, memset, and strcmp are semi-optimized.
>>
>> Memcpy and memset are transformed mostly into bigger operations, namely
>> mostly MOV.X operations (when properly aligned), or MOV.Q (otherwise).
>>
>> The original code in the C library used (*) mostly loops which copied /
>> set data one byte at a time, which was not particularly good for
>> performance.
>>
>>
>> *: Mostly a fork of an old version of PDPCLIB, which was originally
>> written for some bizarre mix of IBM mainframes and an MS-DOS clone. Some
>> of the code in the C library was "not particularly high quality", but
>> not quite to the level to where "abandon all of it and start over"
>> seemed necessary. Had mostly been rewriting parts of it when stumbling
>> onto things that "particularly sucked".
>>
>>
>> Strcmp is harder to optimize mostly for the reason that one needs to
>> detect the presence of a zero byte and end the loop. I don't have a
>> dedicated instruction for this task (eg: "Set SR.T if QWord contains a
>> zero byte"), as it is fairly specialized.
> <
> Strcmp is only hard if you attempt to run it wide with SIMD, it is brain
> dead easy to run it as wide as your cache port using virtual vectors.
> Thus, SIMD is the problem not C strings.
> <
> Secondarily, if instead of SET.?? you had a compare instruction that
> delivered bit vectors of "just about anything you would want to know
> about" between the comparands, this would fall out for free. as far
> back as 88110, the compare instruction was augmented to contain
> "any byte zero", an "any halfword zero". This is the added utility of
> CMP delivering a bit vector rather than delivering a true or false.

Actually, here the SIMD style byte-wise instructions of the MRISC32
come to good use. The SEQ.B instruction will produce a true/false value
(0xff/0x00) for each individual byte. When comparing to the zero
register, you'll get a non-zero 32-bit result if at least one of the
bytes equals 0x00.

Thus, the core loop of strcmp looks like this:

loop:
ldw s4, s1, s3
ldw s5, s2, s3
add s3, s3, #4
sne s6, s4, s5 ; Are the words different?
bs s6, found_diff ; (branch if set)
seq.b s6, s4, z ; Do we have a zero byte in the word?
bz s6, loop ; (branch if zero)

On a related note: zero-terminated strings should never be used in
performance critical code. Modern code that cares about performance
should use proper string types with a string length property.

> <
> But of course, you then need an efficient means to convert a bit in the
> vector into a branch condition, or convert a bit into a true or false.
> 88K and My 66000 both have these.
>>
>> Then again, such an instruction could help with strcpy/strcmp/strlen/...
>> so could maybe be justified.
> <
> I explicitly made the LOOP instruction in My 66000 deal with the loop
> control of strncpy and strncmp where there are bot counted loop
> terminations and data conditional loop terminations.
> <
> Basically every leaf level subroutine in the str and mem libraries vectorizes
> under VVM.
>

EricP <ThatWouldBeTelling@thevillage.com> writes:
>Anton Ertl wrote:
>> Since then the sweet spot seems to have been the 14-19 stages or so
>> that Intel and AMD have been using (wikichip claims 19 stages for
>> Zen-Zen3 and 14-19 for Skylake and Ice Lake). But Apple's A14 shows
>> us that you can do lower-clocked (and likely shorter-pipeline) cores
>> that have so much more IPC that they have competetive performance.
>> Makes me wonder whether there is an even sweeter spot in between.
>
>I was referring to in-order pipelines because the analysis is simpler.
>Pipelining in OoO modules like rename, scheduling or issue brings
>a whole extra level of complexity.

Given that OoO decouples the front end from the functional units and
from retirement, the question is how pipeline length is determined for
OoO instruction sets. I guess it's the minimal number of cycles for
processing an instruction.

Anyway, given the extra complexity you noted, one might expect that
OoO microarchitectures have more stages than in-order
microarchitectures. But if we look at the in-order Bonnell, we see
16-19 stages, while the OoO Sandy Bridge has 14-19 stages. How does
that affect clock speed? The 32nm shrink of Bonnell (Saltwell) was
available at 0.6-2.13GHz, while the Sandy Bridge was available at
1.6-3.6GHz, although admittedly at a higher power consumption point
(but also at much higher IPC).

If we look at Aarch64, we see the in-order Cortex-A55 with 8 stages,
and the OoO Cortex-A76 with 13 stages. In the Kirin 990 4G, the
medium-performance A76s are clocked at 2.09GHz and the Cortex-A55 is
clocked at 1.86GHz, so if we assume that the medium-performance A76s
are run at high-efficiency clock speeds (the high-performance A76s are
significantly faster), we see that some of the deeper pipeline is due
to the higher complexity, and some of it is useful for a higher clock
rate.

Looking back to earlier ARM cores we see:

stages
13 A8 2005 in-order
9-12 A9 2007 OoO
8 A5 2009 in-order
15+ A15 2010 OoO big
8 A7 2011 in-order LITTLE
11 A12 2013 OoO big

Not sure if we can draw general conclusions from that.

Sources: en.wikichip.org, en.wikipedia.org

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

MitchAlsup <MitchAlsup@aol.com> writes:
>Well, we blew right though 4GB, and are in spitting distance of not needing to run
>the swapper on many/most home computers !

We are long past that point. Swapping hundreds of MB to a hard disk
and swapping them back in from a hard disk is so slow that it is
impractical. With SSDs it may have become practical again, but if we
did not need to swap a decade ago, why would we need to swap now?

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

On Tuesday, June 8, 2021 at 3:22:38 AM UTC-5, Anton Ertl wrote:
> EricP <ThatWould...@thevillage.com> writes:
> >Anton Ertl wrote:
> >> Since then the sweet spot seems to have been the 14-19 stages or so
> >> that Intel and AMD have been using (wikichip claims 19 stages for
> >> Zen-Zen3 and 14-19 for Skylake and Ice Lake). But Apple's A14 shows
> >> us that you can do lower-clocked (and likely shorter-pipeline) cores
> >> that have so much more IPC that they have competetive performance.
> >> Makes me wonder whether there is an even sweeter spot in between.
> >
> >I was referring to in-order pipelines because the analysis is simpler.
> >Pipelining in OoO modules like rename, scheduling or issue brings
> >a whole extra level of complexity.
<
> Given that OoO decouples the front end from the functional units and
> from retirement, the question is how pipeline length is determined for
> OoO instruction sets. I guess it's the minimal number of cycles for
> processing an instruction.
<
Mc 88100 had a 5 stage pipeline was 1-wide partially ordered without
renaming.
<
Mc 88120 had a 6 stage pipeline was 6-wide OoO with renaming.
<
We figured out how to perform renaming without adding a pipeline
stage, AND we figured out how to put the reservation stations in
a feed back loop rather than dedicate a stage to them; finally, we
figured out how to perform 3 memory refs per cycle, and to push
and pull a cache line through the pin interface every cycle.
<
The general trend, though, is to add about 5 stages:: rename, station,
complete, retire, and write back.
>
> Anyway, given the extra complexity you noted, one might expect that
> OoO microarchitectures have more stages than in-order
> microarchitectures. But if we look at the in-order Bonnell, we see
> 16-19 stages, while the OoO Sandy Bridge has 14-19 stages. How does
> that affect clock speed? The 32nm shrink of Bonnell (Saltwell) was
> available at 0.6-2.13GHz, while the Sandy Bridge was available at
> 1.6-3.6GHz, although admittedly at a higher power consumption point
> (but also at much higher IPC).
>
> If we look at Aarch64, we see the in-order Cortex-A55 with 8 stages,
> and the OoO Cortex-A76 with 13 stages. In the Kirin 990 4G, the
> medium-performance A76s are clocked at 2.09GHz and the Cortex-A55 is
> clocked at 1.86GHz, so if we assume that the medium-performance A76s
> are run at high-efficiency clock speeds (the high-performance A76s are
> significantly faster), we see that some of the deeper pipeline is due
> to the higher complexity, and some of it is useful for a higher clock
> rate.
>
> Looking back to earlier ARM cores we see:
>
> stages
> 13 A8 2005 in-order
> 9-12 A9 2007 OoO
> 8 A5 2009 in-order
> 15+ A15 2010 OoO big
> 8 A7 2011 in-order LITTLE
> 11 A12 2013 OoO big
>
> Not sure if we can draw general conclusions from that.
>
> Sources: en.wikichip.org, en.wikipedia.org
>
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Tuesday, June 8, 2021 at 3:26:10 AM UTC-5, Anton Ertl wrote:
> MitchAlsup <Mitch...@aol.com> writes:
> >Well, we blew right though 4GB, and are in spitting distance of not needing to run
> >the swapper on many/most home computers !
<
> We are long past that point. Swapping hundreds of MB to a hard disk
> and swapping them back in from a hard disk is so slow that it is
> impractical. With SSDs it may have become practical again, but if we
> did not need to swap a decade ago, why would we need to swap now?
<
Application bloat.
<
And I should note: I am running on a machine bought in April of 2012.
<
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Tue, 08 Jun 2021 08:22:57 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:

>MitchAlsup <MitchAlsup@aol.com> writes:
>>Well, we blew right though 4GB, and are in spitting distance of not needing to run
>>the swapper on many/most home computers !
>
>We are long past that point. Swapping hundreds of MB to a hard disk
>and swapping them back in from a hard disk is so slow that it is
>impractical. With SSDs it may have become practical again, but if we
>did not need to swap a decade ago, why would we need to swap now?
>
>- anton

Well, for one thing, the /average/ home machine still only has 8GB of
RAM. And since 90% of them are running Windows ... which handles
memory very differently than Unix/Linux ... unless the user runs only
a couple of simultaneous applications the machine very likely will be
swapping.

IME, Chrome by itself will happily use more than 8GB.

YMMV,
George

MitchAlsup wrote:
> On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
>> I have a design for a 16-bit mode that looks a lot like the PDP-11. By shrinking
>> the mode bits to only two, as used in the 9900, but keeping only 8 registers, I
>> get an opcode field of six bits. Suddenly, I can include floating-point opcodes.
>>
>> Only thing is, it breaks down if one wants to use more than 64K of memory with
>> it.
> <
> Give a DPD-11 64-bit registers and you will surprised at how good the code density
> is, right up until you have to branch/call/jump farther than ±32KB. But I bet there
> is some kind of "accommodation" to get larger constants that would work fairly well.
> <
> And then there is that "pipelineing" problem.

What do you see as PDP-11's pipelining problem?
The last PDP-11 chipset was I think the J-11, originally circa 1982
for the PDP-11/73 (circa 1983), /83, /84, /93, /94 (circa 1990).

J-11 was originally a 3 chip set, data path chip and control chip
were CMOS and FPU was NMOS.

J-11 apparently had a little pipelining, in that it had a prefetch
buffer and could fetch decode and execute at once.
But execute was still horizontal microcode so limited
potential for doing multiple things at once.

To my eye, the PDP-11 ISA looks like main requirement for
an in-order multi-stage pipeline is to:

(1) separate fetch unit with its own PC (as J-11 did)
(2) must have full back-to-back forwarding
(3) needs a bank of temporary registers to store multiple
memory operands for indirect address modes,
plus a dynamic allocator for above.
(4) for 1-wide pipeline register file needs 2R1W ports
(5) decode emits 1 to 5 uOps per instruction

One could do a nice little 5 or 6 stage pipeline with the above.
The key pieces are the temp registers with dynamic allocator
and the forwarding to deal with intra-instruction uOp dependencies.

On Tuesday, June 8, 2021 at 9:08:42 AM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
> >> I have a design for a 16-bit mode that looks a lot like the PDP-11. By shrinking
> >> the mode bits to only two, as used in the 9900, but keeping only 8 registers, I
> >> get an opcode field of six bits. Suddenly, I can include floating-point opcodes.
> >>
> >> Only thing is, it breaks down if one wants to use more than 64K of memory with
> >> it.
> > <
> > Give a DPD-11 64-bit registers and you will surprised at how good the code density
> > is, right up until you have to branch/call/jump farther than ±32KB.. But I bet there
> > is some kind of "accommodation" to get larger constants that would work fairly well.
> > <
> > And then there is that "pipelineing" problem.
> What do you see as PDP-11's pipelining problem?
<
MOV R6,R3
versus
MOV R6,(R3)
versus
MOV R6,(R3)+
versus
MOV R6,@(r3)
versus
MOV R6,-(R3)
versus
MOV R6,@-(R3)
versus
MOV R6,DISP(R3)
versus
MOV R6,@DISP(R3)
<
Now, granted, the autoincrement/decrement is "not that hard"
but the indirect and double indirect forms are getting hard
to pipeline at one or more instructions per cycle. The pre-
decrement is costly (by a cycle) in getting the address to the
RAM.
<
Given that BOTH R6 and R3 in the above examples have 8-variants
each, there are 256 ways the MOV instruction can specify a single
unit of work.
<
> The last PDP-11 chipset was I think the J-11, originally circa 1982
> for the PDP-11/73 (circa 1983), /83, /84, /93, /94 (circa 1990).
>
> J-11 was originally a 3 chip set, data path chip and control chip
> were CMOS and FPU was NMOS.
>
> J-11 apparently had a little pipelining, in that it had a prefetch
> buffer and could fetch decode and execute at once.
> But execute was still horizontal microcode so limited
> potential for doing multiple things at once.
>
> To my eye, the PDP-11 ISA looks like main requirement for
> an in-order multi-stage pipeline is to:
>
> (1) separate fetch unit with its own PC (as J-11 did)
> (2) must have full back-to-back forwarding
> (3) needs a bank of temporary registers to store multiple
> memory operands for indirect address modes,
> plus a dynamic allocator for above.
> (4) for 1-wide pipeline register file needs 2R1W ports
> (5) decode emits 1 to 5 uOps per instruction
>
> One could do a nice little 5 or 6 stage pipeline with the above.
<
The problem is the indirect and double indirect address forms can require
7 memory refs per instruction.
<
Consider::
MOV @3148(R6),@2464(R3)
<
This requires 3 words for the FETCH side of the pipeline, and 3 Data reads
and 1 Data write to be processed. The first word fetched describes that 2
more words need to be fetched in order to have enough "bits" to execute
the instruction.
<
Yes, you could fetch 4 words per cycle and be able to lob 3 words into
a multi-fire reservation station and have it do all the data references.
But a machine like this would quickly become data bound rather than
calculate bound.
<
A minor complication is that about 40% of memory references don't require
AGEN while 60% do, this is a bit of a scheduling problem at the data port.
<
This is why its only "a little hard" to pipeline, VAX was much worse, so
was 432.
<
> The key pieces are the temp registers with dynamic allocator
> and the forwarding to deal with intra-instruction uOp dependencies.

MitchAlsup wrote:
> On Tuesday, June 8, 2021 at 9:08:42 AM UTC-5, EricP wrote:
>> MitchAlsup wrote:
>>> On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
>>>> I have a design for a 16-bit mode that looks a lot like the PDP-11. By shrinking
>>>> the mode bits to only two, as used in the 9900, but keeping only 8 registers, I
>>>> get an opcode field of six bits. Suddenly, I can include floating-point opcodes.
>>>>
>>>> Only thing is, it breaks down if one wants to use more than 64K of memory with
>>>> it.
>>> <
>>> Give a DPD-11 64-bit registers and you will surprised at how good the code density
>>> is, right up until you have to branch/call/jump farther than ±32KB.. But I bet there
>>> is some kind of "accommodation" to get larger constants that would work fairly well.
>>> <
>>> And then there is that "pipelineing" problem.
>> What do you see as PDP-11's pipelining problem?
> <
> MOV R6,R3

I see this as using mulitple uOps with
back-to-back forwarding where necessary.

1 uOp, R6 <= R3

> versus
> MOV R6,(R3)

1 uOp, R6 <= [R3]

> versus
> MOV R6,(R3)+

either 2 uOps, or 1 uOp if we add an extra reg file write port.
Lets assume R2Rw from now on and each uOp can carry 2 results.

1 uOp, R6 <= [R3]; R3 <= R3+operand_size

> versus
> MOV R6,@(r3)

2 uOps, with a temp register to hold the intermediate
(that is actually a pseudo-register which doesn't need to
exist because we are forwarding to the next uOp).

temp <= [R3]
R6 <= [temp]

> versus
> MOV R6,-(R3)

Similar to as MOV R6,(R3)+, handled by 2R2W ports, 1 uOp with 2 results.

1 uOp, R3,temp <= R3-operand_size; R6 <= [temp]

> versus
> MOV R6,@-(R3)

2 uOps
temp <= [R3-operand_size]
R6 <= [temp]

> versus
> MOV R6,DISP(R3)

1 uOp R6 <= [R3+DISP<<operand_size]

> versus
> MOV R6,@DISP(R3)

2 uOps
temp <= [R3+DISP<<operand_size]
R6 <= [temp]

> <
> Now, granted, the autoincrement/decrement is "not that hard"
> but the indirect and double indirect forms are getting hard
> to pipeline at one or more instructions per cycle. The pre-
> decrement is costly (by a cycle) in getting the address to the
> RAM.
> <

Indirect (register contains address) is just a normal AGEN, MEM.
Double indrect (register contains address of address) is AGEN, MEM, MEM
so 2 uOps with the intermediate just a forwarded temp result.

> Given that BOTH R6 and R3 in the above examples have 8-variants
> each, there are 256 ways the MOV instruction can specify a single
> unit of work.
> <

Two 3-bit address mode fields, 64 pairs, but R7 is the PC
and that can affect behavior and/or legality.

So it is the same as two 4-bit address mode field in sparse combination.

>> The last PDP-11 chipset was I think the J-11, originally circa 1982
>> for the PDP-11/73 (circa 1983), /83, /84, /93, /94 (circa 1990).
>>
>> J-11 was originally a 3 chip set, data path chip and control chip
>> were CMOS and FPU was NMOS.
>>
>> J-11 apparently had a little pipelining, in that it had a prefetch
>> buffer and could fetch decode and execute at once.
>> But execute was still horizontal microcode so limited
>> potential for doing multiple things at once.
>>
>> To my eye, the PDP-11 ISA looks like main requirement for
>> an in-order multi-stage pipeline is to:
>>
>> (1) separate fetch unit with its own PC (as J-11 did)
>> (2) must have full back-to-back forwarding
>> (3) needs a bank of temporary registers to store multiple
>> memory operands for indirect address modes,
>> plus a dynamic allocator for above.
>> (4) for 1-wide pipeline register file needs 2R1W ports
>> (5) decode emits 1 to 5 uOps per instruction
>>
>> One could do a nice little 5 or 6 stage pipeline with the above.
> <
> The problem is the indirect and double indirect address forms can require
> 7 memory refs per instruction.
> <
> Consider::
> MOV @3148(R6),@2464(R3)
> <
> This requires 3 words for the FETCH side of the pipeline, and 3 Data reads
> and 1 Data write to be processed. The first word fetched describes that 2
> more words need to be fetched in order to have enough "bits" to execute
> the instruction.

Lets make it worse and make it an ADD so we have to forward to ALU.

ADD @3148(R6),@2464(R3)

This would require 6 uOps, plus 3 temp registers

temp1 <= [R3+2464]
temp2 <= [temp1] // forwarded from #1
temp1 <= [R6+3148]
temp3 <= [temp1] // forwarded from #3
temp3 <= temp2 + temp3 // forwarded from #4
[temp1] <= temp3 // forwarded from #5

> <
> Yes, you could fetch 4 words per cycle and be able to lob 3 words into
> a multi-fire reservation station and have it do all the data references.
> But a machine like this would quickly become data bound rather than
> calculate bound.

That's fancier than I was thinking.
I was just looking at a minimal pipeline, taking the single stage
microcoded sequencer and breaking out into RR-ALU-MEM-WB stages.

> <
> A minor complication is that about 40% of memory references don't require
> AGEN while 60% do, this is a bit of a scheduling problem at the data port.
> <
> This is why its only "a little hard" to pipeline, VAX was much worse, so
> was 432.
> <
>> The key pieces are the temp registers with dynamic allocator
>> and the forwarding to deal with intra-instruction uOp dependencies.

MitchAlsup wrote:
> On Tuesday, June 8, 2021 at 3:26:10 AM UTC-5, Anton Ertl wrote:
>> MitchAlsup <Mitch...@aol.com> writes:
>>> Well, we blew right though 4GB, and are in spitting distance of not needing to run
>>> the swapper on many/most home computers !
> <
>> We are long past that point. Swapping hundreds of MB to a hard disk
>> and swapping them back in from a hard disk is so slow that it is
>> impractical. With SSDs it may have become practical again, but if we
>> did not need to swap a decade ago, why would we need to swap now?
> <
> Application bloat.
> <
> And I should note: I am running on a machine bought in April of 2012.

My Surface 3 Pro which I read this message on dates back to the fall of
2014/spring 2015. That's actually _very_ impressive for a device which
have been thrown about as much as it has, being stuffed into all sorts
of bags and pulled out anywhere.

My daughter is still using the precursor Surface Pro from 2013, I just
had to order a replacement power adapter from a chinese web site because
Microsoft stopped carrying them years ago.

Terje

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

George Neuner wrote:
> On Tue, 08 Jun 2021 08:22:57 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>> MitchAlsup <MitchAlsup@aol.com> writes:
>>> Well, we blew right though 4GB, and are in spitting distance of not needing to run
>>> the swapper on many/most home computers !
>>
>> We are long past that point. Swapping hundreds of MB to a hard disk
>> and swapping them back in from a hard disk is so slow that it is
>> impractical. With SSDs it may have become practical again, but if we
>> did not need to swap a decade ago, why would we need to swap now?
>>
>> - anton
>
> Well, for one thing, the /average/ home machine still only has 8GB of
> RAM. And since 90% of them are running Windows ... which handles
> memory very differently than Unix/Linux ... unless the user runs only
> a couple of simultaneous applications the machine very likely will be
> swapping.
>
> IME, Chrome by itself will happily use more than 8GB.

Which is one of the reasons I have always insisted on at least twice as
much memory, but accepted a 20-30% slower than bleeding edge cpu.

My 3-4 last work laptops have all had 32 GB RAM and 2+ TB of disk (most
of them in the form of replacement drives I installed myself).

Terje

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

George Neuner <gneuner2@comcast.net> writes:
>On Tue, 08 Jun 2021 08:22:57 GMT, anton@mips.complang.tuwien.ac.at
>(Anton Ertl) wrote:
>
>>MitchAlsup <MitchAlsup@aol.com> writes:
>>>Well, we blew right though 4GB, and are in spitting distance of not needing to run
>>>the swapper on many/most home computers !
>>
>>We are long past that point. Swapping hundreds of MB to a hard disk
>>and swapping them back in from a hard disk is so slow that it is
>>impractical. With SSDs it may have become practical again, but if we
>>did not need to swap a decade ago, why would we need to swap now?
>>
>>- anton
>
>Well, for one thing, the /average/ home machine still only has 8GB of
>RAM. And since 90% of them are running Windows ... which handles
>memory very differently than Unix/Linux ... unless the user runs only
>a couple of simultaneous applications the machine very likely will be
>swapping.

If they have 8GB, they likely also use a hard disk. And swapping
several GB to a hard disk or paging it back in is so slow it is
unusable. Hard disks have typically ~100 IO/s. With 4KB pages, this
can mean paging out as little as 400KB/s. Even if you get 10 times as
much by swapping a range of pages out and in at the same time (to one
extent on the HDD), it means 250s for swapping out 1GB, and another
250s for swapping in the stuff you actually wanted. Unusable. Is it
so much better on Windows?

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

George Neuner <gneuner2@comcast.net> schrieb:
> On Tue, 08 Jun 2021 08:22:57 GMT, anton@mips.complang.tuwien.ac.at
> (Anton Ertl) wrote:
>
>>MitchAlsup <MitchAlsup@aol.com> writes:
>>>Well, we blew right though 4GB, and are in spitting distance of not needing to run
>>>the swapper on many/most home computers !
>>
>>We are long past that point. Swapping hundreds of MB to a hard disk
>>and swapping them back in from a hard disk is so slow that it is
>>impractical. With SSDs it may have become practical again, but if we
>>did not need to swap a decade ago, why would we need to swap now?
>>
>>- anton
>
> Well, for one thing, the /average/ home machine still only has 8GB of
> RAM.

We recently had to switch to Windows 10 at work. Don't ask...

The laptops we got all had 16 GB because even the IT department
had figured out that using 8GB with W10, Teams, Office 365 and
other assorted bloatware would not work.

On Tuesday, June 8, 2021 at 7:04:59 AM UTC-6, MitchAlsup wrote:

> And I should note: I am running on a machine bought in April of 2012.

Until recently, I was using a machine that I bought second-hand for $200,
that was made in 2009. Because it was Xeon based, though, it had niceties
such as two PCIe 16x slots, and triple-channel memory.

Eventually, almost a year after I had finished putting it together, I finally
switched to using my new homebrew Ryzen 9 3900X system as my
daily driver. I still fire up the old system when I need to print or scan something,
as that's where the drivers are installed.

And I will soon have even more use for my old system.

I don't think I could afford to run out and get a new Radeon Pro W6800, and in
any case, since so much software is dependent on CUDA, I wouldn't get full
value for its 1.1 Teraflops of FP64 goodness.

So instead, I'm keeping my somewhat less FP64 beefy (but well endowed with
memory bandwidth) Vega 56 on the newer system... and for the older system,
I've ordered, and have coming my way, a Titan Black. That will be very usable
with Leela Chess Zero at least.

Also on order is a much more economical 1.1 Teraflops of FP64 for that second
PCIe 16x slot. Since it's a Xeon, it should have the Resizable BAR memory goodness
needed to talk to it (which the newest generation of Radeon video cards also uses).

Although I am concerned that the reason it's cheap will be that I will find it very
difficult to actually make any use of it. Support was dropped in version 5.1 of the
Linux kernel, for example...

Yes, it's a 60 core Xeon Phi.

I'm hoping I'll be able to crunch numbers well enough to add some very pretty pictures to
my web site.

John Savard

On Tuesday, June 8, 2021 at 12:14:18 PM UTC-5, EricP wrote:
> MitchAlsup wrote:
> > On Tuesday, June 8, 2021 at 9:08:42 AM UTC-5, EricP wrote:
> >> MitchAlsup wrote:
> >>> On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
> >>>> I have a design for a 16-bit mode that looks a lot like the PDP-11. By shrinking
> >>>> the mode bits to only two, as used in the 9900, but keeping only 8 registers, I
> >>>> get an opcode field of six bits. Suddenly, I can include floating-point opcodes.
> >>>>
> >>>> Only thing is, it breaks down if one wants to use more than 64K of memory with
> >>>> it.
> >>> <
> >>> Give a DPD-11 64-bit registers and you will surprised at how good the code density
> >>> is, right up until you have to branch/call/jump farther than ±32KB.. But I bet there
> >>> is some kind of "accommodation" to get larger constants that would work fairly well.
> >>> <
> >>> And then there is that "pipelineing" problem.
> >> What do you see as PDP-11's pipelining problem?
> > <
> > MOV R6,R3
<
> I see this as using mulitple uOps with
> back-to-back forwarding where necessary.
>
> 1 uOp, R6 <= R3
>
> > versus
> > MOV R6,(R3)
>
> 1 uOp, R6 <= [R3]
<
The thing is that one cannot tell how many things go one by just looking
at the OpCode, one also has to look at the register specifiers.
>
> > versus
> > MOV R6,(R3)+
>
> either 2 uOps, or 1 uOp if we add an extra reg file write port.
> Lets assume R2Rw from now on and each uOp can carry 2 results.
>
> 1 uOp, R6 <= [R3]; R3 <= R3+operand_size
>
> > versus
> > MOV R6,@(r3)
>
> 2 uOps, with a temp register to hold the intermediate
> (that is actually a pseudo-register which doesn't need to
> exist because we are forwarding to the next uOp).
>
> temp <= [R3]
> R6 <= [temp]
>
> > versus
> > MOV R6,-(R3)
>
> Similar to as MOV R6,(R3)+, handled by 2R2W ports, 1 uOp with 2 results.
>
> 1 uOp, R3,temp <= R3-operand_size; R6 <= [temp]
>
> > versus
> > MOV R6,@-(R3)
>
> 2 uOps
> temp <= [R3-operand_size]
> R6 <= [temp]
>
> > versus
> > MOV R6,DISP(R3)
>
> 1 uOp R6 <= [R3+DISP<<operand_size]
>
> > versus
> > MOV R6,@DISP(R3)
>
> 2 uOps
> temp <= [R3+DISP<<operand_size]
> R6 <= [temp]
> > <
> > Now, granted, the autoincrement/decrement is "not that hard"
> > but the indirect and double indirect forms are getting hard
> > to pipeline at one or more instructions per cycle. The pre-
> > decrement is costly (by a cycle) in getting the address to the
> > RAM.
> > <
<
> Indirect (register contains address) is just a normal AGEN, MEM.
<
It could, but both AGENs add 0, so why perform useless work !
<
> Double indrect (register contains address of address) is AGEN, MEM, MEM
> so 2 uOps with the intermediate just a forwarded temp result.
<
> > Given that BOTH R6 and R3 in the above examples have 8-variants
> > each, there are 256 ways the MOV instruction can specify a single
> > unit of work.
> > <
> Two 3-bit address mode fields, 64 pairs, but R7 is the PC
> and that can affect behavior and/or legality.
<
Yep, my math unit blew a fuse on that one.
>
> So it is the same as two 4-bit address mode field in sparse combination.
<
> >> The last PDP-11 chipset was I think the J-11, originally circa 1982
> >> for the PDP-11/73 (circa 1983), /83, /84, /93, /94 (circa 1990).
> >>
> >> J-11 was originally a 3 chip set, data path chip and control chip
> >> were CMOS and FPU was NMOS.
> >>
> >> J-11 apparently had a little pipelining, in that it had a prefetch
> >> buffer and could fetch decode and execute at once.
> >> But execute was still horizontal microcode so limited
> >> potential for doing multiple things at once.
> >>
> >> To my eye, the PDP-11 ISA looks like main requirement for
> >> an in-order multi-stage pipeline is to:
> >>
> >> (1) separate fetch unit with its own PC (as J-11 did)
> >> (2) must have full back-to-back forwarding
> >> (3) needs a bank of temporary registers to store multiple
> >> memory operands for indirect address modes,
> >> plus a dynamic allocator for above.
> >> (4) for 1-wide pipeline register file needs 2R1W ports
> >> (5) decode emits 1 to 5 uOps per instruction
> >>
> >> One could do a nice little 5 or 6 stage pipeline with the above.
> > <
> > The problem is the indirect and double indirect address forms can require
> > 7 memory refs per instruction.
> > <
> > Consider::
> > MOV @3148(R6),@2464(R3)
> > <
> > This requires 3 words for the FETCH side of the pipeline, and 3 Data reads
> > and 1 Data write to be processed. The first word fetched describes that 2
> > more words need to be fetched in order to have enough "bits" to execute
> > the instruction.
<
> Lets make it worse and make it an ADD so we have to forward to ALU.
>
> ADD @3148(R6),@2464(R3)
>
> This would require 6 uOps, plus 3 temp registers
>
> temp1 <= [R3+2464]
> temp2 <= [temp1] // forwarded from #1
> temp1 <= [R6+3148]
> temp3 <= [temp1] // forwarded from #3
> temp3 <= temp2 + temp3 // forwarded from #4
> [temp1] <= temp3 // forwarded from #5
<
Now change + into MUL or DIV and have the subsequent instruction have
a dependency on [temp1]
> > <
> > Yes, you could fetch 4 words per cycle and be able to lob 3 words into
> > a multi-fire reservation station and have it do all the data references..
> > But a machine like this would quickly become data bound rather than
> > calculate bound.
<
> That's fancier than I was thinking.
> I was just looking at a minimal pipeline, taking the single stage
> microcoded sequencer and breaking out into RR-ALU-MEM-WB stages.
<
I was looking at making a real and competitive CPU.
<
In effect, the address modes are mini-instructions embedded in a calculation
instruction.
> > <
> > A minor complication is that about 40% of memory references don't require
> > AGEN while 60% do, this is a bit of a scheduling problem at the data port.
> > <
> > This is why its only "a little hard" to pipeline, VAX was much worse, so
> > was 432.
> > <
> >> The key pieces are the temp registers with dynamic allocator
> >> and the forwarding to deal with intra-instruction uOp dependencies.

On Tuesday, June 8, 2021 at 8:58:30 AM UTC-5, George Neuner wrote:
>
>
> IME, Chrome by itself will happily use more than 8GB.
>
It never ceases to amaze me that I can have four (4) 8GB documents open in WORD
and only use 750KB of memory, yet if I close Chrome with 8 windows open, I go from
70% memory utilization to 30% memory utilization ! on an 8GB machine.

On Tuesday, June 8, 2021 at 8:32:22 AM UTC-6, MitchAlsup wrote:

> MOV R6,R3
> versus
> MOV R6,(R3)
> versus
> MOV R6,(R3)+
> versus

> MOV R6,DISP(R3)

....and not the other modes will be all that I will be including, as I've
trimmed the mode field to only two bits. No decrement, no double
indirect.
So that may help with the pipelining a bit.

John Savard

>>Well, for one thing, the /average/ home machine still only has 8GB of
>>RAM. And since 90% of them are running Windows ... which handles
>>memory very differently than Unix/Linux ... unless the user runs only
>>a couple of simultaneous applications the machine very likely will be
>>swapping.
> If they have 8GB, they likely also use a hard disk.

As one data point, the base Macbooks still sell with 8GB of RAM right
now, even though Macbooks have been using exclusively SSDs for many
years now.

So, I'm not sure what's the proportion of 8GB machines that comes with
an SSD vs HDD (i.e. for machines currently in use, rather than for
machines currently selling), but SSDs might already be more common now,
at least in laptops.

Stefan

On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
> On Monday, June 7, 2021 at 3:06:29 PM UTC-6, MitchAlsup wrote:
>
> > You should only consider 64-bit machines as the PDP-8 is at a serious
> > deficit when you consider loading a value into a register requires clearing
> > the registers and then adding memory to it: 2-instructions, 12×12 multiply
> > is 24 instructions,......indexing memory LD/ST: 3 instructions......
> That is, indeed, such a no-brainer that I had not failed to see that point.
>
> So while the instructions might _look_ like PDP-8 instructions, they would still
> perform 64-bit operations. However, it's still unworkable for many other reasons.
> > I think PDP-11 had better code density.
> I have a design for a 16-bit mode that looks a lot like the PDP-11. By shrinking
> the mode bits to only two, as used in the 9900, but keeping only 8 registers, I
> get an opcode field of six bits. Suddenly, I can include floating-point opcodes.
>
> Only thing is, it breaks down if one wants to use more than 64K of memory with
> it.
>
> John Savard

|> > I think PDP-11 had better code density.

More address space for a PDP11 like ISA:
Use the floating-point instructions instead as an escape to a 24-bit instruction (which allows four data sizes),
Dump the @(--R) and @(R+disp) addressing modes allowing 10 registers + PC addressing modes,
Lengthen the registers to suit your memory size taste,
Use variable length immediates and displacements (increased decoding complexity, less memory waste)

Similar trick possible with MSP430.

On Tuesday, June 8, 2021 at 7:18:31 PM UTC-5, JimBrakefield wrote:
> On Monday, June 7, 2021 at 4:11:45 PM UTC-5, Quadibloc wrote:
> > On Monday, June 7, 2021 at 3:06:29 PM UTC-6, MitchAlsup wrote:
<snip>
> |> > I think PDP-11 had better code density.
> More address space for a PDP11 like ISA:
> Use the floating-point instructions instead as an escape to a 24-bit instruction (which allows four data sizes),
> Dump the @(--R) and @(R+disp) addressing modes allowing 10 registers + PC addressing modes,
> Lengthen the registers to suit your memory size taste,
> Use variable length immediates and displacements (increased decoding complexity, less memory waste)
>
> Similar trick possible with MSP430.
<
I have been thinking about a 64-bit PDP-11 all after noon, and I think it could work
out rather well.
<
The example I gave earlier, were the DECODER would drop the 3 halfword
ADD @disp(R6),@disp2(R3) into a multifire reservation station in one cycle,
then the (now) 5 memory refs would transpire as resources permitted. And
if we were dropping 1 instruction per cycle and had a big enough execution
window, it should perform rather well and have great code density.
<
PDP-11 has the double indirect addressing modes because it does not have
enough registers, and in effect, is using memory as registers. Using 8 real
registers to orchestrate a myriad of memory based registers.
<
Nor does the (R5)+ or the -(R3) bother the multifire reservation station model,
sooner or later there will be a register write cycle on a result bus, and until
that register is delivered there is high probability that other instructions will
be waiting (which alleviates porting problems at the register file.)
<
With only 8 real registers one can build as many ports as one wants !
With a myriad of memory based registers (which cache nicely BTW) the compiler
has a high density encoding to describe the semantic of the code.
<
So, you can get the 3-5 instructions per cycle into execution with a 1-wide
decoder, and wider than people are building if you try for more than 1 PDP-11
instruction per cycle.
<
All well and good. But what instructions would make the cut ?
<
You have two (2) 6-bit register and address mode specifiers in a 16-bit
instruction, so you only get 4-bits of OpCode; 16 instructions which seems
paltry. So I was thinking about using the instruction-modifier approach
to cast more bits onto subsequent instructions. If one Major OpCode
(4-bits) is used to cast 3-bits onto 4 successive instructions, 4-bits to 3,
6-bits to 2,... all of a sudden you have enough instructions or some cross
product of calculation type {int, FP} width {BHWD} and instruction space
widening.
<
All with an orthogonal ISA, high code density.
<
Now to get rid of condition codes,................

On Sunday, June 6, 2021 at 11:35:38 PM UTC-6, Ivan Godard wrote:
> On 6/6/2021 6:51 PM, Quadibloc wrote:

> > Also, most of the time, the VLIW as designed will indeed be useless. Real-world
> > code hardly _ever_ has an ILP of 8.

> True in open code, false in pipelined loops.

Although I actually did make note of that, I have been doing some more
thinking. I first came up with a PDP-11-like alternate instruction set when
it was noted that PDP-11 code was compact. But it was so PDP-11-like
that it would not have worked well at all with any pipelined implementation.

I eventually modified it so that it was less similar to a PDP-11, but fitted
tolerably well with a pipeline - about as well as any ordinary RISC
instruction set, and yet most of the instructions are 16 bits. But not all;
for that, there is also a set of instructions similar to ARM's Thumb Mode.

But that exercise reminded me of how important speed and efficiency
were, in order to make the Concertina II architecture of any interest.

The Itanium had banks of 128 registers, so it "could" be done.

Thus, I've brought that feature back. However, the normal instructions
that use these extended register banks work only with registers drawn
from either one of sixteen groups of eight registers, or from one of
four groups of thirty-two registers.

The idea behind that, in addition to keeping the instructions involved from
using too much opcode space, is to allow the group of registers to be used
to be preselected after the instruction is decoded so that the large banks
of registers won't add to the execution-stage latency of the instructions
that use them - to address a criticism from Mitch Alsup of the notion of
having such a large bank of registers.

With all those registers, it will be easier to have instructions interleaved doing
independent calculations for ease of pipelining without stalls even in the
absence of register rename... assuming, of course, one is solving a problem
that admits of an algorithm which can actually be usefully doing so many
different things in a single thread. I have strong doubts that it can often be
done, but, yes, in a finely-crafted inner loop, it just might pay huge dividends
on some occasions.

John Savard

On Thursday, June 10, 2021 at 10:17:57 PM UTC-6, Quadibloc wrote:

> But that exercise reminded me of how important speed and efficiency
> were, in order to make the Concertina II architecture of any interest.
>
> The Itanium had banks of 128 registers, so it "could" be done.
>
> Thus, I've brought that feature back. However, the normal instructions
> that use these extended register banks work only with registers drawn
> from either one of sixteen groups of eight registers, or from one of
> four groups of thirty-two registers.

While there was room in the opcode space for restricted operate
instructions involving banks of 128 registers, the situation was more
difficult for memory-reference instructions.

The basic instruction set did not have room for any such instructions
for these register banks at all.

The extended instruction set could just barely fit them in; they had to
be restricted to the short-displacement addressing modes, and indexing
could not be allowed, in addition to restricting them to aligned operands.

However, in my header formats, I had already defined a set of header formats
for instructions which had two prefix bits in the header, as in extended mode,
but with only seven (or six) of them instead of fourteen (or twelve). Also
extended, but no longer with variable lengths, so there was room to extend
the set of 32-bit (or really 34-bit) instructions even more.

So an instruction set for those header formats has now been defined, and space
in it is used to provide load and store instructions for aligned operands using the
banks of 128 registers. While there are those two restrictions on memory reference
for those instructions, the other painful restrictions are gone; indexing is available,
and long displacements may be used.

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

John Savard