From Newsgroup: alt.folklore.computers

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

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
scientific computing the way some folks here do, I have not gotten the >>impression that a lot of customers were commonly running up against the
4 GB limit in the early '90s;

Mainframes certainly had more than 4GB. In 1990 the ES/9000 had more
than 4GB of "expanded" memory and by 1994 there was 8GB of main memory,
using a variety of mapping and segmentation kludges to address from a
32 bit architecture.

Even simple data movement (e.g. optimized memcpy) will require half
the instructions on a 64-bit architecture.

Er, maybe. There were plenty of 32 bit systems with 64 bit memory.
I would expect that systems with string move instructions would
take advantage of the underlying hardware.
--
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.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Mon, 4 Aug 2025 18:17:54 -0000 (UTC)
John Levine <johnl@taugh.com> wrote:

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

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
scientific computing the way some folks here do, I have not gotten
the impression that a lot of customers were commonly running up
against the 4 GB limit in the early '90s;

Mainframes certainly had more than 4GB. In 1990 the ES/9000 had more
than 4GB of "expanded" memory and by 1994 there was 8GB of main
memory, using a variety of mapping and segmentation kludges to
address from a 32 bit architecture.

Even simple data movement (e.g. optimized memcpy) will require half
the instructions on a 64-bit architecture.

Er, maybe. There were plenty of 32 bit systems with 64 bit memory.
I would expect that systems with string move instructions would
take advantage of the underlying hardware.

Also there existed possibility of using non-GPR registers.
Didn't majority 32-bit RISC machines with general-purpose ambitions
have 64-bit FP registers?
Plus LTM/STM. I think, ARM was not the only one that had them.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

John Levine <johnl@taugh.com> schrieb:

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

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
scientific computing the way some folks here do, I have not gotten the >>>impression that a lot of customers were commonly running up against the
4 GB limit in the early '90s;

Mainframes certainly had more than 4GB. In 1990 the ES/9000 had more
than 4GB of "expanded" memory and by 1994 there was 8GB of main memory,
using a variety of mapping and segmentation kludges to address from a
32 bit architecture.

#ifdef PEDANTIC
Actually, 31 bits.
#endif
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

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

John Levine <johnl@taugh.com> schrieb:

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

Stefan Monnier <monnier@iro.umontreal.ca> wrote:
scientific computing the way some folks here do, I have not gotten the >>>>impression that a lot of customers were commonly running up against the >>>>4 GB limit in the early '90s;

Mainframes certainly had more than 4GB. In 1990 the ES/9000 had more
than 4GB of "expanded" memory and by 1994 there was 8GB of main memory,
using a variety of mapping and segmentation kludges to address from a
32 bit architecture.

#ifdef PEDANTIC
Actually, 31 bits.
#endif

It's a 32 bit architecture with 31 bit addressing, kludgily extended
from 24 bit addressing in the 1970s.

R's,
John
--
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.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On Mon, 4 Aug 2025 22:17:24 +0300, Michael S wrote:

Didn't majority 32-bit RISC machines with general-purpose ambitions have 64-bit FP registers?

A common rCLextendedrCY floating-point format for IEEE-754-compatible use was 80 bits. E.g. ApplerCOs 1980s-vintage SANE numerics library used this as its internal format for all computations. Motorola implemented a 96-bit format
in its 68881-and-following hardware floating-point processors, but
actually only 80 of those bits were used -- the rest was just alignment padding.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

John Levine <johnl@taugh.com> writes:

It's a 32 bit architecture with 31 bit addressing, kludgily extended
from 24 bit addressing in the 1970s.

2nd half 70s kludge, with 370s that could have 64mbytes of real memory
with only 24bit addressing ... the virtual memory page table entry (PTE)
had 16bits with 2 "unused bits" ... 12bit page number (12bit 4kbyte
pages, 24bits) ... and defined the two unused bits to prepend to the
page number ... making 14bit page number ... for 26bits (instructions
were still be 24bit, but virtual memory used to translate to 26bits real addressing).

original 360 I/O had only 24bit addressing, adding virtual memory (to
all 370s) added IDALs, the CCW was still 24bit but were still being
built by applications running in virtual memory ... and (effectively)
assumed any large storage locations consisting of one contiguous
area. Moving to virtual memory, I/O large "contiguous" area was now
borken into page size chunks in non-contiguous areas. Translating
"virtual" I/O program, the original virtual CCW ... would be converted
to CCW with real addresses and flagged as IDAL ... where the CCW pointed
to IDAL list of real addresses ... that were 32 bit words ... (31 bits specifying real address) for each (possibly non-contiguous) real page
involved.
--
virtualization experience starting Jan1968, online at home since Mar1970
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

scott@slp53.sl.home (Scott Lurndal) writes:

That said, Unix generally defined -1 as the return value for all
other system calls, and code that checked for "< 0" instead of
-1 when calling a standard library function or system call was fundamentally >broken.

