Captain Obvious just passed and told me about the comp.arch law:

As a comp.arch discussion grows longer, the probability of it
becoming a discussion of My 66000 or the Mill approaches one.

On Thursday, February 17, 2022 at 12:33:44 PM UTC-6, Thomas Koenig wrote:
> Captain Obvious just passed and told me about the comp.arch law:
>
> As a comp.arch discussion grows longer, the probability of it
> becoming a discussion of My 66000 or the Mill approaches one.
<
Astute observation.

Thomas Koenig wrote:
> Captain Obvious just passed and told me about the comp.arch law:
>
> As a comp.arch discussion grows longer, the probability of it
> becoming a discussion of My 66000 or the Mill approaches one.
>
This is a _huge_ improvement vs the original nazi/hitler version! :-)

Terje

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

On 2/17/2022 10:33 AM, Thomas Koenig wrote:
> Captain Obvious just passed and told me about the comp.arch law:
>
> As a comp.arch discussion grows longer, the probability of it
> becoming a discussion of My 66000 or the Mill approaches one.

That's because My 66 and Mill are the limit cases, of dynamic and static
scheduled designs respectively.

However, contravening the law, there is a lot of worthwhile discussion
about designs that have constraints, such a FPGA size/cost, that keep
them short of the limit.

On Thursday, February 17, 2022 at 4:52:27 PM UTC-6, Ivan Godard wrote:
> On 2/17/2022 10:33 AM, Thomas Koenig wrote:
> > Captain Obvious just passed and told me about the comp.arch law:
> >
> > As a comp.arch discussion grows longer, the probability of it
> > becoming a discussion of My 66000 or the Mill approaches one.
> That's because My 66 and Mill are the limit cases, of dynamic and static
> scheduled designs respectively.
<
Plus they are pretty devoid of instances where the instruction set was
poorly chosen. {Something RISC-V, ARM, x86 cannot really claim....}
>
> However, contravening the law, there is a lot of worthwhile discussion
> about designs that have constraints, such a FPGA size/cost, that keep
> them short of the limit.

On Friday, February 18, 2022 at 3:55:16 AM UTC+2, MitchAlsup wrote:
> On Thursday, February 17, 2022 at 4:52:27 PM UTC-6, Ivan Godard wrote:
> > On 2/17/2022 10:33 AM, Thomas Koenig wrote:
> > > Captain Obvious just passed and told me about the comp.arch law:
> > >
> > > As a comp.arch discussion grows longer, the probability of it
> > > becoming a discussion of My 66000 or the Mill approaches one.
> > That's because My 66 and Mill are the limit cases, of dynamic and static
> > scheduled designs respectively.
> <
> Plus they are pretty devoid of instances where the instruction set was
> poorly chosen. {Something RISC-V, ARM, x86 cannot really claim....}
> >
> > However, contravening the law, there is a lot of worthwhile discussion
> > about designs that have constraints, such a FPGA size/cost, that keep
> > them short of the limit.

And they are paper which is long known to be much better material for CPUs than silicon.

On Thursday, February 17, 2022 at 10:33:44 AM UTC-8, Thomas Koenig wrote:
> Captain Obvious just passed and told me about the comp.arch law:
>
> As a comp.arch discussion grows longer, the probability of it
> becoming a discussion of My 66000 or the Mill approaches one.
Though no thread is really complete until the C nasal demons have emerged, quickly followed by their compiler-writer defenders.

JohnG <gomijacogeo@gmail.com> wrote:
> On Thursday, February 17, 2022 at 10:33:44 AM UTC-8, Thomas Koenig wrote:
>> Captain Obvious just passed and told me about the comp.arch law:
>>
>> As a comp.arch discussion grows longer, the probability of it
>> becoming a discussion of My 66000 or the Mill approaches one.
> Though no thread is really complete until the C nasal demons have
> emerged, quickly followed by their compiler-writer defenders.

Followed by me telling the C++ children to upgrade to a real language like
Swift.
;)

On Saturday, February 19, 2022 at 9:20:45 PM UTC-6, gg...@yahoo.com wrote:
> JohnG <gomij...@gmail.com> wrote:
> > On Thursday, February 17, 2022 at 10:33:44 AM UTC-8, Thomas Koenig wrote:
> >> Captain Obvious just passed and told me about the comp.arch law:
> >>
> >> As a comp.arch discussion grows longer, the probability of it
> >> becoming a discussion of My 66000 or the Mill approaches one.
> > Though no thread is really complete until the C nasal demons have
> > emerged, quickly followed by their compiler-writer defenders.
> Followed by me telling the C++ children to upgrade to a real language like
> Swift.
> ;)
<
Boos from the audience........

JohnG <gomijacogeo@gmail.com> schrieb:
> On Thursday, February 17, 2022 at 10:33:44 AM UTC-8, Thomas Koenig wrote:
>> Captain Obvious just passed and told me about the comp.arch law:
>>
>> As a comp.arch discussion grows longer, the probability of it
>> becoming a discussion of My 66000 or the Mill approaches one.

