Deutsch   English   Français   Italiano  
<vcht39$mbru$1@dont-email.me>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Brett <ggtgp@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 19 Sep 2024 19:12:41 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 50
Message-ID: <vcht39$mbru$1@dont-email.me>
References: <vaqgtl$3526$1@dont-email.me>
 <p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
 <2024Sep10.101932@mips.complang.tuwien.ac.at>
 <ygn8qvztf16.fsf@y.z>
 <2024Sep11.123824@mips.complang.tuwien.ac.at>
 <vbsoro$3ol1a$1@dont-email.me>
 <867cbhgozo.fsf@linuxsc.com>
 <20240912142948.00002757@yahoo.com>
 <vbuu5n$9tue$1@dont-email.me>
 <20240915001153.000029bf@yahoo.com>
 <vc6jbk$5v9f$1@paganini.bofh.team>
 <20240915154038.0000016e@yahoo.com>
 <vc70sl$285g2$4@dont-email.me>
 <vc73bl$28v0v$1@dont-email.me>
 <OvEFO.70694$EEm7.38286@fx16.iad>
 <32a15246310ea544570564a6ea100cab@www.novabbs.org>
 <vc7a6h$2afrl$2@dont-email.me>
 <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org>
 <vc8qic$2od19$1@dont-email.me>
 <fCXFO.4617$9Rk4.4393@fx37.iad>
 <vcb730$3ci7o$1@dont-email.me>
 <7cBGO.169512$_o_3.43954@fx17.iad>
 <vcffub$77jk$1@dont-email.me>
 <n7XGO.89096$15a6.87061@fx12.iad>
 <35b8ff2e6baa54c7aa22ec4edf45c3f9@www.novabbs.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 19 Sep 2024 21:12:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f5096f7998b9f29573d3e22405ab7db3";
	logging-data="733054"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19vUx4hEKeiXVA1gxsNIVQu"
User-Agent: NewsTap/5.5 (iPad)
Cancel-Lock: sha1:Im3gJ9PT2VZ9Gb9WhtGjQEoPCY4=
	sha1:xUJ2rE55yYkKArEhYztt5WT2ZGo=
Bytes: 3883

MitchAlsup1 <mitchalsup@aol.com> wrote:
> On Thu, 19 Sep 2024 15:07:11 +0000, EricP wrote:
> 
>> Brett wrote:
>>> EricP <ThatWouldBeTelling@thevillage.com> wrote:
>>> 
>>> They claim 5 cycles, should be six, five for the multiply and one more
>>> for
>>> the second result, unless the next instruction does not need a write
>>> port,
>>> and does not use the result. You can get a throughput of 5 cycles with
>>> smart coding, but that rarely happens without effort.
>> 
>> That article is ignoring multiplier pipelining.
>> 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.
>> And if it does fuse them then the internal uArch cost is the same as if
>> you had designed it optimally from the start, except now you have
>> to pay for a fuser.
> 
> You failed to recognize the critical part of my comment on this::
> 
> When the IMUL function unit sees MULL and MULH back to back AND
> when both operands are the same for both instructions; it KNOWS
> that the second multiply has the same result as the first and
> thereby that the second multiply can be suppressed and the first
> multiply used twice. {{In pure CMOS, if you drop the same operands
> twice into the multiplier tree, the multiplier tree burns no power
> in any event, just the operand delivery power.}}
> 
> You may call this fusion, but it is the very lowest level of it
> and was not called such when first used.
> 
>> <sound of soap box being dragged out>


>> - register specifier fields are either source or dest, never both
>
> I happen to be wishywashy on this


This is deeply interesting, can you expound on why it is fine a register
field can be shared by loads and stores, and sometimes both like x86.

Classic RISC says the loads are critical, but no one is one wide today, so
stores matter for deconfliction…. And does stuff just fall out right to
allow both?