That may be the interface of the C system call wrapper, along with
errno, but at the actual system call level, the error is indicated in
an architecture-specific way, and the ones I have looked at before
today use the sign of the result register or the carry flag. On those architectures, where the sign is used, mmap(2) cannot return negative addresses, or must have a special wrapper.

Let's look at what the system call wrappers do on RV64G(C) (which has
no carry flag). For read(2) the wrapper contains:

0x3ff7f173be <read+20>: ecall
0x3ff7f173c2 <read+24>: lui a5,0xfffff
0x3ff7f173c4 <read+26>: mv s0,a0
0x3ff7f173c6 <read+28>: bltu a5,a0,0x3ff7f1740e <read+100>

For dup(2) the wrapper contains:

0x3ff7e7fe9a <dup+2>: ecall
0x3ff7e7fe9e <dup+6>: lui a7,0xfffff
0x3ff7e7fea0 <dup+8>: bltu a7,a0,0x3ff7e7fea6 <dup+14>

and for mmap(2):

0x3ff7e86b6e <mmap64+12>: ecall
0x3ff7e86b72 <mmap64+16>: lui a5,0xfffff
0x3ff7e86b74 <mmap64+18>: bltu a5,a0,0x3ff7e86b8c <mmap64+42>

So instead of checking for the sign flag, on RV64G the wrapper checks
if the result is >0xfffff00000000000. This costs one instruction more
than just checking the sign flag, and allows to almost double the
number of bytes read(2) can read in one call, the number of file ids
that cn be returned by dup(2), and the address range returnable by
mmap(2). Will we ever see processes that need more than 8EB? Maybe
not, but the designers of the RV64G(C) ABI obviously did not want to
be the ones that are quoted as saying "8EB should be enough for
anyone":-).

Followups to comp.arch

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

From Newsgroup: alt.folklore.computers

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

I would have liked to install 64-bit Debian (IIRC I initially ran
32-bit Debian on the Athlon 64), but they were not ready at the time,
and still busily working on their multi-arch (IIRC) plans, so
eventually I decided to go with Fedora Core 1, which just implemented
/lib and /lib64 and was there first.

For some reason I switched to Gentoo relatively soon after
(/etc/hostname from 2005-02-20, and IIRC Debian still had not finished >hammering out multi-arch at that time), before finally settling in >Debian-land several years later.

Reading some more, Debian 4.0 (Etch), released 8 April 2007, was the
first Debian with official AMD64 support.

Multiarch was introduced in Debian 7 (Wheezy), released 4 May 2013.

So Multiarch took much longer than they had originally expected, and
they apparently settled for the lib64 approach for Debian 4-6.

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

From Newsgroup: alt.folklore.computers

Reading some more, Debian 4.0 (Etch), released 8 April 2007, was the
first Debian with official AMD64 support.

Indeed, I misremembered: I used Debian's i386 port on my 2003 AMD64
machine.
It didn't have enough RAM to justify the bother of distro hopping. EfOe


Stefan
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

On 9/1/2025 11:15 AM, Stefan Monnier wrote:

Reading some more, Debian 4.0 (Etch), released 8 April 2007, was the
first Debian with official AMD64 support.

Indeed, I misremembered: I used Debian's i386 port on my 2003 AMD64
machine.
It didn't have enough RAM to justify the bother of distro hopping. EfOe

My first AMD64 machine also ended up mostly running 32-bit OS's, but
more because initially:
It was unstable if running 64-bit Linux;
It was also not very stable initially with XP-X64;
Driver support for XP-X64, initially, was almost non existent.
So, ended up mostly running 32-bit WinXP on the thing.

Though, after the initial weak results, on my next machine I had a
better experience and IIRC had it set up to dual boot XP-X64 and Fedora,
by that point stuff was stable and XP-X64 had drivers for stuff. I stuck
with XP-X64 mostly as Vista was kinda trash (until some years later
jumping to Win7, and now Win10).


Well, and (at least in these years) Linux still had serious issues with
driver compatibility, so you can use the OS but typically with no 3D acceleration or sound (and Mesa-GL in SW mode is horribly slow).

At least Ethernet tended to work as most MOBOs had settled on the
RTL8139 or similar (well, until MOBOs started having Gigabit Ethernet,
and suddenly Ethernet no longer worked in Linux for a while, ...).

Well, Linux land often failing to provide a great experience, not so
much because of UI (and, I actually like using the Bash shell for
stuff), but because of ever-present hardware support issues (so, can't
usually end up running it as the main OS as much of the HW often didn't
work).

...

Stefan

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.folklore.computers

Stefan Monnier <monnier@iro.umontreal.ca> writes:

It didn't have enough RAM to justify

My Athlon 64 only had 1GB of RAM, so an IA-32 distribution would have
done nicely for it, but I wanted to be able to build and run AMD64
software.

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