According to MitchAlsup <mitchalsup@aol.com>:
>> That would mean that "RISC" has an original definition; what is it?
>
>See the classic "Case for the Reduced Instruction Set Computer"
>Katevinis.

Do you mean this paper by Patterson and Ditzel or something else?

https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf

Also compare this paper on the 801 which starts in a very different
place but ends up with many of the same conclusions.

https://dl.acm.org/doi/pdf/10.1145/800050.801824

--
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 12/9/2023 6:35 AM, Quadibloc wrote:
> On Sat, 09 Dec 2023 08:33:14 +0000, Anton Ertl wrote:
>
>> That would mean that "RISC" has an original definition; what is it?
>
> It certainly does make sense to say that the _description_ of
> characteristics of existing RISC implementations in the Patterson
> and Ditzel paper which you cited doesn't constitute an _original_
> definition of RISC.
>
> However, Patterson also wrote a popular article about one of the
> early RISC processors with which he was connected for _Scientific
> American_, and he mentioned most or all of those characteristics
> there, including not having hardware floating-point, because it
> took more than one cycle to execute, and, although my memory may
> be wrong, it seems to me that in that article he did make the leap
> to treating that as a definition rather than just an observation.
>
> Whether or not that is true, it is indeed something like the list
> from Patterson and Ditzel that is being taken as the "definition"
> of RISC by those who say that what passes for RISC these days is
> such as to deprive the term of meaning.
>
> Obviously, not having hardware floating-point for the sake of
> RISC purism is such a stupid idea that basically no one does that
> any more. Since, however, there are still many current designs
> that incorporate most of the _other_ characteristics of RISC, it
> would be inappropriate to draw the conclusion from this that RISC
> is now a dead and obsolete concept.
>
> On the other hand, a lot of RISC architectures - all the instructions
> are 32 bits long, the register banks have at least 32 registers in
> them, the architecture is load-store - currently have OoO
> implementations. Like having hardware floating-point, this is done
> to get the best possible speed given the much larger number of transistors
> we can put on a die this day.
>
> Unlike allowing hardware floating-point, though, I think this
> change strikes directly at the _raison d'être_ of RISC itself.
>
> If RISC exists because it's designed around making pipelining
> fast and efficient, once you've got an OoO implementation, of
> what benefit is RISC? Maybe the OoO circuitry doesn't have to
> work so hard, or OoO plus 32 registers can delay register
> hazards even longer than OoO plus 8 registers. I don't find this
> so implausible as to dismiss RISC as being now nothing more than
> a marketing gimmick.
>
> Of course, there's CISC-that's-almost-as-good-as-RISC (IBM's
> z/Architecture, ColdFire, maybe even Mitch's MY 66000) and
> there's CISC than which _anything_ else would be better
> (such as the world's most popular ISA, devised by a company
> that made MOS memories, and then branched out into making
> some of the world's first single-chip microprocessors)...
>
> Given that situation, where "good CISC" is relatively
> minor in its market presence compared to bad, bad, very
> bad CISC, some architecture designers have chosen to
> incorporate as much of Patterson's original description,
> if not definition, of RISC into their designs as is
> practical in order to distance themselves more convincingly
> from x86 and x86-64.
>
> In designing Concertina II, which might well be described
> as a half-breed architecture from Hell that hasn't made
> up its mind whether to be RISC, CISC, or VLIW, even I have
> been affected by that concern.
>

Yeah...

Your stuff tends to come off as horridly over complicated, and not
particularly RISC-like either.

As for some things in my effort:
Registers: 32 or 64; 64 in most "non small" configurations.
Instruction lengths (bits):
16 (baseline), 32, 64, 96
VLE 64/96 uses the same mechanism as instruction bundles.
The 'XG2 Mode' reclaims the bits used to encode 16-bit ops,
mostly to make all of the register fields 6-bit;
Also to extend the immediate fields for some ops.
Load/Store
Except if LDOP is enabled/used, which adds Load-Op and Op-Store.
But only for a limited range of ALU ops:
ADD/SUB/AND/OR/XOR/XCHG.
All of the LDOP ops currently only have 64-bit encodings.
Only exists if the RV64 mode 'A' extension also exists.
Both are implemented on top of the same mechanism.
I have doubts as to whether it is a good idea...
Also LDOP is not yet supported by my compiler.
Pipelined for most ops.
At present, most ops have a 2 or 3 cycle latency.
LIW
Compiler can indicate 2 or 3 instructions to execute in parallel.
Only certain types of ops are allowed to operate in parallel.
In theory, traditional superscalar could be added at some point.
FPU exists in GPR space.
Integer ops, FPU, and SIMD all exist within the same registers.
Addressing modes:
(RegBase, ImmDisp), (RegBase, RegIndex)
Disp and Index nominally scaled by the element size
1/2/4/8 bytes; the 128-bit case still uses scale of 8.
PC and GBR can be encoded by using R0 and R1 as base registers.
RiDisp extension adds:
(RegBase, RegIndex*ISc, Imm2Disp*1)
Currently only as 64-bit encodings.
Debatable as, at best, the cases where this is useful are rare.

Current number of defined instruction encodings:
~ 700
Currently number of mnemonics:
~ 437

Though, a fair number of both of these were eaten by SIMD and
type-converter ops.

Things like RGB555 or small-vector format converters are infrequently
used, but matter a fair bit for performance in the cases where they come up.

Much past around the 140 mnemonics, SIMD and converter ops dominate for
a while, then intermixed with some newer ISA features, and stuff carried
over from RISC-V.

Say, block of the last 34 (most recent) mnemonics:
SIMD: 8
Twiddle/Convert: 6
Feature: 9 (experimental ops for working with 48-bit data, *)
RISC-V: 11

*: Load/Store ops for 48-bit values in memory, some operations to help
with natively 48-bit integer data (and pointers). These were still
considered an experiment. The 48-bit integer ops had an unexpectedly
large impact on LUT cost and timing (cheaper option being to use 48-bit
sign/zero extension with 64-bit ALU ops as before; though, this case is
one potential drawback of using things like pointer type-tagging and
similar, since for operations like pointer difference or pointer
compare, one doesn't want the results polluted by the high-order
type-tag bits and similar).

There are some operations to assist with type-tag checking and
manipulation, but for the most part the ISA remains unaware with the
contents of the type-tags (though a tagging scheme is defined as part of
the ABI, and some instructions assume the use of this tagging scheme).

Note that, say, trying to bake support for dynamic typed operations into
an ISA would add way too much complexity (and then one would need
fallback handling for those cases not handled directly by the hardware,
etc).

Or, something like an emulation trap when one does a "Variant ADD" and
the value is something other than a fixnum or flonum, would suck for
performance (or, at least, worse than using a run-time call with
hot-paths for the fixnum and flonum cases). Though, in relevant
languages, it is possible to eliminate a lot of these runtime calls
through the use of type-inference, and then one mostly needs to optimize
for cases where the type is known.

Though, this may lead to wonk in some cases, say, if one assumes:
fixnum+fixnum => fixnum
And then hits cases where it overflows the range allowed for a fixnum
(here, the usual assumption is that it would promote to a bignum or
similar, ...).

But, yeah, if there is one thing that RISC would probably reject, baking
dynamic typed operations into hardware would probably be one of them...

Well, along with the possible funkiness of a person doing kernel-mode
programming in a language along the lines of JavaScript (and/or Python).

Had done some small scale experiments, and even with the current
limitations (and dynamically typed code being essentially a pure stream
of runtime calls), dynamic typing performance was "surprisingly
non-horrible" (or, as non-horrible as one can expect from code that is
entirely runtime calls with the occasional register MOV or similar).

Though, OTOH, there are still reasons I am mostly using C on this.

OTOH, did also (very recently) get a nice speedup by noticing that my
compiler was failing to optimize "memcpy(dst, src, const);" into an
inline instruction sequence in most cases that "actually mattered" (so,
was losing a chunk of performance by it "actually calling memcpy()" in
cases where it shouldn't have been; and there was a non-zero amount of
code using memcpy to copy small values and similar).

....

> John Savard

On Sat, 9 Dec 2023 19:41:47 -0000 (UTC), John Levine wrote:

> According to MitchAlsup <mitchalsup@aol.com>:
>>> That would mean that "RISC" has an original definition; what is it?
>>
>>See the classic "Case for the Reduced Instruction Set Computer"
>>Katevinis.
>
> Do you mean this paper by Patterson and Ditzel or something else?

Mitch may also be thinking of Manolis Katevenis' thesis:

<http://users.ics.forth.gr/~kateveni/cv/katevenis_cv_full_v21.html#B1>

On 12/9/23 12:27 PM, Anton Ertl wrote:
[snip]
> The ARM A64 seem to have had no qualms at introducing features like
> load-pair and store-pair that raise eyebrows among purists,

Quick note: that seems to fall out more-or-less for free when
supporting fast unaligned full-register-size ("word") load/store.
I.e., if you "need" the hardware to load two adjacent "words", one
can implement a double-width load that guarantees alignment with
little change to the load/store design. There is the complication
of doubling the number of source/destination registers for
stores/loads.

> so if they
> thought they would gain enough by deviating from A64 being a
> load-store architecture, or from sticking to fixed-width instructions,
> or from it having 32 registers, they would have gone there.

I think the AArch64 design was somewhat low-risk — which makes
sense for a commercial design intended as a long-term stable
interface with significant time-to-market pressure.

(By the way, I think AArch64 has 31 GPRs plus zero/SP and 32
FP/SIMD registers and the PC.)

> Apparently they did not think so, and the IPC and performance per Watt
> of Firestorm indicates that they have designed well.

While the perfect is the enemy of the good (e.g., timeliness of
result is important), emphasis on timeliness and low-risk tends to
produce a worse result than if a statistician made the decision
(especially if externalities are included — what is profitable for
a company can be bad for humanity).

> The surviving RISC properties are no longer as important as they were
> in the late 1980s, but they still result in fewer problems for the
> microarchitects to solve, and all of what goes with lower complexity.

Getting the complexity right seems one of the challenges and one
area where broad experience/knowledge is particularly helpful.
Experience strengthens intuition and knowledge facilitates
determining when complexity can be managed more easily (and when
limited constraints can greatly reduce the effective complexity).

[Captain Obvious, at your service.☺]

On 12/8/2023 8:58 PM, Paul A. Clayton wrote:
> On 12/2/23 3:39 PM, MitchAlsup wrote:
>> Paul A. Clayton wrote:
> [snip]
>>> (Itanium showed that mediocre hardware translation between x86 and
>>> a rather incompatible architecture (and microarchitecture) would
>>> have been problematic even if native Itanium code had competitive
>>
>> So did Transmeta.
>
> Transmeta did not use hardware translation and actually attempted
> to have decent performance. (I think originally Transmeta was
> seeking high performance at lower area before switching to lower
> power as a goal.) For Itanium, binary translation provided better
> performance on the same hardware, so it was more evident that the
> compatibility had a mediocre performance target.
>

As I understand it, Transmeta was effectively a full-system
software/firmware based emulator running on top of a custom VLIW design
(where effectively the code running in x86 land couldn't see "the man
behind the curtain").

IIRC, Itanium was a bit different, apparently trying at first to provide
hardware level backwards compatibility with x86, but it sucked so bad
that people went over to emulation instead.

John Levine wrote:

> According to MitchAlsup <mitchalsup@aol.com>:
>>> That would mean that "RISC" has an original definition; what is it?
>>
>>See the classic "Case for the Reduced Instruction Set Computer"
>>Katevinis.

> Do you mean this paper by Patterson and Ditzel or something else?

I actually means "Reduced Instruction Set Computers for VLSI" K.

> https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf

My memory ain't what it used to be........

Several quotes from the Ditzel paper::

By a judicious choice of the proper instruction set and the design of a corresponding
architecture, we feel that it should be possible to have a very simple instruction set
that can be very fast. This may lead to a substantial net gain in overall program
execution speed. This is the concept of the Reduced Instruction Set Computer.

Johnson used an iterative technique of proposing a machine, writing a compiler, measuring
the results to propose a better machine, and then repeating the cycle over a dozen times.
Though the initial intent was not specifically to come up with a simple design, the result
was a RISC-like 32-bit architecture whose code density was as compact as the PDP-11 and
VAX [Johnson79].

The paper also makes the case against instructions that are seldom used two ways:
First it makes an argument against microcoded implementations using microcode as
a gas and filling up every SQ nanoAcre with seldom functionality, then pointing
out that if a simple sequence of instructions is faster than the equivalent µCode
instruction, choosing µCode was a poor choice of the architect.

In my case (My 66000)::
I see enough use of indexed addressing that this feature makes the cut
I see enough use of LD Reg,[GOT[k]] that big displacements make the cut
I see enough use of LD IP, [GOT[k]] that simplifies cross module calling to make the cut
I see immediates being used all sorts of places so immediates make the cut
I see large displacements being used all sorts of places so displacements make the cut
I see a few uses of the operand sign control but this reduces the name space the programmer
......needs to understand
I see enough VEC-LOOP pairs that these make the cut
Practically every non-leaf subroutine uses ENTER and EXIT
......But note I must remain vigilant that these don't end up slower than a series of insts
The compiler happily produces transcendental instructions for those names which are in the
......LLVM intrinsic function list. When you can calculate practically any transcendental
......in fewer than 20 cycles (FDIV equivalent) it is time to do with these what happened
......to FP instructions around the time of the first commercial RISCs.

Although not done yet:: I am not adverse to adding encryption instructions {once I can
figure out what they should actually be doing and how few I can get away with}

> Also compare this paper on the 801 which starts in a very different
> place but ends up with many of the same conclusions.

> https://dl.acm.org/doi/pdf/10.1145/800050.801824

BGB wrote:

> On 12/9/2023 6:35 AM, Quadibloc wrote:
>>
>> In designing Concertina II, which might well be described
>> as a half-breed architecture from Hell that hasn't made
>> up its mind whether to be RISC, CISC, or VLIW, even I have
>> been affected by that concern.
>>

> Yeah...

> Your stuff tends to come off as horridly over complicated, and not
> particularly RISC-like either.

> As for some things in my 66000:
Registers: 32-registers 64-bit each
> Instruction lengths (bits): {32, 64, 96, 128, 160}
> VLE uses the same 4-bits when inst<31..29> == 00x
> Major OpCodes have 16-bit constant
> Load/Store
> Pipelined for most ops.
> FPU exists in GPR space.
> Integer ops, FPU, and SIMD all exist within the same registers.
> Addressing modes:
[Base+disp16]
[Base+index<<scale]
[Base+index<<scale+disp32]
[base+index<<scale+disp64]
Base = R0 -> IP
index = R0 -> 0x0

> Current number of defined instruction encodings:
> 2218
> Currently number of mnemonics:
> 61
Maximum number of instruction encodings:
~5000

On 12/9/2023 3:05 PM, Paul A. Clayton wrote:
> On 12/9/23 12:27 PM, Anton Ertl wrote:
> [snip]
>> The ARM A64 seem to have had no qualms at introducing features like
>> load-pair and store-pair that raise eyebrows among purists,
>
> Quick note: that seems to fall out more-or-less for free when
> supporting fast unaligned full-register-size ("word") load/store.
> I.e., if you "need" the hardware to load two adjacent "words", one
> can implement a double-width load that guarantees alignment with
> little change to the load/store design. There is the complication
> of doubling the number of source/destination registers for
> stores/loads.
>

Yes, this is also why for the most part, my 128-bit MOV.X op had imposed
an 8-byte alignment even when everything else is unaligned.

Did experimentally add support for unaligned MOV.X though, but this
means I may need feature-flags for my compiler and emulator to make
effective use of it (for the compiler, so that it can be aware that it
is safe to use MOV.X for unaligned cases, and the emulator that it
should allow it without raising an alignment-fault).

Allowing unaligned MOV.X in this case, just sort of added some cost to
the extract/insert logic (which needed to move from working with 128
bits to working with 192 bits).

These operations do effectively eat all 3 lanes though:
Lanes 1/2, the Load/Store itself;
Lane 3, provides the Source register ports for Store operations.

Though, it is basically the same configuration as used for 128-bit SIMD ops.

>> so if they
>> thought they would gain enough by deviating from A64 being a
>> load-store architecture, or from sticking to fixed-width instructions,
>> or from it having 32 registers, they would have gone there.
>
> I think the AArch64 design was somewhat low-risk — which makes
> sense for a commercial design intended as a long-term stable
> interface with significant time-to-market pressure.
>
> (By the way, I think AArch64 has 31 GPRs plus zero/SP and 32
> FP/SIMD registers and the PC.)
>
>> Apparently they did not think so, and the IPC and performance per Watt
>> of Firestorm indicates that they have designed well.
>
> While the perfect is the enemy of the good (e.g., timeliness of
> result is important), emphasis on timeliness and low-risk tends to
> produce a worse result than if a statistician made the decision
> (especially if externalities are included — what is profitable for
> a company can be bad for humanity).
>

Best for humanity would likely be if it were all open and not based on
profit motive.

But, it can also be noted on the other side of things that profit motive
can often provide a better quality product than tends to result from
people doing stuff "just for the hell of doing it" (where things are
often functional but significantly lacking in "polish").

Granted, this latter point matters less for things like CPU ISA's and
developer tools than for end-user facing products (where "for profit"
development tends to dominate).

>> The surviving RISC properties are no longer as important as they were
>> in the late 1980s, but they still result in fewer problems for the
>> microarchitects to solve, and all of what goes with lower complexity.
>
> Getting the complexity right seems one of the challenges and one
> area where broad experience/knowledge is particularly helpful.
> Experience strengthens intuition and knowledge facilitates
> determining when complexity can be managed more easily (and when
> limited constraints can greatly reduce the effective complexity).
>
> [Captain Obvious, at your service.☺]

I am sometimes concerned that my stuff may be a bit more complicated
than ideal, but alas.

It was at least within the limits of my ability to implement it, and a
better focused subset could likely be defined as well (and a lot of the
stuff I had defined, isn't actually required for an implementation).

Mostly it is more a thing of figuring out what is "value added", with a
more minimal subset being used if FPGA constraints are a concern (then
trying to balance between what is useful to have, vs cost tradeoffs).

If there were ASIC versions, likely the core's feature-set would be
adapted to the intended use-case for the ASIC (say, a core intended for
neural-net processing might focus more heavily on SIMD features; whereas
one intended for motor controls might leave out pretty much anything
much beyond basic integer stuff, ...).

There was one subset, eg:
https://github.com/cr88192/bgbtech_btsr1arch/blob/master/docs/2021-11-15_BJX2_Fix32D.txt

But, looking at it, may need to update some things as it still includes
some features that have been deprecated or dropped from my main ISA.

Might also make sense to define the possibility of Fix32-XG2, which is
basically the same but would be expanded to 64 registers.

Maybe also add the JCMPZ ops as well.

Keeping all my specs in sync with each other is a hassle sometimes.

But, the Fix32 subset doesn't seem too far off from a more conventional
RISC.

In other news, I recently ended up getting tuning forks as a test, and
can confirm that for the most part, I can't hear them.
128Hz: Nope (can feel vibrations, can't hear anything).
256Hz: Barely, if I stick the handle in my ear.
512Hz: Still barely, but slightly easier.

Can also sorta hear the 512Hz one it if I have it stuck to a cardboard
box and stick my head in the box (or if holding the tuning fork via my
teeth; but this doesn't really work for 256Hz).

Can feel them vibrate if holding them, so presumably they make sounds.

But, yeah, still seems like I am "mostly deaf" to much of anything below
around 1 to 2 kHz...

On 12/9/2023 4:03 PM, MitchAlsup wrote:
> BGB wrote:
>
>> On 12/9/2023 6:35 AM, Quadibloc wrote:
>>>
>>> In designing Concertina II, which might well be described
>>> as a half-breed architecture from Hell that hasn't made
>>> up its mind whether to be RISC, CISC, or VLIW, even I have
>>> been affected by that concern.
>>>
>
>> Yeah...
>
>> Your stuff tends to come off as horridly over complicated, and not
>> particularly RISC-like either.
>
> As for some things in my 66000:
>     Registers: 32-registers 64-bit each

Yeah, 64-bits here as well, 128 via even-pairs (So, 32x 128-bit virtual
registers).

>    Instruction lengths (bits): {32, 64, 96, 128, 160}

Don't have 128 or 160, would require more expensive fetch and decode.

Could in theory add 48-bit and 80-bit in baseline mode, but have not
done so (these would create more problems than they would solve). In XG2
Mode, these would remain non-encodable.

>    VLE uses the same 4-bits when inst<31..29> == 00x

Baseline:
(15:12): 7/9/E/F (32+), Else: 16-bit
(15:8): FE/FF (64+)
...

XG2 (15:8):
zzz1111z: 64+, Else: 32-bit (or WEX)

zzz0z0zz: Pred?T
zzz0z1zz: Pred?F
zzz0101z: Pred?T + WEX
zzz0111z: Pred?F + WEX

zzz1z0zz: Scalar
zzz1z1zz: WEX Cases

>    Major OpCodes have 16-bit constant
>    Load/Store
>    Pipelined for most ops.
>    FPU exists in GPR space.
>      Integer ops, FPU, and SIMD all exist within the same registers.
>    Addressing modes:
>       [Base+disp16]
>       [Base+index<<scale]
>       [Base+index<<scale+disp32]
>       [base+index<<scale+disp64]
>           Base  = R0 -> IP
>           index = R0 -> 0x0
>
> Current number of defined instruction encodings:
>    2218
> Currently number of mnemonics:
>      61

Hmm, so more encodings possible for fewer mnemonics...

I have the issue that for SIMD or converter ops, often they are closer
to 1:1 between mnemonic and encoding.

>  Maximum number of instruction encodings:
>    ~5000

Depends mostly on how the space was allocated.

Major instruction blocks I have:
F0, F1, F2, F3, F8, F9

F0: Mostly 3R and 2R ops.
F1: LD/ST, Disp9
F2: 3RI Imm9 and 2RI Imm10
F3: Reserved

F8: 2RI Imm16
F9: Reserved

Each block could theoretically hold on of:
512 3R instructions
16384 2R instructions
32 Imm9/Disp9 instructions;
512 2RI Imm10 instructions.
8 Imm16 instructions.

So, the F8 block has:
MOV, ADD, LDSH, and FLDCH, and is already mostly full.

Thus far, roughly 24 3R spots were used for 2R space, so this is space
for around 768 2R instructions (a little over 1/3 of this space has been
used).

BGB wrote:

> On 12/9/2023 4:03 PM, MitchAlsup wrote:
>> BGB wrote:
>>
>>> On 12/9/2023 6:35 AM, Quadibloc wrote:
>>>>
>>>> In designing Concertina II, which might well be described
>>>> as a half-breed architecture from Hell that hasn't made
>>>> up its mind whether to be RISC, CISC, or VLIW, even I have
>>>> been affected by that concern.
>>>>
>>
>>> Yeah...
>>
>>> Your stuff tends to come off as horridly over complicated, and not
>>> particularly RISC-like either.
>>
>> As for some things in my 66000:
>>     Registers: 32-registers 64-bit each
>>    Instruction lengths (bits): {32, 64, 96, 128, 160}

> Don't have 128 or 160, would require more expensive fetch and decode.

Minimum fetch width is 4 which means by the time you need the constants of
3-5 word instructions, they have arrived.

My 6-wide machine looks like it will fetch 4×¼ cache lines per cycle
(16 words in blocks of 4) while also fetching 1×40-bit word that provides
the 5-indexes used in the subsequent fetch cycle. eXcel analysis of this
organization indicates it should cover ~97% of all patterns that contain
6-instructions.

>>    VLE uses the same 4-bits when inst<31..29> == 00x
>>    Major OpCodes have 16-bit constant
>>    Load/Store
>>    Pipelined for most ops.
>>    FPU exists in GPR space.
>>      Integer ops, FPU, and SIMD all exist within the same registers.
>>    Addressing modes:
>>       [Base+disp16]
>>       [Base+index<<scale]
>>       [Base+index<<scale+disp32]
>>       [base+index<<scale+disp64]
>>           Base  = R0 -> IP
>>           index = R0 -> 0x0
>>
>> Current number of defined instruction encodings:
>>    2218
>> Currently number of mnemonics:
>>      61

> Hmm, so more encodings possible for fewer mnemonics...

> I have the issue that for SIMD or converter ops, often they are closer
> to 1:1 between mnemonic and encoding.

>>  Maximum number of instruction encodings:
>>    ~5000

> Depends mostly on how the space was allocated.

2218 and 61 are exact counts, accepting a constraint that adding more
instruction groups can only remove terms from the current length and
position decoders {0->x or 1->x}m is what constrains me to ~5000.
Relaxing this rule would allow for millions.

But it is entirely against my "reduced" mantra.

I have 23 major OpCodes unallocated and 6 more that are permanently
reserved {these guard against jumping into random data when E=1}

I got 2192 instructions from 6 major OpCodes.

> Major instruction blocks I have:

000110 XON6 Predicate
000111 XON7 Shifts Imm12
001001 XOP1 2-Operand
001010 XOP2 Memory
001100 XOP4 3-Operand
001101 XOP5 1-Operand

011xxx .... Branches
10xxxx .... Memory Disp16
11xxxx .... Int Imm16

John Levine <johnl@taugh.com> writes:

> It appears that David Brown <david.brown@hesbynett.no> said:
>
>> Based solely on the information Scott gave, however, I would suggest
>> that the "OPR" instruction - "microcoded operation" - and the "IOT"
>> operation would mean it certainly was not RISC. (This is true even if
>> it has other attributes commonly associated with RISC architectures.)
>
> The PDP-5 was built in 1963 and the term RISC dates from the late 1970s
> so this is a purely hypothetical argument.

The underlying ideas were looked at in the late 1970s, but I
believe the name RISC goes back only to the early 1980s.

> Keep in mind that the PDP-8 was built from 1400 discrete transistors
> and 10,000 diodes. It had to be simple.

The LGP-30, first delivered in 1956, had 113 tubes and 1450
diodes. I think it's fair to say the LGP-30 has a good
claim to being the world's first minicomputer.

Paul A. Clayton wrote:

> Getting the complexity right seems one of the challenges and one
> area where broad experience/knowledge is particularly helpful.

It was due to my vast/long* experience that I saw forwarding as the
register version of delivering constants as operands into execution.

It was due to my singular experience with a GPU ISA that I included
operand sign control {ADD R7,-R9,R19} as part of routing data
around which is not part of execution per-seé but simple data path
bit manipulation.

> Experience strengthens intuition and knowledge facilitates
> determining when complexity can be managed more easily (and when
> limited constraints can greatly reduce the effective complexity).

> [Captain Obvious, at your service.☺]

(*) some might say tiring.

MitchAlsup <mitchalsup@aol.com> schrieb:

> Question (to everyone):: Has your word processor or spreadsheet
> added anything USEFUL TO YOU since 2000 ??

In my case: Yes.

Besides making many things worse, the new formula editor (since
2010?) in Word is reasonable to work with, especially since it is
possible to use LaTeX notation now (and thus it is now possible
to paste from Maple).

Previously, I actually wrote some reports in LaTeX, going to some
trouble to make them appear visually like the Word template du jour
(but the formulas gave it away, they looked to nice for Word).

Formula _numbering_ - now that, Microsoft managed to make worse
(which simply comes naturally in LaTeX).

And, come to think of it, since Office 365 (I think) they now
allow direct use of svg files as graphics, allowing two
non-braindead ways of including pdf graphics in Word - either
via Inkscape (read as pdf, write as svg) or through command-line
tools (usually via Cygwin).

MitchAlsup <mitchalsup@aol.com> schrieb:

> If you want multi-threaded programs to succeed you need to start writing
> them in a language that is not inherently serial !! It is brain dead
> easy to write embarrassingly parallel applications in a language like
> Verilog. The programmer does not have to specify when or where a gate
> is evaluated--that is the job of the environment (Verilog).....

But the job of a programmer to keep everything that can be parallel in
mind... Would you write a compiler, or a word processor, in Verilog?
How much harder would that be, compared to a serial language?

My personal favorites for parallel programming are PGAS languages
like (yes, you guessed it) Fortran, where the central data
structure is the coarray.

On image X, you can manuipulate data on your own image, and you can
access data on other images (let's call it Y) in these coarrays via
special syntax, as a[Y].

You have to make sure that you synchronize before accessing data
that has been modified on another image.

According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>> The PDP-5 was built in 1963 and the term RISC dates from the late 1970s
>> so this is a purely hypothetical argument.
>
>The underlying ideas were looked at in the late 1970s, but I
>believe the name RISC goes back only to the early 1980s.

I checked, the 801 project started in 1975. The RISC-I paper was
published in 1981 and I think they came up with the name in 1980, so
close enough.

>> Keep in mind that the PDP-8 was built from 1400 discrete transistors
>> and 10,000 diodes. It had to be simple.
>
>The LGP-30, first delivered in 1956, had 113 tubes and 1450
>diodes. I think it's fair to say the LGP-30 has a good
>claim to being the world's first minicomputer.

I poked around one that was old and dead but just looking at it, you
could see what a very elegant design it was to get useful work out of
so little logic.

The Bendix G-15 had 450 tubes and 3000 diodes so it's the other
contender for the title. Both machines were introduced in 1956,
cost about the same, and were about the same size, 800lb for the LGP-30,
956lb for the G-15.

--
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

According to MitchAlsup <mitchalsup@aol.com>:
>I actually means "Reduced Instruction Set Computers for VLSI" K.
>
>> https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf
>
>My memory ain't what it used to be........
>
>Several quotes from the Ditzel paper::
>
>By a judicious choice of the proper instruction set and the design of a corresponding
>architecture, we feel that it should be possible to have a very simple instruction set
>that can be very fast. This may lead to a substantial net gain in overall program
>execution speed. This is the concept of the Reduced Instruction Set Computer.
>
>Johnson used an iterative technique of proposing a machine, writing a compiler, measuring
>the results to propose a better machine, and then repeating the cycle over a dozen times.
>Though the initial intent was not specifically to come up with a simple design, the result
>was a RISC-like 32-bit architecture whose code density was as compact as the PDP-11 and
>VAX [Johnson79].

Yup. If anyone can find that Johnson tech report I'd like to read it.
Some googlage only found references to it.

It seems to me there were two threads to the RISC work. IBM designed
the hardware and compiler together, a more sophisticated version of
what Johnson did, so they were constantly trading off what they could
do in hardware and what they could do in software, usually finding
that software could do it better, e.g., splitting instruction and data
caches because they knew their compiler's code never modified
instructions.

Berkeley used the old PCC compiler which wasn't terrible but did not
do very sophisticated register allocation, so they invented hardware
register windows. In retrospect, the 801 project was right and windows
albeit clever were a bad idea. Better to use that chip area for a
bigger cache.

--
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

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>On 12/3/23 10:01 AM, Anton Ertl wrote:
>> "Paul A. Clayton" <paaronclayton@gmail.com> writes:
>>> A uniquely difficult architecture like x86 increases the barrier
>>> to competition both from patents and organizational knowledge and
>>> tools. While MIPS managed to suppress clones with its patent on
>>> unaligned loads (please correct any historical inaccuracy), Intel
>>> was better positioned to discourage software-compatible
>>> competition — and not just financially.
>>
>> Really? There is software-compatible competition to Intel. Not so
>> much for MIPS (maybe Loongson).
>
>There is also less economic incentive to seek binary compatibility
>with MIPS. Even when MIPS was used by multiple UNIX system
>vendors, binaries would not be compatible across UNIXes. Targeting
>workstations also influenced the economics of cloning.

That was noticed by Motorola when developing the 88100. They
sponsered a binary compatability standard (BCS) and an object
comptability standard (OCS) in conjunction with their customers
to provide standard portable binaries across operating
systems. There was a group called 88open (of which I was
a member, via Convergent Technologies which had been
purchased by Burroughs/Unisys) which created and managed the
standards documents.

https://en.wikipedia.org/wiki/88open

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>The ARM A64 seem to have had no qualms at introducing features like
>load-pair and store-pair that raise eyebrows among purists, so if they
>thought they would gain enough by deviating from A64 being a
>load-store architecture, or from sticking to fixed-width instructions,
>or from it having 32 registers, they would have gone there.
>Apparently they did not think so, and the IPC and performance per Watt
>of Firestorm indicates that they have designed well.

Actually the 'RISC purity' of the A64 Architecture was not
likely to have ever been a consideration when choosing which
features to add to the architecture. They're in the money
making business, not some idealistic RISC business.

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>John Levine <johnl@taugh.com> writes:
>
>> It appears that David Brown <david.brown@hesbynett.no> said:
>>
>>> Based solely on the information Scott gave, however, I would suggest
>>> that the "OPR" instruction - "microcoded operation" - and the "IOT"
>>> operation would mean it certainly was not RISC. (This is true even if
>>> it has other attributes commonly associated with RISC architectures.)
>>
>> The PDP-5 was built in 1963 and the term RISC dates from the late 1970s
>> so this is a purely hypothetical argument.
>
>The underlying ideas were looked at in the late 1970s, but I
>believe the name RISC goes back only to the early 1980s.
>
>> Keep in mind that the PDP-8 was built from 1400 discrete transistors
>> and 10,000 diodes. It had to be simple.
>
>The LGP-30, first delivered in 1956, had 113 tubes and 1450
>diodes. I think it's fair to say the LGP-30 has a good
>claim to being the world's first minicomputer.

I'd suggest the ABC machine, but it was restricted to solving
linear equations :-) I did have the last remaining
component in my possession for a few months in 1981 (the
memory drum).

There's a modern replica at the CHM.

John Levine <johnl@taugh.com> writes:
>According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>>> The PDP-5 was built in 1963 and the term RISC dates from the late 1970s
>>> so this is a purely hypothetical argument.
>>
>>The underlying ideas were looked at in the late 1970s, but I
>>believe the name RISC goes back only to the early 1980s.
>
>I checked, the 801 project started in 1975. The RISC-I paper was
>published in 1981 and I think they came up with the name in 1980, so
>close enough.
>
>>> Keep in mind that the PDP-8 was built from 1400 discrete transistors
>>> and 10,000 diodes. It had to be simple.
>>
>>The LGP-30, first delivered in 1956, had 113 tubes and 1450
>>diodes. I think it's fair to say the LGP-30 has a good
>>claim to being the world's first minicomputer.
>
>I poked around one that was old and dead but just looking at it, you
>could see what a very elegant design it was to get useful work out of
>so little logic.
>
>The Bendix G-15 had 450 tubes and 3000 diodes so it's the other
>contender for the title. Both machines were introduced in 1956,
>cost about the same, and were about the same size, 800lb for the LGP-30,
>956lb for the G-15.

The electrodata Datatron system shipped in 1954. I used to work in
the plant where it was designed and built (albeit decades later
when the B4800 was the high-end machine).

John Levine wrote:

> According to MitchAlsup <mitchalsup@aol.com>:
>>I actually means "Reduced Instruction Set Computers for VLSI" K.
>>
>>> https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf
>>
>>My memory ain't what it used to be........
>>
>>Several quotes from the Ditzel paper::
>>
>>By a judicious choice of the proper instruction set and the design of a corresponding
>>architecture, we feel that it should be possible to have a very simple instruction set
>>that can be very fast. This may lead to a substantial net gain in overall program
>>execution speed. This is the concept of the Reduced Instruction Set Computer.
>>
>>Johnson used an iterative technique of proposing a machine, writing a compiler, measuring
>>the results to propose a better machine, and then repeating the cycle over a dozen times.
>>Though the initial intent was not specifically to come up with a simple design, the result
>>was a RISC-like 32-bit architecture whose code density was as compact as the PDP-11 and
>>VAX [Johnson79].

> Yup. If anyone can find that Johnson tech report I'd like to read it.
> Some googlage only found references to it.

> It seems to me there were two threads to the RISC work. IBM designed
> the hardware and compiler together,

Something I keep pushing Quadrablock to do.
> a more sophisticated version of
> what Johnson did, so they were constantly trading off what they could
> do in hardware and what they could do in software, usually finding
> that software could do it better, e.g., splitting instruction and data
> caches because they knew their compiler's code never modified
> instructions.

Apparently they had no notion of JiT compilation and JiT caches.

> Berkeley used the old PCC compiler which wasn't terrible but did not
> do very sophisticated register allocation, so they invented hardware
> register windows. In retrospect, the 801 project was right and windows
> albeit clever were a bad idea. Better to use that chip area for a
> bigger cache.

mitchalsup@aol.com (MitchAlsup) writes:

> Scott Lurndal wrote:
>
>> The lack of general purpose registers doesn't disqualify it
>> from the RISC label in my opinion.
>
> Then RISC is a meaningless term.
>
> PDP-8 certainly is simple nor does it have many instructions, but it
> certainly is NOT RISC.
>
> Did not have a large GPR register file
> Was Not pipelined
> Was Not single cycle execution
> Did not overlap instruction fetch with execution
> Did not rely on compiler for good code performance

Of course the PDP-8 is a RISC. These propperties may have been
common among some RISC processors, but they don't define what
RISC is. RISC is a design philosophy, not any particular set
of architectural features.

Tim Rentsch wrote:

> mitchalsup@aol.com (MitchAlsup) writes:

>> Scott Lurndal wrote:
>>
>>> The lack of general purpose registers doesn't disqualify it
>>> from the RISC label in my opinion.
>>
>> Then RISC is a meaningless term.
>>
>> PDP-8 certainly is simple nor does it have many instructions, but it
>> certainly is NOT RISC.
>>
>> Did not have a large GPR register file
>> Was Not pipelined
>> Was Not single cycle execution
>> Did not overlap instruction fetch with execution
>> Did not rely on compiler for good code performance

> Of course the PDP-8 is a RISC. These propperties may have been
> common among some RISC processors, but they don't define what
> RISC is. RISC is a design philosophy, not any particular set
> of architectural features.

So what we can take from this is that RISC as a term has become meaningless.

On 12/10/2023 11:56 AM, John Dallman wrote:
> In article <P0mdN.7690$83n7.6186@fx18.iad>, scott@slp53.sl.home (Scott
> Lurndal) wrote:
>
>> That was noticed by Motorola when developing the 88100. They
>> sponsered a binary compatability standard (BCS) and an object
>> comptability standard (OCS) in conjunction with their customers
>> to provide standard portable binaries across operating
>> systems.
>
> Doing that for the file formats and calling standard is eminently
> practical, but how was it managed for library APIs? Were there baseline
> standards for libc, libm, libpthread and so on, which vendors could
> extend, or were those things fully standardised?
>

Seems like, yeah, to have any hope of binary compatibility, one also
needs to standardize on either the libraries or the specific syscalls
and syscall mechanism (like how it was in the MS-DOS era).

But, hoping for cross-platform seems like a bit of an ask when modern
OS's, like Linux, are hard-pressed to have binary compatibility between
different versions or different variants of the same OS on the same
hardware.

Also annoys me that most FOSS projects are solely focused on
implementation, rather than on specifying things well enough to
potentially allow for multiple implementations to exist.

Say, people put all their effort trying to make "the one true whatever",
rather than specifying things well enough to allow for re-implementation
as-needed.

Or, like the annoyance of the whole Linux software stack, where one
seemingly can't really build or reuse any single part of it without
effectively bringing over the entire GNU ecosystem in the process.

> John

jgd@cix.co.uk (John Dallman) writes:
>In article <ul4pvc$2r22$1@gal.iecc.com>, johnl@taugh.com (John Levine)
>wrote:
>
>> Yup. If anyone can find that Johnson tech report I'd like to read
>> it. Some googlage only found references to it.
>
>The Computer History Museum has hardcopy:
>
><https://www.computerhistory.org/collections/catalog/102773566>
>
>The UK's Centre for Computing History also appears to have a copy:
><https://www.computinghistory.org.uk/det/12205/Bell-Computing-Science-Tech
>nical-Report-80-A-32-Bit-Processor-Design/> Since they're local to me,
>I've asked them if they can make me a copy.
>
>If anyone else wants to hunt, the reference is in:
><https://inst.eecs.berkeley.edu/~n252/paper/RISC-patterson.pdf>
>
>The author was Stephen C Johnson, who worked at Bell Labs in the 1970s,
>largely on languages; he was responsible for YACC.

He was also responsible for PCC, if I recall correctly.