Path: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Stealing a Great Idea from the 6600
Date: Sat, 20 Apr 2024 22:03:21 +0000
Organization: Rocksolid Light
Message-ID: <da6dc5fe28bb31b4c73d78ef1aac2ac5@www.novabbs.org>
References: <lge02j554ucc6h81n5q2ej0ue2icnnp7i5@4ax.com> <e2097beb24bf27eed0a92f14596bd59e@www.novabbs.org> <in312jlca131khq3vj0i24n6pb0hah2ur5@4ax.com> <71acfecad198c4e9a9b14ffab7fc1cb5@www.novabbs.org> <1s042jdli35gdo092v6uaupmrcmvo0i5vp@4ax.com> <oj742jdvpl21il2s5a1ndsp3oidsnfjmr6@4ax.com> <dd1866c4efb369b7b6cc499d718dc938@www.novabbs.org> <acq62j98dhmguil5ebce6lq4m9kkgt1fs2@4ax.com> <kkq62jppr53is4r70n151jl17bjd5kd6lv@4ax.com> <9d1fadaada2ec0683fc54688cce7cf27@www.novabbs.org> <v017mg$3rcg9$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="1823366"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="65wTazMNTleAJDh/pRqmKE7ADni/0wesT78+pyiDW8A";
User-Agent: Rocksolid Light
X-Rslight-Posting-User: ac58ceb75ea22753186dae54d967fed894c3dce8
X-Rslight-Site: $2y$10$tyQLyfhCYEQfIu4I8aUGNuHWpa1KT5UfbKOWym.eEUxwUDco1.BB6
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 13342
Lines: 293

BGB wrote:

> On 4/20/2024 12:07 PM, MitchAlsup1 wrote:
>> John Savard wrote:
>> 
>>> On Sat, 20 Apr 2024 01:09:53 -0600, John Savard
>>> <quadibloc@servername.invalid> wrote:
>> 
>> 
>>> And, hey, I'm not the first guy to get sunk because of forgetting what
>>> lies under the tip of the iceberg that's above the water.
>> 
>>> That also happened to the captain of the _Titanic_.
>> 
>> Concer-tina-tanic !?!
>> 

> Seems about right.
> Seems like a whole lot of flailing with designs that seem needlessly 
> complicated...



> Meanwhile, has looked around and noted:
> In some ways, RISC-V is sort of like MIPS with the field order reversed, 

They, in effect, Litle-Endian-ed the fields.

> and (ironically) actually smaller immediate fields (MIPS was using a lot 
> of Imm16 fields. whereas RISC-V mostly used Imm12).

Yes, RISC-V took a step back with the 12-bit immediates. My 66000, on
the other hand, only has 12-bit immediates for shift instructions--
allowing all shifts to reside in one Major OpCode; the rest inst[31]=1
have 16-bit immediates (universally sign extended).

> But, seemed to have more wonk:
> A mode with 32x 32-bit GPRs; // unnecessary
> A mode with 32x 64-bit GPRs;
> Apparently a mode with 32x 32-bit GPRs that can be paired to 16x 64-bits 
> as needed for 64-bit operations?... 

Repeating the mistake I made on Mc 88100....

> Integer operations (on 64-bit registers) that give UB or trap if values 
> are outside of signed Int32 range;

Isn't it just wonderful ??

> Other operations that sign-extend the values but are ironically called 
> "unsigned" (apparently, similar wonk to RISC-V by having signed-extended 
> Unsigned Int);
> Branch operations are bit-sliced;
> ....


> I had preferred a different strategy in some areas:
>    Assume non-trapping operations by default;

Assume trap/"do the expected thing" under a user accessible flag. 

>    Sign-extend signed values, zero-extend unsigned values.

Another mistake I mad in Mc 88100.

Do you sign extend the 16-bit displacement on an unsigned LD ??

> Though, this is partly the source of some operations in my case assuming 
> 33 bit sign-extended: This can represent both the signed and unsigned 
> 32-bit ranges.

These are some of the reasons My 66000 is 64-bit register/calculation only.

