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

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: Taughannock Networks (3:633/280.2@fidonet)

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.


--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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.

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: Taughannock Networks (3:633/280.2@fidonet)

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 “extended” floating-point format for IEEE-754-compatible use was 80 bits. E.g. Apple’s 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.

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: A noiseless patient Spider (3:633/280.2@fidonet)

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

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: Wheeler&Wheeler (3:633/280.2@fidonet)

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>

--- MBSE BBS v1.1.2 (Linux-x86_64)
* Origin: Institut fuer Computersprachen, Technische Uni (3:633/280.2@fidonet)