From Newsgroup: comp.arch

quadi <quadibloc@ca.invalid> writes:

while most modern architectures only have _one_
field to specify a register the contents of which are to be added to the >displacement.

Most? Only the MIPS descendents come to mind. Most of these
architectures have been cancelled (MIPS, Alpha, Nios2), only RISC-V
survives.

Other than that, most architectures support at least [reg+reg]
addressing. I think that adding that addressing mode to the load
instructions of these architectures would have been a good idea while
still staying within the 2R,1W register access limit that the
architects seem to have observed. A disadvantage of treating loads
differently from stores would be that the decoding and the data path
would be different. The benefit would be that for a loop like

for (i=0; i<n; i++)
a[i]=b[i]+c[i];

the loop body could look as follows:

loop:
ld r1,(r2+r3)
ld r4,(r2+r5)
add r6=r4+r1
sd r6,(r2)
add r2=r2+8
blt r2,r7,loop

while typical RISC-V code has two additional adds in the loop because
it has to update the cursors into b and c on every iteration.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to Thomas Koenig <tkoenig@netcologne.de>:

Not goals exactly, but constraints. Remember, S/360 had no memory
address relocation hardware such as a hardware base register or paging.
The addresses in a program were real memory addresses. Thus address say
1,000 in a program was real memory address 1,000. So absent base
registers, you couldn't have more than one program in memory at the same
time, since program1's address 1,000 would have referred to the same
real memory address as program2's address 1,000.

