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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Michael S wrote:

On Mon, 11 Dec 2023 12:23:51 -0800
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:

On 12/9/2023 10:11 AM, MitchAlsup wrote:

RISC was defined before CISC was coined as its contrapositive.

I agree, but this illustrates some of the semantic confusion we are
having regarding defining RISC. In normal speech, the opposite of
"reduced" is "increased",

In context of Reduced Instruction Set the opposit of "reduced" is
"full" or "complete". IMHO.

What if you had an instruction set that was both reduced and complete
{and essentially full} ?

Consider an ISA where there are only 61 instructions, but this contains complete access to typical RISC features, Scaled index addressing, vectorization, gather, scatter, SIMD functionality, and elementary
functions within those 'only 61' instructions ??

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Tim Rentsch wrote:

John Levine <johnl@taugh.com> writes:

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:

Looking at the genesis of the RISCs, full means the S/360 and S/370
instruction sets for the 801 project, and VAX for the Berkeley RISC
project. Not sure what full means for Stanford MIPS.

This web page suggests it was more from the other direction, they
started from the compiler:

The Stanford research group had a strong background in compilers,
which led them to develop a processor whose architecture would
represent the lowering of the compiler to the hardware level, as
opposed to the raising of hardware to the software level, which
had been a long running design philosophy in the hardware
industry.

https://cs.stanford.edu/people/eroberts/
courses/soco/projects/risc/mips/index.html

I agree that these days RISC doesn't really meen anything beyond
"not a Vax or S/360".

Surely people don't view the Itanium as being a RISC. And what
about the Mill? Is that a RISC or not?

Itanium is VLIW
Mill is Belted
Both are dependent on compiler to perform code scheduling.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)