Path: ...!3.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Robert Finch Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Fri, 20 Sep 2024 01:55:47 -0400 Organization: A noiseless patient Spider Lines: 69 Message-ID: References: <2024Sep11.123824@mips.complang.tuwien.ac.at> <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com> <20240915001153.000029bf@yahoo.com> <20240915154038.0000016e@yahoo.com> <32a15246310ea544570564a6ea100cab@www.novabbs.org> <50cd3ba7c0cbb587a55dd67ae46fc9ce@www.novabbs.org> <7cBGO.169512$_o_3.43954@fx17.iad> <35b8ff2e6baa54c7aa22ec4edf45c3f9@www.novabbs.org> <790b8efbbbb95a6e56ea52bc004f466a@www.novabbs.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 20 Sep 2024 07:55:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="2aa1eff26a0609aa43eb8e70fd231bb3"; logging-data="1032330"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/jPjiTzihWugQLHeUSb+mrx9lB8nz7xYo=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:hJDM4ZfYYd468grdOUYIaY3dBTY= In-Reply-To: <790b8efbbbb95a6e56ea52bc004f466a@www.novabbs.org> Content-Language: en-US Bytes: 4336 On 2024-09-19 4:21 p.m., MitchAlsup1 wrote: > On Thu, 19 Sep 2024 19:12:41 +0000, Brett wrote: > >> MitchAlsup1 wrote: >>> On Thu, 19 Sep 2024 15:07:11 +0000, EricP wrote: >> >> >>>> - 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. > > My 66000 encodes store data register in the same field position as it > encodes "what kind of branch" is being performed, and the same position > as all calculation (and load) results. > > I started doing this in 1982 with Mc88100 ISA, and never found a problem > with the encoding nor in the decoding nor with the pipelining of it. > > Let me be clear, I do not support necessarily damaging a source operand > to fit in another destination as:: > >     ADD     SP,SP,#0x40 > > by specifying SP only once in the instruction. > > So, > >     +------+-----+-----+----------------+ >     | major| Rd  | Rs1 | whatever       | >     +------+-----+-----+----------------+ >     |  BC  | cnd | Rs1 | label  offset  | >     +------+-----+-----+----------------+ >     |  LD  | Rd  | Rb  | displacement   | >     +------+-----+-----+----------------+ >     | ST   | Rs0 | Rb  | displacement   | >     +------+-----+-----+----------------+ > > Is: > a) no burden in encoding > b) no burden in decoding > c) no burden in pipelining > d) no burden in stealing the Store data port late in the pipeline >   {in particular, this saves lots of flip-flops deferring store >    data until after cache hit, TLB hit, and data has arrived at >    cache.} > > I disagree with things like:: > >     +------+-----+-----+----------------+ >     | big OpCode | Rds | whatever       | >     +------+-----+-----+----------------+ > > Where Rds means the specifier is used as both a source and destination. > > Notice in my encoding one can ALWAYS take the register specification > fields and wire them directly into the RF/renamer decoder ports. > You lose this property the other way around. > ??? I am not sure about this. It is in the Q+ ISA. Is the decoder output registered before feeding the renamer?