> One could argue that sign-extending both could save 1 bit in some cases. 
> But, this creates wonk in other cases, such as requiring an explicit 
> zero extension for "unsigned int" to "long long" casts; and more cases 
> where separate instructions are needed for Int32 and Int64 cases (say, 
> for example, RISC-V needed around 4x as many Int<->Float conversion 
> operators due to its design choices in this area).

It also gets difficult when you consider EADD Rd,Rdouble,Rexponent ??
is it a FP calculation or an integer calculation ?? If Rdouble is a
constant is the constant FP or int, if Rexponent is a constant is it
double or int,..... Does it raise FP overflow or integer overflow ??

> Say:
>    RV64:
>      Int32<->Binary32, UInt32<->Binary32
>      Int64<->Binary32, UInt64<->Binary32
>      Int32<->Binary64, UInt32<->Binary64
>      Int64<->Binary64, UInt64<->Binary64
>    BJX2:
>      Int64<->Binary64, UInt64<->Binary64
     My 66000:
       int64_t  -> { uint64_t, float,   double }
       uint64_t -> {  int64_t, float,   double }
       float    -> { uint64_t, int64_t, double }
       double   -> { uint64_t, int64_t, float  }

> With the Uint64 case mostly added because otherwise one needs a wonky 
> edge case to deal with this (but is rare in practice).

> The separate 32-bit cases were avoided by tending to normalize 
> everything to Binary64 in registers (with Binary32 only existing in SIMD 
> form or in memory).

I saved LD and ST instructions by leaving float 32-bits in the registers.

> Annoyingly, I did end up needing to add logic for all of these cases to 
> deal with RV64G.

No rest for the wicked.....

> Currently no plans to implement RISC-V's Privileged ISA stuff, mostly 
> because it would likely be unreasonably expensive. 

The sea of control registers or the sequencing model applied thereon ??
My 66000 allows access to all control registers via memory mapped I/O 
space.

>                                                     It is in theory 
> possible to write an OS to run in RISC-V mode, but it would need to deal 
> with the different OS level and hardware-level interfaces (in much the 
> same way, as I needed to use a custom linker script for GCC, as my stuff 
> uses a different memory map from the one GCC had assumed; namely that of 
> RAM starting at the 64K mark, rather than at the 16MB mark).



> In some cases in my case, there are distinctions between 32-bit and 
> 64-bit compare-and-branch ops. I am left thinking this distinction may 
> be unnecessary, and one may only need 64 bit compare and branch.

No 32-bit stuff, thereby no 32-bit distinctions needed.

> In the emulator, the current difference ended up mostly that the 32-bit 
> version sees if the 32-bit and 64-bit version would give a different 
> result and faulting if so, since this generally means that there is a 
> bug elsewhere (such as other code is producing out-of-range values).

Saving vast amounts of power {{{not}}}

> For a few newer cases (such as the 3R compare ops, which produce a 1-bit 
> output in a register), had only defined 64-bit versions.

Oh what a tangled web we.......

> One could just ignore the distinction between 32 and 64 bit compare in 
> hardware, but had still burnt the encoding space on this. In a new ISA 
> design, I would likely drop the existence of 32-bit compare and use 
> exclusively 64-bit compare.


> In many cases, the distinction between 32-bit and 64-bit operations, or 
> between 2R and 3R cases, had ended up less significant than originally 
> thought (and now have ended up gradually deprecating and disabling some 
> of the 32-bit 2R encodings mostly due to "lack of relevance").

I deprecated all of them.

> Though, admittedly, part of the reason for a lot of separate 2R cases 
> existing was that I had initially had the impression that there may have 
> been a performance cost difference between 2R and 3R instructions. This 
> ended up not really the case, as the various units ended up typically 
> using 3R internally anyways.


> So, say, one needs an ALU with, say:
>    2 inputs, one output;
you forgot carry, and inversion to perform subtraction.
>    Ability to bit-invert the second input
>      along with inverting carry-in, ...
>    Ability to sign or zero extend the output.

So, My 66000 integer adder has 3 carry inputs, and I discovered a way to
perform these that takes no more gates of delay than the typical 1-carry
in 64-bit integer adder. This gives me a = -b -c; for free.

> So, say, operations:
========== REMAINDER OF ARTICLE TRUNCATED ==========