> Though no thread is really complete until the C nasal demons
> have emerged, quickly followed by their compiler-writer defenders.

I cannot confirm that. While this has been a recurring theme,
there have been a great many threads without even referencing
this subject.

On Thursday, February 17, 2022 at 3:52:27 PM UTC-7, Ivan Godard wrote:

> That's because My 66 and Mill are the limit cases, of dynamic and static
> scheduled designs respectively.

And from this we can also conclude that, in comparison to those designs,
RISC-V and ARM - not to mention x86 - are hardly worth discussing.

John Savard

On 2/20/2022 3:54 AM, Quadibloc wrote:
> On Thursday, February 17, 2022 at 3:52:27 PM UTC-7, Ivan Godard wrote:
>
>> That's because My 66 and Mill are the limit cases, of dynamic and static
>> scheduled designs respectively.
>
> And from this we can also conclude that, in comparison to those designs,
> RISC-V and ARM - not to mention x86 - are hardly worth discussing.
>
> John Savard

Depends on whether you are interested in what could be done clean-sheet,
or in what was done, why it shouldn't have been, and what can be done to
work around it. Both are fit topics.

Quadibloc <jsavard@ecn.ab.ca> schrieb:
> On Thursday, February 17, 2022 at 3:52:27 PM UTC-7, Ivan Godard wrote:
>
>> That's because My 66 and Mill are the limit cases, of dynamic and static
>> scheduled designs respectively.
>
> And from this we can also conclude that, in comparison to those designs,
> RISC-V and ARM - not to mention x86 - are hardly worth discussing.

Regarding ARM, with their 9000-page handbook, a quote from Bismarck
(or Palmerston?) comes to mind.

He quipped that there only had been three people to understand the
Schleswig-Holstein question. One went mad, the second one died.
He himself was the third one, and he had forgotten.

On 2/20/2022 4:06 AM, Ivan Godard wrote:
> On 2/20/2022 3:54 AM, Quadibloc wrote:
>> On Thursday, February 17, 2022 at 3:52:27 PM UTC-7, Ivan Godard wrote:
>>
>>> That's because My 66 and Mill are the limit cases, of dynamic and static
>>> scheduled designs respectively.
>>
>> And from this we can also conclude that, in comparison to those designs,
>> RISC-V and ARM - not to mention x86 - are hardly worth discussing.
>>
>> John Savard
>
> Depends on whether you are interested in what could be done clean-sheet,
> or in what was done, why it shouldn't have been, and what can be done to
> work around it. Both are fit topics.

Absolutely. Both were excellent solutions to the problems of the time
they were designed. Later, as we learned more, and the technology
progressed, we saw their shortcomings. It is important to look at those
to try to see what, in say 30 years and assuming they last that long,
might be the shortcomings of today's new designs, so we can try to avoid
them.

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

On 2/19/2022 11:37 PM, Thomas Koenig wrote:
> JohnG <gomijacogeo@gmail.com> schrieb:
>> On Thursday, February 17, 2022 at 10:33:44 AM UTC-8, Thomas Koenig wrote:
>>> Captain Obvious just passed and told me about the comp.arch law:
>>>
>>> As a comp.arch discussion grows longer, the probability of it
>>> becoming a discussion of My 66000 or the Mill approaches one.
>
>> Though no thread is really complete until the C nasal demons
>> have emerged, quickly followed by their compiler-writer defenders.
>
> I cannot confirm that. While this has been a recurring theme,
> there have been a great many threads without even referencing
> this subject.

But, of course, this thread just provided evidence for the proposition. :-)

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

MitchAlsup wrote:
> On Saturday, February 19, 2022 at 9:20:45 PM UTC-6, gg...@yahoo.com wrote:
>> JohnG <gomij...@gmail.com> wrote:
>>> On Thursday, February 17, 2022 at 10:33:44 AM UTC-8, Thomas Koenig wrote:
>>>> Captain Obvious just passed and told me about the comp.arch law:
>>>>
>>>> As a comp.arch discussion grows longer, the probability of it
>>>> becoming a discussion of My 66000 or the Mill approaches one.
>>> Though no thread is really complete until the C nasal demons have
>>> emerged, quickly followed by their compiler-writer defenders.
>> Followed by me telling the C++ children to upgrade to a real language like
>> Swift.
>> ;)
> <
> Boos from the audience........
>
Accompanied with cries of "Use Rust instead!"

Terje

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

On Sunday, February 20, 2022 at 5:54:12 AM UTC-6, Quadibloc wrote:
> On Thursday, February 17, 2022 at 3:52:27 PM UTC-7, Ivan Godard wrote:
>
> > That's because My 66 and Mill are the limit cases, of dynamic and static
> > scheduled designs respectively.
> And from this we can also conclude that, in comparison to those designs,
> RISC-V and ARM - not to mention x86 - are hardly worth discussing.
>
> John Savard
<
I think the contrapositive is de rigueur.
<
Mill and My 66000 can point to x86-64, ARM to discuss why we did not
do things those ways.
<
Conversely, we get performance data (like context switch latency) and
point out how Mill or My 66000 can change a 1,000-to-10,000 cycle
thing into a 10-cycle thing.