Small quibble: This depends on what your loader does. IIRC
(I would have to re-read John Levine's book on linkers and loaders

You rang? I don't think my book said much about it, but on OS/360 and its descendants, load modules are relocatable and when they're loaded into memory, which they call program fetch, the addresses in memory, which they call address constants, are relocated to wherever the module is actually loaded. If you have three copies of a program running at once, they'd be loaded and relocated to three separate places.

The main motivation for base+displacement was that they both wanted an architecture with large flat addresses, and they needed compact instructions since memory was expensive and the small models would have only 8K or 16K. Each address in an instruction was 16 bits, but could address the full 24 bit (later 31 bit) address space without segment kludgery. You needed a BALR or similar at the start of each routine to set up a base register, but that was only two bytes
so it was a good tradeoff. The only thing I would have done differently would have been to make branches PC relative so code didn't need a base register, something later added in S/390.

Sort of reading between the lines, I get the impression that they thought that since all the addresses were relative to base registers, they could get the effect of dynamic relocation by changing the base registers. That didn't work both because there's no straightforward way to know which registers are being used as base registers, and because every real program also has the above mentioned address constants in memory.

I think I heard of a version of APL\360 which by very disciplined programming could swap a workspace out and swap it back in somewhere else, and update
the register pointing to it, but that was far from a general solution.

As time went on and memory became cheaper, the 4K displacements became more annoying, so on S/390 they added 16 and 32 bit relative branches, which were really 17 and 33 since they were shifted a bit left since instructions are
all halfword aligned, and a bunch of instructions with 16 bit immmediate operands. On z they added 32 bit immediates and 20 bit signed displacements. --
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

According to Scott Lurndal <slp53@pacbell.net>:

Index registers were considered a good idea back when they were originally >>introduced. It meant you could redirect an instruction to point somewhere >>else without modifying the instruction in memory.

The earliest incarnations of such were often not 'registers' per-se, but >rather reserved locations in memory (c.f. PDP-8 'TAD I'). The Electrodata >220 had a 'B' register - the predecessor Electrodata 205 was the first >commercial computer to offer an Index register (with the idea inspired
by the Manchester Mark I).

I believe the 205 was introduced in 1954, the same year as the IBM 704
which had three real index registers.

By that time the idea was well known. Once computers had reliable
random access core memory rather flaky Williams tubes or rotating
drums like the 205 had, it was a clear win to to do data indexing
without extra code to patch the indexed address into the instruction.

I still have not been able to find any explanation of why the
sign-magnitude 704 did two's complement subtractive indexing. There
are plenty of guesses, so we don't need any more, but I've looked hard
and found no paper trail.
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch


anton@mips.complang.tuwien.ac.at (Anton Ertl) posted:

quadi <quadibloc@ca.invalid> writes:

while most modern architectures only have _one_
field to specify a register the contents of which are to be added to the >displacement.

Most? Only the MIPS descendents come to mind. Most of these
architectures have been cancelled (MIPS, Alpha, Nios2), only RISC-V
survives.

Other than that, most architectures support at least [reg+reg]
addressing. I think that adding that addressing mode to the load instructions of these architectures would have been a good idea while
still staying within the 2R,1W register access limit that the
architects seem to have observed. A disadvantage of treating loads differently from stores would be that the decoding and the data path
would be different. The benefit would be that for a loop like

for (i=0; i<n; i++)
a[i]=b[i]+c[i];

the loop body could look as follows:

loop:
ld r1,(r2+r3)
ld r4,(r2+r5)
add r6=r4+r1
sd r6,(r2)
add r2=r2+8
blt r2,r7,loop

With scaled indexing::

loop:
LDD R1,[Rb,Ri<<3]
LDD R4,[Rc,Ri<<3]
ADD R6,R4,R1
STD R6,[Ra,Ri<<3]
ADD Ri,Ri,#1
BLT Ri,Rn,loop

without ay cursoring...

while typical RISC-V code has two additional adds in the loop because
it has to update the cursors into b and c on every iteration.

- anton

--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

On 5/2/2026 11:21 AM, John Levine wrote:

According to Thomas Koenig <tkoenig@netcologne.de>:

Not goals exactly, but constraints. Remember, S/360 had no memory
address relocation hardware such as a hardware base register or paging.
The addresses in a program were real memory addresses. Thus address say >>> 1,000 in a program was real memory address 1,000. So absent base
registers, you couldn't have more than one program in memory at the same >>> time, since program1's address 1,000 would have referred to the same
real memory address as program2's address 1,000.

Small quibble: This depends on what your loader does. IIRC
(I would have to re-read John Levine's book on linkers and loaders

You rang? I don't think my book said much about it, but on OS/360 and its descendants, load modules are relocatable and when they're loaded into memory,
which they call program fetch, the addresses in memory, which they call address
constants, are relocated to wherever the module is actually loaded. If you have
three copies of a program running at once, they'd be loaded and relocated to three separate places.

The main motivation for base+displacement was that they both wanted an architecture with large flat addresses, and they needed compact instructions since memory was expensive and the small models would have only 8K or 16K.

Thank you. That is another constraint that John's design doesn't have
to deal with, which should, but apparently doesn't effect his thinking.
--
- Stephen Fuld
(e-mail address disguised to prevent spam)
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 02 May 2026 12:31:04 -0700, Stephen Fuld wrote:

On 5/2/2026 11:21 AM, John Levine wrote:

The main motivation for base+displacement was that they both wanted an
architecture with large flat addresses, and they needed compact
instructions since memory was expensive and the small models would have
only 8K or 16K.

Thank you. That is another constraint that John's design doesn't have
to deal with, which should, but apparently doesn't effect his thinking.

I want an architecture with large flat addresses.

It's true, though, that the original System/360 had an _address space_ of
16 megabytes, and while you could get 16 megabytes of RAM for some high-
end models, it had to be slow 10 microsecond memory, the regular 2
microsecond memory for those models was only available in smaller sizes...

and today, a computer will often have 16 *gigabytes* of memory.

So since we have so much memory, what's the problem with using 64-bit addresses in every memory-reference instruction?

I haven't noticed anybody actually doing that. Not x86, not SPARC, not PowerPC, not Itanium, not ARM. Maybe I haven't been looking?

I figured that if we had more memory, that meant we were writing bigger programs - or programs that used more data, and so we had more memory to
*use* but still no memory to *waste*.

However, I'm not _dead_ set against larger displacements. IBM's z/ Architecture, the 64-bit development of the venerable 360 architecture,
offers a set of 48-bit instructions which use 20-bit displacements instead
of 12-bit displacements. I have included 20-bit displacements as an option within Concertina II, since I took this as "evidence" that 20-bit displacements were genuinely - or at least _possibly_ - useful. Anything *short* of a 64-bit displacement (well, maybe 36 bits or 48 bits, since physical memory is still less than what a 64-bit displacement covers)
still needs a base register, so that includes 32 bits.

I haven't seen ISAs out there that use displacements larger than 20 bits
to any great extent, although absolute addressing without a base register
is sometimes offered in some architectures... as an exotic option. Such instructions, for example, may allow a computer to perform some exotic housekeeping tasks prior to loading up the base registers.

If I don't already have absolute addressing in Concertina II at this time,
I probably will get around to adding it - but it will _not_ be intended as
the main addressing mode to be used for writing everyday real programs. It will be a special-purpose addressing mode, intended to make certain highly specific tasks easier to accomplish.

John Savard
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Sat, 02 May 2026 21:29:40 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

quadi <quadibloc@ca.invalid> posted:

...
and today, a computer will often have 16 *gigabytes* of memory.

Home systems now routinely have 64GB and some as large as 256GB
{pre AI consuming all the large DRAM DIMMs.}

Many home systems can *support* 64GB - few actually have that much.
The vast majority have 16GB or less.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

George Neuner wrote:

On Sat, 02 May 2026 21:29:40 GMT, MitchAlsup <user5857@newsgrouper.org.invalid> wrote:

quadi <quadibloc@ca.invalid> posted:

...
and today, a computer will often have 16 *gigabytes* of memory.

Home systems now routinely have 64GB and some as large as 256GB
{pre AI consuming all the large DRAM DIMMs.}

Many home systems can *support* 64GB - few actually have that much.
The vast majority have 16GB or less.

Every single one of my home laptops since at least 2010 or so have had
exactly 32 GB. Initially, that was a lot, currently I'm occasionally
feeling the squeeze.

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

On Tue, 5 May 2026 10:12:13 +0200, Terje Mathisen
<terje.mathisen@tmsw.no> wrote:

George Neuner wrote:

On Sat, 02 May 2026 21:29:40 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

quadi <quadibloc@ca.invalid> posted:

...
and today, a computer will often have 16 *gigabytes* of memory.

Home systems now routinely have 64GB and some as large as 256GB
{pre AI consuming all the large DRAM DIMMs.}

Many home systems can *support* 64GB - few actually have that much.
The vast majority have 16GB or less.

Every single one of my home laptops since at least 2010 or so have had >exactly 32 GB. Initially, that was a lot, currently I'm occasionally
feeling the squeeze.

Terje

And no doubt you paid through your nose for them. Most people will
not spend that much. Look at what systems are selling in droves:
mostly 8GB..16GB systems and even still 4GB at the low end.

32GB would have been considered a "high end" home system just a few
years ago - it's still considered "high middle".

I don't consider "gamers" to be entirely sane - and AI bullshit
notwithstanding - most other users have little or no need for that
much memory.
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: comp.arch

George Neuner wrote:

On Tue, 5 May 2026 10:12:13 +0200, Terje Mathisen
<terje.mathisen@tmsw.no> wrote:

George Neuner wrote:

On Sat, 02 May 2026 21:29:40 GMT, MitchAlsup
<user5857@newsgrouper.org.invalid> wrote:

quadi <quadibloc@ca.invalid> posted:

...
and today, a computer will often have 16 *gigabytes* of memory.

Home systems now routinely have 64GB and some as large as 256GB
{pre AI consuming all the large DRAM DIMMs.}

Many home systems can *support* 64GB - few actually have that much.
The vast majority have 16GB or less.

Every single one of my home laptops since at least 2010 or so have had
exactly 32 GB. Initially, that was a lot, currently I'm occasionally
feeling the squeeze.

Terje

And no doubt you paid through your nose for them. Most people will
not spend that much. Look at what systems are selling in droves:
mostly 8GB..16GB systems and even still 4GB at the low end.

32GB would have been considered a "high end" home system just a few
years ago - it's still considered "high middle".

I don't consider "gamers" to be entirely sane - and AI bullshit notwithstanding - most other users have little or no need for that
much memory.

I haven't really gamed since I helped write Quake (30+ years ago), my
PCs are there to process mapping data, in particular fairly dense lidar clouds.

I currently have 70 TB of compressed laz files on my home NAS box.

I also haven't personally paid for any machine with more than 8 GB of
RAM (7-8 year old Surface Pro).

Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
--- Synchronet 3.21f-Linux NewsLink 1.2