Path: news.eternal-september.org!eternal-september.org!feeder3.eternal-september.org!news.quux.org!news.nk.ca!rocksolid2!i2pn2.org!.POSTED!not-for-mail
From: mitchalsup@aol.com (MitchAlsup1)
Newsgroups: comp.arch
Subject: Re: Why I've Dropped In
Date: Wed, 11 Jun 2025 23:01:04 +0000
Organization: Rocksolid Light
Message-ID: <474deb60ed00ec42228bbbc8dae7cbe9@www.novabbs.org>
References: <0c857b8347f07f3a0ca61c403d0a8711@www.novabbs.com> <dd6e28b90190e249289add75780b204a@www.novabbs.com> <ec821d1d64555055271e3b72f241d39b@www.novabbs.com> <8addb3f96901904511fc9350c43917ef@www.novabbs.com> <102b5qh$1q55a$2@dont-email.me> <102bj2r$1tbgq$1@dont-email.me> <2025Jun11.185129@mips.complang.tuwien.ac.at> <c338aa4b5775151e87a505e7a9f44f66@www.novabbs.org> <x0n2Q.214093$x6q4.59556@fx46.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Info: i2pn2.org;
	logging-data="116554"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="o5SwNDfMfYu6Mv4wwLiW6e/jbA93UAdzFodw5PEa6eU";
User-Agent: Rocksolid Light
X-Spam-Checker-Version: SpamAssassin 4.0.0
X-Rslight-Posting-User: cb29269328a20fe5719ed6a1c397e21f651bda71
X-Rslight-Site: $2y$10$rPH07bm0.kc7ooUp.N2dgOOsDm/pI3BQzGfA/Y4.79oov0i/z/qVi

On Wed, 11 Jun 2025 22:00:33 +0000, EricP wrote:

> MitchAlsup1 wrote:
>> On Wed, 11 Jun 2025 16:51:29 +0000, Anton Ertl wrote:
>>
>>> Program Counter: Some instruction sets (ARM A32, IIRC PDP-11 and VAX)
>>> have the PC addressed like a GPR, although it clearly is a
>>> special-purpose register.  Most RISCs don't have this, and don't even
>>> have a PC-relative addressing mode or somesuch.  Instead, they use
>>> ABIs where global pointers play a big role.
>>
>> I consider IP as a GPR a mistake--I think the PDP-11 and VAX
>> people figured this out as Alpha did not repeat this mistake.
>> Maybe in a 16-bit machine it makes some sense but once you have
>> 8-wide fetch-decode-execute it no longer does.
>
> It had the advantage of meaningfully reusing some address modes
> rather than having to add new opcode formats:
> PC & autoincrement => immediate value (opcode data type gives size)
> PC & autoincrement deferred => absolute address of data
> PC & B/W/L relative => PC relative address of data
> PC & B/W/L relative deferred => PC relative address of address of data

I can argue that there are other ways to encode each of the above
without using "address modes".

> On the con side, for all PC-relative addressing the offset is
> relative to the incremented PC after *each* operand specifier.
> So two PC-rel references to the same location within a single
> instruction will have different offsets.

This is exactly what made wide VAXs so hard to pipeline. At least
when I use IP as a means to access something in my ISA, the IP used
is the IP of the first word of the instruction {rather than a run-
ning copy of IP}

> (Not a big deal but yet another thing one has to deal with in
> Decode and carry with you in any uOps.)

It becomes quadratically harder as instruction width increases,
cubically if the accessed operands have variable widths.