Re: Computer architects leaving Intel...

On 9/22/24 6:19 PM, MitchAlsup1 wrote:

On Sun, 22 Sep 2024 20:43:38 +0000, Paul A. Clayton wrote:
 

On 9/19/24 11:07 AM, EricP wrote:
[snip]

If the multiplier is pipelined with a latency of 5 and throughput
of 1,
then MULL takes 5 cycles and MULL,MULH takes 6.
>
But those two multiplies still are tossing away 50% of their work.

>
I do not remember how multipliers are actually implemented — and
am not motivated to refresh my memory at the moment — but I
thought a multiply low would not need to generate the upper bits,
so I do not understand where your "50% of their work" is coming
from.

      +-----------+   +------------+
     \  mplier  /     \   mcand  /        Big input mux
      +--------+       +--------+
           |                |
           |      +--------------+
           |     /               /
           |    /               /
           +-- /               /
              /     Tree      /
             /               /--+
            /               /   |
           /               /    |
          +---------------+-----------+
                hi             low        Products
 two n-bit operands are multiplied into a 2×n-bit result.
{{All the rest is HOW not what}}

So are you saying the high bits come for free? This seems
contrary to the conception of sums of partial products, where
some of the partial products are only needed for the upper bits
and so could (it seems to me) be uncalculated if one only wanted
the lower bits.

The high result needs the low result carry-out but not the rest of
the result. (An approximate multiply high for multiply by
reciprocal might be useful, avoiding the low result work. There
might also be ways that a multiplier could be configured to also
provide bit mixing similar to middle result for generating a
hash?)
>
I seem to recall a PowerPC implementation did semi-pipelined 32-
bit multiplication 16-bits at a time. This presumably saved area
and power

 You save 1/2 of the tree area, but ultimately consume more power.

The power consumption would seem to depend on how frequently both
multiplier and multiplicand are larger than 16 bits. (However, I
seem to recall that the mentioned implementation only checked one
operand.) I suspect that for a lot of code, small values are
common.
There might also be some benefits in special casing small values
if the multiplier supports SIMD. Small values can use
substantially less physical resources for multiplication and if
the multiplier is already designed to handle multiple
parallel/SIMD small multiplies, being able to squeeze another
scalar multiply in may be possible/practical (assuming the
communication of the values is not problematic).

          while also facilitating early out for small
multiplicands,

 Dadda showed that doubling the size of the tree only adds one
4-2 compressor delay to the whole calculation.

Interesting.
[snip]

<sound of soap box being dragged out>
This idea that macro-op fusion is some magic solution is bullshit.

 The argument is, at best, of Academic Quality, made by a student
at the time as a way to justify RISC-V not having certain easy
for HW to perform calculations.

The RISC-V published argument for fusion is not great, but fusion
(and cracking/fission) seem natural architectural mechanisms *if*
one is stuck with binary compatibility.

1) It's not free.

>
Neither is increasing the number of opcodes or providing extender
prefixes. If one wants binary compatibility, non-fusing
implementations would work.

 I did neither and avoided both.

My 66000's CARRY and PRED are "extender prefixes", admittedly
included in the original architecture so compensating for encoding
constraints (e.g., not having 36-bit instruction parcels) rather
than microarchitectural or architectural variation.
[snip]>> (I feel that encoding some of the dependency information could

be useful to avoid some of this work. In theory, common
dependency detection could also be more broadly useful; e.g.,
operand availability detection and execution/operand routing.)

 So useful that it is encoded directly in My 66000 ISA.

How so? My 66000 does not provide any explicit declaration what
operation will be using a result (or where an operand is being
sourced from). Register names express the dependencies so the
dataflow graph is implicit.
I was speculating that _knowing_ when an operand will be available
and where a result should be sent (rather than broadcasting) could
be useful information. Classic transport-triggered architectures
do this but do not integrate dynamic scheduling and do not handle
multiple use well (awkwardness of delayed use seems connected both
of these aspects).
While such information can be cached for operation networks that
are revisited with reasonable temporal locality, discovering
optimization opportunities dynamically has risk of not being used
(similar to prefetching). Bloating the communication of "what to
do" also adds cost, so early and more persistent (compile time)
caching of such information may not actually be helpful.

5) Any fused instructions leave (multiple) bubbles that should be
    compacted out or there wasn't much point to doing the fusion.

>
Even with reduced operations per cycle, fusion could still provide
a net energy benefit.

 Here I disagree:: but for a different reason::
 In order for RISC-V to use a 64-bit constant as an operand, it has
to execute either::  AUPIC-LD to an area of memory containing the
64-bit constant, or a 6-7 instruction stream to build the constant
inline. While an ISA that directly supports 64-bit constants in ISA
does not execute any of those.
 Thus, while it may save power seen at the "its my ISA" level it
may save power, but when seem from the perspective of "it is
directly supported in my ISA" it wastes power.

Yes, but "computing" large immediates is obviously less efficient
(except for compression), the computation part is known to be
unnecessary. Fusing a comparison and a branch may be a consequence
of bad ISA design in not properly estimating how much work an
instruction can do (and be encoded in available space) and there
is excess decode overhead with separate instructions, but the
individual operations seem to be doing actual work.
I suspect there can be cases where different microarchitectures
would benefit from different amounts of instruction/operation
complexity such that cracking and/or fusion may be useful even in
an optimally designed generic ISA.
[snip]

- register specifier fields are either source or dest, never both

>
This seems mostly a code density consideration. I think using a
single name for both a source and a destination is not so
horrible, but I am not a hardware guy.

 All we HW guys want is the where ever the field is specified,
it is specified in exactly 1 field in the instruction. So, if
field<a..b> is used to specify Rd in one instruction, there is
no other field<!a..!b> specifies the Rd register. RISC-V blew
this "requirement.

Only with the Compressed extension, I think. The Compressed
extension was somewhat rushed and, in my opinion, philosophically
flawed by being redundant (i.e., every C instruction can be
expanded to a non-C instruction). Things like My 66000's ENTER
provide code density benefits but are contrary to the simplicity
emphasis. Perhaps a Rho (density) extension would have been
better.☺ (The extension letter idea was interesting for an
academic ISA but has been clearly shown to be seriously flawed.)
16-bit instructions could have kept the same register field
placements with masking/truncation for two-register-field
instructions. Even a non-destructive form might be provided by
different masking or bit inversion for the destination. However,
providing three register fields seems to require significant
irregularity in extracting register names. (Another technique
would be using opcode bits for specifying part or all of a
register name. Some special purpose registers or groups of
registers may not be horrible for compiler register allocation,
but such seems rather funky/clunky.)
It is interesting that RISC-V chose to split the immediate field
for store instructions so that source register names would be in
the same place for all (non-C) instructions.
Comparing an ISA design to RISC-V is not exactly the same as
comparing to "best in class".