Re: Computer architects leaving Intel...

On Tue, 17 Sep 2024 19:51:19 +0000, BGB wrote:

On 9/17/2024 4:39 AM, David Brown wrote:

On 16/09/2024 21:46, BGB wrote:

On 9/16/2024 4:27 AM, David Brown wrote:
>
Albeit, types like _Bool in my implementation are padded to a full
byte (it is treated as an "unsigned char" that is assumed to always
hold either 0 or 1).

>
That's the usual way to handle them.

Smallest C container is 1 byte
__BOOL can use as small a container as C can address

>

>
Another option would be for adjacent _Bool values to merge similar to
bitfields...
Though, seems that simply turning it into a byte is the typical option.

One can do ATOMIC stuff on a __BOOL
one cannot do ATOMIC stuff on struct { unsigned __bool: 1};

>

>
This comes up as an issue in some Windows file formats, where one
can't just naively use a struct with 32-bit fields because some 32-bit
members only have 16-bit alignment.

>
Ah, the joys of using ancient formats with new systems!
>

>
I was around when this stuff was still newish.
>
Some are essentially frozen in time with their misaligned members.

In HW the packing and unpacking of multi-container single variables
is easy--its just wires.

Still better than:
   "Well, initial field wasn't big enough";
   "Repurpose those bytes from over there, and glue them on".

Really NOT a problem in HW--understandably low efficiency in SW.

>
There would need to be a mechanism in the ISA to select between these
modes though (probably a "magic branch" scheme different from the one
used for Inter-ISA branches).

Modes make testing significantly harder. Each mode adds 1 to the
exponent
how many test cases it takes to adequately test a part.

>
This would likely include an RV64 encoding for "Branch to/from CoEx",
and an encoding within this ISA to jump between CoEx and "Native" mode.
>
Magic branches make sense mostly as any such mode switch is going to
require a pipeline flush.
>
This is assuming an implementation that would want to be able to support
both this ISA and also RV64GC.
>
One possibility could be (in native RV notation):
RV64 (Branches if supported, NOP if not):
   LBU X0, Xs, Disp12s  //Dest=RV64GC
   LWU X0, Xs, Disp12s  //Dest=CoEx
   LHU X0, Xs, Disp12s  //Dest=Native
New ISA:
   LBU X0, Xs, Disp10s  //Dest=RV64GC
   LWU X0, Xs, Disp10s  //Dest=CoEx
   LHU X0, Xs, Disp10s  //Dest=Native

This only gives 36-bits (top) or 30-bits (bottom) or range. What you are
going to want is 64-bits of range -- especially when switching modes--
you PROBABLY want to use an entirely different sub-tree of the
translation
table trees.