Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Stealing a Great Idea from the 6600
Date: Sun, 21 Apr 2024 02:17:39 -0500
Organization: A noiseless patient Spider
Lines: 727
Message-ID: <v02eij$6d5b$1@dont-email.me>
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>
 <da6dc5fe28bb31b4c73d78ef1aac2ac5@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 21 Apr 2024 09:17:41 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="eb8a718465b00007c507332e9ba6007d";
	logging-data="210091"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18cgsk1ZT4CtNrI/Ypm6riPsmKNBlRuu5U="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:Q6Qh/Lb8V4a89vGdA76oZZp3h3o=
Content-Language: en-US
In-Reply-To: <da6dc5fe28bb31b4c73d78ef1aac2ac5@www.novabbs.org>
Bytes: 28073

On 4/20/2024 5:03 PM, MitchAlsup1 wrote:
> 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.
> 

Yeah.


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

I had gone further and used mostly 9/10 bit fields (mostly expanded to 
10/12 in XG2).


I don't really think this is a bad choice in a statistical sense (as it 
so happens, most of the immediate values can fit into a 9-bit field, 
without going too far into "diminishing returns" territory).

Ended up with some inconsistency when expanding to 10 bits:
   Displacements went 9u -> 10s
   ADD/SUB: 9u/9n -> 10u/10n
   AND: 9u -> 10s
   OR,XOR: 9u -> 10u

And was initially 9u->10u (like OR and XOR), but changed over at the 
last minute:
   Negative masks were far more common than 10-bit masks;
   At the moment, the change didn't seem to break anything;
   I didn't really have any other encoding space to put this.
     The main "sane" location to put it was already taken by RSUB;
     The Imm9 space is basically already full.

With OR and XOR, negative masks are essentially absent, so switching 
these to signed would not make sense; even if this breaks the symmetry 
between AND/OR/XOR.


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

I had saw a video talking about the Nintendo 64, and it was saying that 
the 2x paired 32-bit register mode was used more often than the native 
64-bit mode, as the native 64-bit mode was slower as apparently it 
couldn't fully pipeline the 64-bit ops, so using it in this mode came at 
a performance hit (vs using it to run glorified 32-bit code).


>> Integer operations (on 64-bit registers) that give UB or trap if 
>> values are outside of signed Int32 range;
> 
> Isn't it just wonderful ??
> 

No direct equivalent in my case, nor any desire to add these.

Preferable I think if the behavior of instructions is consistent across 
implementations, though OTOH can claim strict 1:1 between my Verilog 
implementation and emulator, but at least I try to keep things consistent.

Though, things fall short of strict 100% consistency between the Verilog 
implementation and emulator (usually in cases where the emulator will 
trap, but the Verilog implementation will "do whatever").

Though, in part, this is because the emulator serves the secondary 
purpose of linting the compiler output.

Though, partly it is a case of, not even trapping is entirely free.


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

Most are defined in ways that I feel are sensible.

For ALU this means one of:
   64-bit result;
   Sign-extended from 32-bit result;
   Zero extended from 32-bit result.


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

In my case; for the Baseline encoding, Ld/St displacements were unsigned 
only.

For XG2, they are signed. It was a tight call, but the sign-extended 
case won out by an admittedly thin margin in this case.

Granted, this means that the Load/Store ops with a Disp5u/Disp6s 
encodings are mostly redundant in XG2, but are the only way to directly 
encode negative displacements in Baseline+XGPR (in pure Baseline, 
negative Ld/St displacements being N/E).


But, as for values in registers, I personally feel that my scheme (as a 
direct extension of the scheme that C itself seems to use) works better 
than the one used by MIPS and RISC-V, which seems needlessly wonky with 
a bunch of edge cases (that end up ultimately requiring the ISA to care 
more about the size and type of the value rather than less).

Then again, x86-64 and ARM64 went the other direction (always zero 
extending the 32-bit values).

Then again, it seems like a case where spending more in one area can 
save cost in others.


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

It is a tradeoff.

========== REMAINDER OF ARTICLE TRUNCATED ==========