Re: Stealing a Great Idea from the 6600

On 4/22/2024 12:49 AM, Terje Mathisen wrote:

MitchAlsup1 wrote:

BGB wrote:
>

On 4/20/2024 5:03 PM, MitchAlsup1 wrote:
Like, in-order superscalar isn't going to do crap if nearly every instruction depends on every preceding instruction. Even pipelining can't help much with this.

>
Pipelining CREATED this (back to back dependencies). No amount of
pipelining can eradicate RAW data dependencies.
>

The compiler can shuffle the instructions into an order to limit the number of register dependencies and better fit the pipeline. But, then, most of the "hard parts" are already done (so it doesn't take much more for the compiler to flag which instructions can run in parallel).

>
Compiler scheduling works for exactly 1 pipeline implementation and
is suboptimal for all others.

 Well, yeah.
 OTOH, if your (definitely not my!) compiler can schedule a 4-wide static ordering of operations, then it will be very nearly optimal on 2-wide and 3-wide as well. (The difference is typically in a bit more loop setup and cleanup code than needed.)
 Hand-optimizing Pentium asm code did teach me to "think like a cpu", which is probably the only part of the experience which is still kind of relevant. :-)
 

Mine is hard-pressed to even make effective use of the current pipeline, so going wider does not make sense at present.
As I had noted before, the main merit of 3 wide in my case is that it makes it easier to justify a 6R register file, which, unlike the 4R register file, doesn't choke up with trying to run other instructions in parallel with memory store and similar (which is actually a fairly serious restriction given how much memory operations tend to clog up Lane 1; opportunities for "ALU|ST" being more common than "ALU|ALU").
Granted, one could argue that (Reg, Disp) memory addressing could be supported entirely within a 2R1W pattern, which while true in premise, does not match my implementation (which always uses indexed addressing internally, treating the Disp as a virtual register; thus eating 3 register ports).
Well, and for the 4R2W configuration, the main priority is minimizing LUT cost (which favors leaving it as-is, with the current restrictions).
Granted, some similar issues apply to 128-bit MOV.X and SIMD ops, which as-is can only exist as scalar ops. These could potentially also be hacked around (say, to allow ALU|SIMD or ALU|MOV.X, but the "fix" would cost a lot of LUTs). Mostly in that variability in terms of input routing does not come cheap.
Though, that said, the 3rd lane still gets used for a share of basic ALU instructions, so isn't entirely going to waste either.

Terje