On 2/20/2022 6:06 AM, Ivan Godard wrote:
> On 2/20/2022 3:54 AM, Quadibloc wrote:
>> On Thursday, February 17, 2022 at 3:52:27 PM UTC-7, Ivan Godard wrote:
>>
>>> That's because My 66 and Mill are the limit cases, of dynamic and static
>>> scheduled designs respectively.
>>
>> And from this we can also conclude that, in comparison to those designs,
>> RISC-V and ARM - not to mention x86 - are hardly worth discussing.
>>
>> John Savard
>
> Depends on whether you are interested in what could be done clean-sheet,
> or in what was done, why it shouldn't have been, and what can be done to
> work around it. Both are fit topics.

In some other circles, people obsess on RISC-V with nearly cult-like
dedication, it is kinda weird.

ARM A32 and A64 are kinda meh.
A32 is kinda needlessly fancy in some areas, but its small register
space kinda sucks.
A64 makes more sense, but its use of ALU status flags and condition
codes isn't ideal (*).

*: While some of the issues could arguably also apply to a T-bit flag,
some were avoided by making T flag only able to be updated from lane 1.

Main alternatives require either using combined Compare-Op instructions,
Predication via Compare-Op prefixes, ... Or passing status in a register.

Most one can gather from x86 is that decoding it is a pain, and Reg/Mem
sucks...

Likely x86 decoding would require an 8-bit lookup for each byte in an
instruction fetch to find the length, with flags, say:
IsPfx: Instruction Follows
IsOpRm: If an instruction opcode has an Mod/Reg/Rm Byte
IsOpIb: Instruction has an Imm Byte
IsOpIw: Instruction has an Imm Word/DWord
S0..S2: Size, how many bytes follow if parsed as a Mod/RM

Could probably handle the basic x86 and x86-64 ISAs, but this scheme
would fail on AVX and similar.

Could look, it may be possible to split it into two smaller lookups per
byte (one for Prefix/Op, and another for Mod/Rm). Restricting these
lookups to positions which may validly contain these bytes (say, assume
a limit of 4 prefix bytes, then there are 5 spots which may contain an
opcode, and 5 which may contain an Mod/RM).

Then do some pattern-matching or lookups on the result of these bytes.

Result of a fetch could potentially normalize the layout.
Prefix Flags (8b)
Opcode Byte (8b)
Mod/RM Byte (8b)
SIB Byte (8b)
Disp (32b)
Immed (32b)
With some x86-64 encodings (eg: "MOV RAX, Imm64") using both Disp and
Imm as a combined value.

Quickly thinks about it, will probably ignore superscalar for now.
This part would likely need to be done during instruction fetch as there
is otherwise no way to advance EIP/RIP.

....

Compared with other variable-length ISAs:
6502: Instruction formats and lengths are more limited than x86;
M68K: Encoding is more consistent.
PDP-11, MSP430, ... Likewise (similar scheme).
Category: 16-bit op, followed by 0 or more 16-bit fields.
Thumb2, RVC, BJX2, ...
16/32 base, Opcode bits encode length.
Bundle encoding in BJX2 adds some (manageable) complexity here.

Some combination of the M68K and Thumb2 approach could be possible, but
not really an obvious way to pull it off effectively.

Say:
16/32 base op, 0..3 16-bit words of immediate/displacement.

While there would not be much issue for a 1-wide implementation, the use
of variable imm/disp words would be a significant hassle for wide-issue
decoding (it is either this, disallow external imm/disp in bundles, or
use the same encoding for both and make these cases mutually exclusive).

Though more awkward, this latter option is effectively how
Jumbo-encodings work are in BJX2 (typically, you either have a Bundle or
a Jumbo-Op).

The first case which deviates from this being the newer "Op40x2"
encoding (This effectively being the first Jumbo+Bundle Encoding).
Though, this format is still relatively limited in terms of immediate
values. One drawback is I didn't have any spare bits to make the
encoding less ambiguous.

Say, if I had some good way to reliably disambiguate:
"(Op64+Op) | Op" from "Op40+Op | Op40+Op"

Actually, thinking about it, I could reuse some otherwise
redundant/invalid encodings:
70, Redundant with F0
78, Redundant with F4 (Repurpose as Op40x2 prefix)
90, Redundant with F2
98, Redundant with F6 (Reserve as Jumbo)
91, Redundant with F1
99, Redundant with F5 (Reserve as Jumbo)

Where, say, redundant encodings are invalid and reserved for future
expansion.

And, then move Op40x2 from, say:
FFzz_zzzz-F4zz_zzzz_F0zz_zzzz (Ambiguous)
To:
78zz_zzzz-F4zz_zzzz_F0zz_zzzz (Repurposed Encoding).

With the current 'FF' encoding then reverting back to:
"(Op64+Op) | Op"

May go do this, seems slightly less likely to come back to bite me...

....