Re: Computer architects leaving Intel...

On 9/1/2024 4:02 PM, Paul A. Clayton wrote:

On 8/31/24 4:56 PM, BGB wrote:
[snip]

I was mostly doing dual-issue with a 4R2W design.
>
Initially, 6R3W won out mostly because 4R2W disallows an indexed store to be run in parallel with another op; but 6R3W did allow this.

 Stores and MADD allow one register read to be delayed by at least
one cycle. If the following cycle had a free read port, that could
be stolen to complete the store/MADD. This could be viewed as
cracking a three-source operation into a two-source operation and
a one-source operation that reads source operands in a following
cycle except that this operation never uses a result from the
previous cycle.
 

This wouldn't map well to my existing decoder/pipeline, which requires all the ports (and all the registers) to be available at the time an instruction enters EX1, and currently has no support for "cracking" an instruction over multiple cycles, but may spread a single instruction across multiple lanes.
For operations like Index Store or MAC/MADD, it would quietly eat the 3rd lane's ports, allowing the first 2 lanes to still be used.

In a VLIW, one could even imagine the register name for the
delayed read being in the next instruction word if the available
read port was always from using an immediate or having fewer
source operands. This would add complexity for exceptions,
branches, and even instruction cache misses. With a small
buffer, a VLIW could also borrow from a previous cycle; an
operation with one register source could include a "load into
buffer" operation. (I do not recall ever reading about cross-
cycle/-instruction-word register fields in any VLIW. While it
seems to fit the VLIW model of static resource management, it
breaks the "atomic" view of an instruction word and of the
operation components — even borrowing within an instruction
word seems not to have been considered.)
 Relying on forwarding or stealing from a future surplus would
result in variable performance unless the opportunities were
guaranteed (at least for enough cases that performance glitches
would not be significant).

Yeah, I wouldn't want to do this.
But, yeah, if the restriction only applied to indexed store (in the current implementation, it applies to all stores), it would still be around 4% of the total instruction stream.
As-is, it is closer to 12%, and causing an extra penalty for 12% of the total-executed instructions was undesirable (but, IMHO, still better than needing to use multiple instructions).
If I went to an in-order superscalar approach, it may make sense to drop back to 2 wide, either eating the penalty (which at least in this case would no longer effect binary compatibility), or figuring out a workaround.; or stick with 3-wide but try to figure out ways to make the 3rd lane "more useful" in this case.
Though, usual issue with most code is that there are not enough independent instructions within a basic block to use all 3 lanes (usual case this happens is with code with a lot of implicit parallelism).
Otherwise, annoying:
Despite configuring GCC to use RV64G, it builds its C library as RV64GC and is like "well, close enough". So, looks like allowing binaries to use GLIBC and Linux-style syscalls also means prioritizing getting the 'C' extension implemented.
Which is annoying because seemingly nearly every instruction has its own encoding scheme for the immediate fields.
I guess, register fields don't move around too much, and that is all most people care about. And the listing is arguably fairly short, even if nearly every instruction has different immed fields.
Well, and also some different instructions are encoded based on the contents of the register fields, ...
...