On 10/19/2021 12:26 PM, Stephen Fuld wrote:
> On 10/16/2021 1:04 PM, Ivan Godard wrote:
>> On 10/16/2021 12:20 PM, Stephen Fuld wrote:
>>> On 10/16/2021 11:44 AM, Ivan Godard wrote:
>>>> On 10/16/2021 9:07 AM, Anton Ertl wrote:
>>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>> [bounds checking]
>>>>>> There are languages where the necessary info is provided, Ada
>>>>>> and Fortran among them.  However, that there is a rather large
>>>>>> overhead in code size and, more importantly, execution time.
>>>>>
>>>>> Please support your claim with empirical results.
>>>>>
>>>>>> Compilers need to become better at moving
>>>>>> checking code out of loops.
>>>>>
>>>>> Again, support needed.  My impression is that the Cousots solved this
>>>>> problem pretty well in the 1970, and for the common case their
>>>>> solution is good enough.  And it's not clear that much can be done for
>>>>> the other cases.
>>>>>
>>>>>> Signed overruns - the very topic we are discussing here.  Integer
>>>>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>>>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>>>
>>>>> Consider:
>>>>>
>>>>> signed char a=127;
>>>>> signed char b=127;
>>>>> signed char c;
>>>>> c=a+b;
>>>>>
>>>>> The addition is defined in C.  Maybe the narrowing of the result in
>>>>> the assignment is undefined, C standards lawyers will know.
>>>>>
>>>>> But of course, the major question is who wants this?  Who uses -ftrapv
>>>>> on MIPS and Alpha which have such instructions (for 32 bits and 64
>>>>> bits, relevant for their I32LP64 C).
>>>>>
>>>>>> Use after free - much more difficult.  It might be possible to
>>>>>> have a hardware list of "poisoned" address ranges from which it is
>>>>>> not permitted to load.  Very expensive (comparable to
>>>>>> cache) and would probably cache only the most recently freed
>>>>>> memory blocks.  Not sure if this is worth it.
>>>>>
>>>>> If you have NaT bits associated with the memory, you could fill the
>>>>> free()d memory with NaTs.
>>>>
>>>> I would love to have NaT bits (NaR in our terminology) associated
>>>> with memory. It's certainly doable, but not economically feasible
>>>> IMO, unless you are Samsung.
>>>
>>> I was thinking about (ab)using a modification of your mechanism that
>>> allows reading zeros when you load from uninitialized memory, but I
>>> suspect the overhead might be way to high.
>>
>> We looked at having uninit read as NaR. If real Samsung had NaR bits
>> then you could write a speculative NaR and later discard it
>> harmlessly; without Samsung we have to fault a NaR store, which limits
>> the degree of performance gain available from speculation. With NaR
>> uninits but no Samsung we can nanny the programmer, but the common
>> zero init (as nannied) becomes explicit, lowering performance. Absent
>> Samsung, we decided that the reliability gain from nannying wasn't as
>> good as the performance gain from zero; YMMV. Might well have gone the
>> other way had Samsung been aboard.
>
> Obviously I am missing something, but I thought your "read zeros"
> mechanism used the PLB, not anything in the RAM itself.  So I was
> suggesting some enhancement of the range protection in the PLB, but as I
> said, I fear it would entail too much overhead.

Not the PLB, which handles permissions, but the TLB, which does
translation and can tell whether an address for which you have
permission (PLB) is mapped to physical DRAM (TLB) or should be assumed
to be zero without doing a mapping first..

On 19/10/2021 18:45, Tim Rentsch wrote:
> EricP <ThatWouldBeTelling@thevillage.com> writes:
>
>> Tim Rentsch wrote:
>>
>>> Michael S <already5chosen@yahoo.com> writes:
>>>
>>>>> [..sarcastic comments regarding signed overflow..]
>>>>
>>>> Don't be silly.
>>>> The best solution does not involve magic.
>>>> Something like that will do:
>>>>
>>>> Signed overflow is implementation-defined, but in constrained way.
>>>> Possible options are
>>>> 1. two-complement wrap-around
>>>> 2. trap
>>>> 3. saturation
>>>> 4. one-complement wrap-around, if there exist a member of
>>>> committee that care about it
>>>>
>>>> Implementation has to specify the chosen option clearly in
>>>> documentation. It is allowed to select an option with special
>>>> flag. It is not allowed to make option dependent on optimization
>>>> settings. If the chosen option is trap and overflow happens in
>>>> intermediate result of complex expression, but not in the final
>>>> result than it's it's legal for trap to be intermittent and
>>>> dependent on ether optimization level or phase of the moon, but
>>>> not both.
>>>
>>> My sense is this idea is not much better than how things are
>>> now. I would like to see the decision be under control of
>>> the source code, perhaps by means of a #pragma:
>>>
>>> #pragma STDC SIGNED_OVERFLOW WRAP
>>> #pragma STDC SIGNED_OVERFLOW TRAP
>>> #pragma STDC SIGNED_OVERFLOW SATURATE
>>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>>> (..others?..)
>>>
>>> If it's important, implementations might be allowed not to
>>> implement some or all of these choices; but if they don't then
>>> they must at least check the #pragma line for legality and fail
>>> the compilation if they cannot accommodate the choice indicated
>>> (or if the #pragma STDC doesn't scan for some reason).
>>
>> Gcc C already has the compiler switch -ftrapv to enable signed integer
>> overflow checks (operators are implemented as subroutine calls).
>>
>> The problem with such pragmas in C is the same as compiler switches:
>> they cause many false positives (overflow traps) because they are too
>> much of a blunt object. As a consequence people just turn them off.
>>
>> A number of studies of real world code have shown that it is a
>> mixture of signed and unsigned, checked and unchecked assumptions
>> *often within a single expression*.
>>
>> E.g. these folks tap into clang's front end to inject checks into
>> code.
>>
>> Understanding Integer Overflow in C/C++, 2015
>> https://wdtz.org/files/tosem15.pdf
>>
>> Consider a hypothetical line from a codec:
>>
>> signal = signal + impulse[i + j];
>>
>> In this expression, i+j are signed integers and should be added using
>> checked arithmetic, the array index then checked against array bounds,
>> the array element address addition calculated using unsigned modulo
>> arithmetic, and signal value added using saturating arithmetic.
>>
>> Note also that some unsigned wrap arounds are bugs, some not.
>> It depends on the programmers intent.
>>
>> This is why the VAX with it PSW global flag enabling overflow detect
>> had problems - real code would have to keep switching it on and off,
>> which would cause a large overhead so they just left it on for Fortran
>> or Ada and lived with occasional false overflow traps. Which is why
>> Alpha has separate instructions for Add and AddTrapOverflow.
>>
>> The only mechanism I can think of that can handle that kind of
>> flexibility smoothly would be based on multiple language data types,
>> and an ISA with separate instructions for each operation on each type.
>
> Just a few comments. I didn't see how to intersperse these
> with what you said, so I'm putting everything here.
>
> One, my comments were only about providing an alternative to
> undefined behavior on signed integer arithmetic. They had
> nothing to do with checking index bounds, incorrect use of
> defined behavior on unsigned operands, bugs arising from
> implementation-dependent behavior or integer promotions, etc.
> All of these are outside the realm of what I was addressing.
>
> Two, having something like the #pragma ability outlined above has
> some advantages over things like -ftrapv. First, being defined
> in the C standard, it's the same everywhere, with no need to hunt
> around for compiler-dependent options. Second, because it is
> expressed in C, it stays with the code, rather than having to
> live outside the code in something like a makefile.
>
> Three, unlike compiler options such as -ftrapv, the #pragma
> mechanism is not all or nothing for a whole translation unit.
> A single .c file can have multiple overflow #pragma's, changing
> settings through the TU. Furthermore there is no reason they
> can't be syntax sensitive, limiting the domains of application
> to a braced block or a parenthesized expression. Combined with
> calls to _Pragma operators, the details can be abstracted
> inside macro definitions. Taking your example
>
> signal = signal + impulse[i + j];
>
> this might be written as
>
> signal = SATURATE( signal + impulse[ TRAP(i + j)] );
>
> where SATURATE and TRAP have been previously defined
>
> #define TRAP(e) ( \
> _Pragma ("STDC SIGNED_OVERFLOW TRAP") e \
> )
>
> #define SATURATE(e) ( \
> _Pragma ("STDC SIGNED_OVERFLOW SATURATE") e \
> )
>
> Again, I'm not suggesting that using this approach for what
> happens on signed overflows solves all the world's problems.
> But I do think it is both more convenient and more flexible
> than compiler options like -ftrapv, and needs only modest
> changes to the C standard to enable it.
>

Just a small note here - gcc's "-ftrapv" and "-fwrapv" options can be
controlled using pragmas. So "#pragma STDC SIGNED_OVERFLOW WRAP" can be
achieved today with "#pragma GCC optimize "-fwrapv", and similarly (with
its limitations) with "-ftrapv".

Other than that, I agree with Tim's points - and of course I agree that
a standardised pragma would be better than a gcc-specific pragma.

On Tuesday, October 19, 2021 at 10:49:15 PM UTC+3, Stephen Fuld wrote:
> On 10/11/2021 10:13 AM, George Neuner wrote:
> > On Sun, 10 Oct 2021 16:31:21 -0700, Stephen Fuld
> > <sf...@alumni.cmu.edu.invalid> wrote:
> >
> >> I don't think the question of whether 64 bits is adequate (it is), but
> >> for how long into the future will it be adequate, and secondarily, when
> >> it does become inadequate, how big a change, hardware and software, will
> >> be required to deal with it?
> >
> > When the time comes that one computer can't run all your programs, buy
> > another one.
> >
> > Address space won't be a problem until 64 bits is too small for a
> > /single/ program. "Big data" notwithstanding, I don't expect to see
> > programs of that size any time in this century.
>
> You may be right. But historically, desired address space has grown by
> about 1 bit every 2-3 years. Currently we are probably in the mid
> forties bits, so if the trend continues then we will exceed 64 before
> 2099. But others have said the trend is slowing.
>

I think, the highest memory capacity of single-system-image computers is stuck at 24TB for 7 or 8 years.

> Of course, time will tell.
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Stephen Fuld [2021-10-19 12:49:11] wrote:
> On 10/11/2021 10:13 AM, George Neuner wrote:
>> Address space won't be a problem until 64 bits is too small for a
>> /single/ program. "Big data" notwithstanding, I don't expect to see
>> programs of that size any time in this century.
> You may be right. But historically, desired address space has grown by
> about 1 bit every 2-3 years.

George was speaking about the segment of the market *not* concerned with
"big data". While this is a very vague definition of "segment of the
market", I'd tend to agree with him that it appears to have grown a lot
slower than "1 bit every 2-3 years".

At least, I have the feeling that the amount of RAM on "average laptops"
has not even quadrupled over the last 10 years.

> Currently we are probably in the mid forties bits, so if the trend
> continues then we will exceed 64 before 2099.

But that's for "big data". For desktops we're barely reaching the
fortieth bit at the top end of the market, AFAICT. So if that grows at
2bits every 10 years that puts the 64bit barrier well into the
XXII century.

Stefan "typing this on a 3GB laptop ;-)"

On 10/19/2021 1:47 PM, Ivan Godard wrote:
> On 10/19/2021 12:26 PM, Stephen Fuld wrote:
>> On 10/16/2021 1:04 PM, Ivan Godard wrote:
>>> On 10/16/2021 12:20 PM, Stephen Fuld wrote:
>>>> On 10/16/2021 11:44 AM, Ivan Godard wrote:
>>>>> On 10/16/2021 9:07 AM, Anton Ertl wrote:
>>>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>>> [bounds checking]
>>>>>>> There are languages where the necessary info is provided, Ada
>>>>>>> and Fortran among them.  However, that there is a rather large
>>>>>>> overhead in code size and, more importantly, execution time.
>>>>>>
>>>>>> Please support your claim with empirical results.
>>>>>>
>>>>>>> Compilers need to become better at moving
>>>>>>> checking code out of loops.
>>>>>>
>>>>>> Again, support needed.  My impression is that the Cousots solved this
>>>>>> problem pretty well in the 1970, and for the common case their
>>>>>> solution is good enough.  And it's not clear that much can be done
>>>>>> for
>>>>>> the other cases.
>>>>>>
>>>>>>> Signed overruns - the very topic we are discussing here.  Integer
>>>>>>> arithmetic could (optionally) trap on a 64-bit overflow, a 32-bit
>>>>>>> overflow, a 16-bit overflow and an 8-bit overflow.
>>>>>>
>>>>>> Consider:
>>>>>>
>>>>>> signed char a=127;
>>>>>> signed char b=127;
>>>>>> signed char c;
>>>>>> c=a+b;
>>>>>>
>>>>>> The addition is defined in C.  Maybe the narrowing of the result in
>>>>>> the assignment is undefined, C standards lawyers will know.
>>>>>>
>>>>>> But of course, the major question is who wants this?  Who uses
>>>>>> -ftrapv
>>>>>> on MIPS and Alpha which have such instructions (for 32 bits and 64
>>>>>> bits, relevant for their I32LP64 C).
>>>>>>
>>>>>>> Use after free - much more difficult.  It might be possible to
>>>>>>> have a hardware list of "poisoned" address ranges from which it is
>>>>>>> not permitted to load.  Very expensive (comparable to
>>>>>>> cache) and would probably cache only the most recently freed
>>>>>>> memory blocks.  Not sure if this is worth it.
>>>>>>
>>>>>> If you have NaT bits associated with the memory, you could fill the
>>>>>> free()d memory with NaTs.
>>>>>
>>>>> I would love to have NaT bits (NaR in our terminology) associated
>>>>> with memory. It's certainly doable, but not economically feasible
>>>>> IMO, unless you are Samsung.
>>>>
>>>> I was thinking about (ab)using a modification of your mechanism that
>>>> allows reading zeros when you load from uninitialized memory, but I
>>>> suspect the overhead might be way to high.
>>>
>>> We looked at having uninit read as NaR. If real Samsung had NaR bits
>>> then you could write a speculative NaR and later discard it
>>> harmlessly; without Samsung we have to fault a NaR store, which
>>> limits the degree of performance gain available from speculation.
>>> With NaR uninits but no Samsung we can nanny the programmer, but the
>>> common zero init (as nannied) becomes explicit, lowering performance.
>>> Absent Samsung, we decided that the reliability gain from nannying
>>> wasn't as good as the performance gain from zero; YMMV. Might well
>>> have gone the other way had Samsung been aboard.
>>
>> Obviously I am missing something, but I thought your "read zeros"
>> mechanism used the PLB, not anything in the RAM itself.  So I was
>> suggesting some enhancement of the range protection in the PLB, but as
>> I said, I fear it would entail too much overhead.
>
> Not the PLB, which handles permissions, but the TLB, which does
> translation and can tell whether an address for which you have
> permission (PLB) is mapped to physical DRAM (TLB) or should be assumed
> to be zero without doing a mapping first..

OK, that is what I was missing. Thanks.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 10/19/2021 4:37 PM, Stefan Monnier wrote:
> Stephen Fuld [2021-10-19 12:49:11] wrote:
>> On 10/11/2021 10:13 AM, George Neuner wrote:
>>> Address space won't be a problem until 64 bits is too small for a
>>> /single/ program. "Big data" notwithstanding, I don't expect to see
>>> programs of that size any time in this century.
>> You may be right. But historically, desired address space has grown by
>> about 1 bit every 2-3 years.
>
> George was speaking about the segment of the market *not* concerned with
> "big data". While this is a very vague definition of "segment of the
> market", I'd tend to agree with him that it appears to have grown a lot
> slower than "1 bit every 2-3 years".
>
> At least, I have the feeling that the amount of RAM on "average laptops"
> has not even quadrupled over the last 10 years.
>

Yeah, a lot of stuff would probably be fine with 8GB of RAM apart from
the combination of OS bloat and web-browser bloat.

I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
a fairly long time (at least, last I looked at laptops).

>> Currently we are probably in the mid forties bits, so if the trend
>> continues then we will exceed 64 before 2099.
>
> But that's for "big data". For desktops we're barely reaching the
> fortieth bit at the top end of the market, AFAICT. So if that grows at
> 2bits every 10 years that puts the 64bit barrier well into the
> XXII century.
>

Yeah, hardware stats on consumer PCs seems to be slowing down rather
than speeding up.

We hit ~ 3-4 GHz nearly 2 decades ago.

RAM and HDD sizes started rapidly slowing down around a decade ago.

Say, HDD sizes:
1990: 100MB
2000: 20GB
2010: 1TB
2020: 8TB

So, 200x, 50x, 8x.

Or, "typical" RAM sizes:
1990: 4MB
2000: 512MB
2010: 8GB
2020: 32GB

So: 128x, 16x, 4x.

The number of cores has increased, but this is hardly exponential either.

RAM bandwidth has increased, but is limited by a combination of
clock-speed and bus width. Given DRAM clock-speed has nearly reached
parity with the CPU cores, getting much faster is likely to require
wider buses.

Most likely result would be RAM needing to move over to LGA sockets or
similar, with the CPUs having even bigger LGA sockets. To avoid needing
absurdly large chips, pin pitch will need to get smaller, but there are
limits to how small of pin-pitch is viable.

I also have doubts as to the viability of optical interconnects (I
suspect the usable bandwidth for an optical RAM interconnect would be
lower than an electronic interconnect).

Though, one possibility could be replacing DDR signaling with QAM or
similar (and then maybe have people try to figure out how to mimic the
properties of coax cabling within the PCB traces).

Well, or they try to switch to higher frequencies, but then deal with
the issue that the signals no longer propagate effectively through solid
copper (much past a few GHz) so effectively either have to make traces
with some other material or engineer waveguides into the PCBs or similar
(both of which are likely to fall into "no longer cost effective"
territory).

Either way, my current prediction is that (at least for mainstream
equipment) progress kinda "fizzles out" on this front.

Like, several decades for now, we might find people using computer
equipment only modestly bigger and faster than what we have already.

Or, at least, this is what I assumed in some of my SciFi writing; people
pushing it to the limits of using LGA RAM chips, but stopping there,
mostly because of a mixture of cost/benefit and that it seems like we
are already pushing the limits of what may be "physically possible".

Though, the assumption was that RAM and storage sizes keep on an upward
trend for a while, but it is "modest" given I am assuming ~ 16x the RAM
capacity over ~ 50 years, or an average of around 0.8 bit per decade.

However, the assumption is more that it is ~ 3 bits over ~ 25 years, and
another 25 years with only around 1 bit.

Granted, I could be wrong and my predictions are overly pessimistic, but
either way. In any case, I don't expect "riding an exponential curve
into the far future" is particularly realistic, and the more likely
outcome is for everything to roughly plateau (like what roughly happened
for CPU clock speeds, but for "everything else").

>
> Stefan "typing this on a 3GB laptop ;-)"
>

I am using a desktop PC with 48GB of RAM.

Of which a third of this is currently being eaten by Firefox.

According to BGB <cr88192@gmail.com>:
>I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
>a fairly long time (at least, last I looked at laptops).

I'm typing this on a 16GB Macbook that I bought two years ago. Apple just announced
some new M1 based laptops that can go up to 32 or 64GB, although they are very expensive
and the 64GB is aimed at people doing video editing.

Dell makes a few 32 and 64GB laptops, again pretty expensive.

16GB is now a normal size. I bought this one off the shelf in an Apple
store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
are still special order.

At the high end I see that IBM z Series has this recent history

model year max memory
zEC12 2013 3TB (42 bits)
z13 2015 10TB (44 bits)
z14 2017 32TB (45 bits)
z15 2019 40TB (46 bits)

So it looks to me more like one bit every two years, so mainframes will
hit 64 bits in the 2050s and normal computers 20 years later.

--
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

On 10/19/2021 8:58 PM, John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>> I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
>> a fairly long time (at least, last I looked at laptops).
>
> I'm typing this on a 16GB Macbook that I bought two years ago. Apple just announced
> some new M1 based laptops that can go up to 32 or 64GB, although they are very expensive
> and the 64GB is aimed at people doing video editing.
>
> Dell makes a few 32 and 64GB laptops, again pretty expensive.
>

I was mostly only seeing 4GB and 8GB models when I was looking a few
years ago, but admittedly, I was primarily looking at sub $1k models.

It didn't seem like new laptops in this category have much advantage
stats-wise over sometimes significantly older models.

Like, as far as the stats go, one almost may as well save some money and
buy an older refurbished model (like, at least most of these still come
with IO ports, and removable HDDs and batteries).

> 16GB is now a normal size. I bought this one off the shelf in an Apple
> store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
> are still special order.
>

Don't have anything Apple here; usual issue is that Apple stuff is too
expensive probably for most people to be able to afford (so, like the
electronics equivalent of buying a Rolex, kind of a needless luxury item).

Like, probably a lot of people would have more pressing matters in their
life that they need to spend money on, like paying rent and buying food
and similar.

Some might generally be running PCs formed out of a mishmash of old and
new parts (and some amount second hand parts), ...

Some might be running PC's made mostly from parts that they quietly
'salvaged' from commercial dumpsters, ... (often a lot of the
dumpster-class hardware seems like it could still have resale value;
like for people who want to build PCs running 15 year old Xeons and
similar, ...).

> At the high end I see that IBM z Series has this recent history
>
> model year max memory
> zEC12 2013 3TB (42 bits)
> z13 2015 10TB (44 bits)
> z14 2017 32TB (45 bits)
> z15 2019 40TB (46 bits)
>
> So it looks to me more like one bit every two years, so mainframes will
> hit 64 bits in the 2050s and normal computers 20 years later.
>

I am explicitly thinking here of consumer-grade hardware, high-end
systems seem to be advancing at a faster rate relative to consumer grade
hardware. Similarly, excluding high-end enthusiast grade parts, ...

Then again, it could be partly that they is a growing divide between
"new / high end" and "generally sufficient".

On 10/19/2021 6:58 PM, John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>> I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
>> a fairly long time (at least, last I looked at laptops).
>
> I'm typing this on a 16GB Macbook that I bought two years ago. Apple just announced
> some new M1 based laptops that can go up to 32 or 64GB, although they are very expensive
> and the 64GB is aimed at people doing video editing.
>
> Dell makes a few 32 and 64GB laptops, again pretty expensive.
>
> 16GB is now a normal size. I bought this one off the shelf in an Apple
> store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
> are still special order.
>
> At the high end I see that IBM z Series has this recent history
>
> model year max memory
> zEC12 2013 3TB (42 bits)
> z13 2015 10TB (44 bits)
> z14 2017 32TB (45 bits)
> z15 2019 40TB (46 bits)
>
> So it looks to me more like one bit every two years, so mainframes will
> hit 64 bits in the 2050s and normal computers 20 years later.

Interesting. That raises the question of whether these systems are
running a single program that needs that much RAM (seems unlikely to
me), or there is some other advantage of having a single large system
over multiple smaller ones (George Neuner's solution - just buy another
one).

There may be "artificial" advantages of a single system, such as the way
the software licensing works, or there may be some real advantage in
system management, etc.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 10/19/2021 10:07 PM, BGB wrote:
> On 10/19/2021 8:58 PM, John Levine wrote:
>> According to BGB  <cr88192@gmail.com>:
>>> I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
>>> a fairly long time (at least, last I looked at laptops).
>>
>> I'm typing this on a 16GB Macbook that I bought two years ago.  Apple
>> just announced
>> some new M1 based laptops that can go up to 32 or 64GB, although they
>> are very expensive
>> and the 64GB is aimed at people doing video editing.
>>
>> Dell makes a few 32 and 64GB laptops, again pretty expensive.
>>
>
> I was mostly only seeing 4GB and 8GB models when I was looking a few
> years ago, but admittedly, I was primarily looking at sub $1k models.
>
> It didn't seem like new laptops in this category have much advantage
> stats-wise over sometimes significantly older models.
>
>
> Like, as far as the stats go, one almost may as well save some money and
> buy an older refurbished model (like, at least most of these still come
> with IO ports, and removable HDDs and batteries.

>> 16GB is now a normal size. I bought this one off the shelf in an Apple
>> store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
>> are still special order.
>>
>
> Don't have anything Apple here; usual issue is that Apple stuff is too
> expensive probably for most people to be able to afford (so, like the
> electronics equivalent of buying a Rolex, kind of a needless luxury item. > Like, probably a lot of people would have more pressing matters in their
> life that they need to spend money on, like paying rent and buying food
> and similar.

Apparently the millions of people who have bought Macbooks disagreed
with you.

> Some might generally be running PCs formed out of a mishmash of old and
> new parts (and some amount second hand parts), ...

The percentage of people who build their own PCs is quite small. Most
just buy whatever Dell or HP model (or equivalent from another vendor)
seems to meet their needs. And a huge percentage of desktop PCs are
bought by businesses who aren't going to fool around mixing old parts.

> Some might be running PC's made mostly from parts that they quietly
> 'salvaged' from commercial dumpsters, ... (often a lot of the
> dumpster-class hardware seems like it could still have resale value;
> like for people who want to build PCs running 15 year old Xeons and
> similar, ...).

You and a relatively few of your friends. :-)

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>I'd tend to agree with him that it appears to have grown a lot
>slower than "1 bit every 2-3 years".
>
>At least, I have the feeling that the amount of RAM on "average laptops"
>has not even quadrupled over the last 10 years.

Indeed. My Lenovo X121e from 2011 came with 4GB in one DDR3 SO-DIMM
(plus an empty SO-DIMM slot) and it cost ~EUR 330.

My Fujitsu Lifebook U7311 from 2021 came with 8GB soldered in (plus an
empty SO-DIMM slot) and it cost ~EUR 1200.

>> Currently we are probably in the mid forties bits, so if the trend
>> continues then we will exceed 64 before 2099.
>
>But that's for "big data". For desktops we're barely reaching the
>fortieth bit at the top end of the market, AFAICT.

The technological development that drives RAM size are the same for
desktops and others: It's how much fits on a single low-cost die. And
it seems that this has slowed down in recent years: 16GB DDR4 UDIMMs
(i.e., with 8Gb dies) became available in 2015, 32GB DDR4 UDIMMs (with
16Gb dies) in 2020 (I wanted to find announcement of the devices, but
Google only showed me sales pages for computers, phones or DIMMs with
8GB, even when I asked it for "8 Gbit"; so I went with the
introduction of the corresponding UDIMMs, where the largest ones
invariably contain 16/18 dies); so that's one bit in 5 years. If "big
data" or whatever wants RAM to grow faster, they need to put an
exponentially growing number of devices in their machines. I have my
doubts that this is economical.

Maybe this slowness was due to the delays in EUV introduction, but
it's far from clear that these delays will stay an exception and that
upcoming hurdles can all be taken in the traditional relentless stride
observed in Moore's law.

If you want more than 2^64 bytes of physical RAM in a machine with,
say, 64K RAM dies (IBM z15 supports 40K 8Gb dies), each die has to
hold more than 2^51 bits of RAM, i.e., 2Pb. Will even a slowed-down
version of Moore's law hold that long, and will it do so before 2100?

The other thing about 64bits is that you usually want a bit more
address space than physical RAM, for various reasons (note that, e.g.,
the first implementations of AMD64 supported 48 bits of virtual
addresses and 40 bits of physical addresses), so if we ever get close
to needing 64 bits for physical RAM, we probably will switch to
128-bit machines a little earlier. Of course, by that time we will
have a much longer legacy of 64-bit software than we had with 32-bit
software in the 32->64-bit-transition.

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

On 10/20/2021 1:52 AM, Stephen Fuld wrote:
> On 10/19/2021 10:07 PM, BGB wrote:
>> On 10/19/2021 8:58 PM, John Levine wrote:
>>> According to BGB  <cr88192@gmail.com>:
>>>> I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
>>>> a fairly long time (at least, last I looked at laptops).
>>>
>>> I'm typing this on a 16GB Macbook that I bought two years ago.  Apple
>>> just announced
>>> some new M1 based laptops that can go up to 32 or 64GB, although they
>>> are very expensive
>>> and the 64GB is aimed at people doing video editing.
>>>
>>> Dell makes a few 32 and 64GB laptops, again pretty expensive.
>>>
>>
>> I was mostly only seeing 4GB and 8GB models when I was looking a few
>> years ago, but admittedly, I was primarily looking at sub $1k models.
>>
>> It didn't seem like new laptops in this category have much advantage
>> stats-wise over sometimes significantly older models.
>>
>>
>> Like, as far as the stats go, one almost may as well save some money
>> and buy an older refurbished model (like, at least most of these still
>> come with IO ports, and removable HDDs and batteries.
>
>>> 16GB is now a normal size. I bought this one off the shelf in an Apple
>>> store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
>>> are still special order.
>>>
>>
>> Don't have anything Apple here; usual issue is that Apple stuff is too
>> expensive probably for most people to be able to afford (so, like the
>> electronics equivalent of buying a Rolex, kind of a needless luxury
>> item. > Like, probably a lot of people would have more pressing
>> matters in their
>> life that they need to spend money on, like paying rent and buying
>> food and similar.
>
> Apparently the millions of people who have bought Macbooks disagreed
> with you.
>

I suspect they are mostly "rich people", like the same ones who buy big
houses and fancy cars.

For pretty much everyone else, there are normal PCs running Windows or
Linux; and Android devices for when one needs a smartphone or similar.

Before I had lost my job, was almost to the point of considering getting
a car, but it would have been a used one.

As-is, no real money, so it isn't going to happen.

Could be a lot worse, still live with parents, so "the basics" are
covered, though stuff like food that is basically some mix of things
like ramen noodles (square ramen bricks), mixed vegetables, and cubed
potatoes, thrown into a pot and boiled, then reused over multiple days
with various other stuff thrown in each time, yeah this sorta stuff is
kinda lame...

Well, also rice or similar sometimes, ...

Granted, food products are expensive...

>
>> Some might generally be running PCs formed out of a mishmash of old
>> and new parts (and some amount second hand parts), ...
>
> The percentage of people who build their own PCs is quite small.  Most
> just buy whatever Dell or HP model (or equivalent from another vendor)
> seems to meet their needs.  And a huge percentage of desktop PCs are
> bought by businesses who aren't going to fool around mixing old parts.
>

New pre-built PCs tend to be overpriced and kinda weak regarding their
hardware stats (at least from places like BestBuy).

There is also Walmart, but their PCs suck on this front (overpriced
crappy HW, typically them also only putting in a single stick of RAM).

My current PC:
Case, PSU, MOBO, and CPU were new (Ryzen 7 2700X);
HDDs were carried over from prior PCs;
Also have an SSD for OS + pagefile.
GPU is a second hand GTX 980.

Have 48GB, comprised of two 8GB sticks and two 16GB sticks.

Monitors are an LCD (1680x1050 max, DVI/HDMI);
And, an 34" LCD TV being used as a monitor (1920x1080, also HDMI).

For my use-cases, mostly wanted decent amounts of CPU and RAM.

Turbo is disabled, partly because turbo doesn't really help much with my
use-cases (mostly running the CPU semi-consistently at upwards of
50-70%, often running a bunch of Verilog simulations in parallel to see
if everything is working, or if any of them crash there may be a bug I
need to look at). Also occasionally compiling stuff, running genetic
algorithms, ...

Not really a gamer, so the older card isn't too much of an issue, apart
from its inability to do the whole 'RTX' thing. My "gaming" anymore is
mostly limited to occasionally poking around in Minecraft or similar.

Never got that big into the whole RGB thing, but the MOBO and CPU fan I
have use it by default, so whatever.

My setup is basically air-cooled as well (so, no fancy pumps or "water
loops" or any of that fun).

Did get a kinda beast of a PC tower case though in the off-chance I
wanted at some point to stick in an EATX MOBO. Also has a decent amount
of space for HDDs.

>
>> Some might be running PC's made mostly from parts that they quietly
>> 'salvaged' from commercial dumpsters, ... (often a lot of the
>> dumpster-class hardware seems like it could still have resale value;
>> like for people who want to build PCs running 15 year old Xeons and
>> similar, ...).
>
> You and a relatively few of your friends.  :-)
>

Luckily, I am not desperate enough to use a salvage-parts build PC as my
main PC.

The Dual Xeon E5410 boxes I have... Yeah, these are recycle salvage...

Despite the age of the CPUs, ..., these things are actually pretty
formidable in terms of memory bandwidth and ability to run genetic
algorithms and similar.

Like, while its single thread performance is kinda meh, one can
basically max out all of the cores without any real noticeable drop in
per-core performance or memory bandwidth.

Unlike any of my "normal" PCs; which go full speed up to a certain
number of threads, and then drop-off (as-if the total memory bandwidth
hits a wall after a certain number of threads).

....

Michael S wrote:
> On Tuesday, October 19, 2021 at 10:49:15 PM UTC+3, Stephen Fuld
> wrote:
>> On 10/11/2021 10:13 AM, George Neuner wrote:
>>> On Sun, 10 Oct 2021 16:31:21 -0700, Stephen Fuld
>>> <sf...@alumni.cmu.edu.invalid> wrote:
>>>
>>>> I don't think the question of whether 64 bits is adequate (it
>>>> is), but for how long into the future will it be adequate, and
>>>> secondarily, when it does become inadequate, how big a change,
>>>> hardware and software, will be required to deal with it?
>>>
>>> When the time comes that one computer can't run all your
>>> programs, buy another one.
>>>
>>> Address space won't be a problem until 64 bits is too small for
>>> a /single/ program. "Big data" notwithstanding, I don't expect to
>>> see programs of that size any time in this century.
>>
>> You may be right. But historically, desired address space has grown
>> by about 1 bit every 2-3 years. Currently we are probably in the
>> mid forties bits, so if the trend continues then we will exceed 64
>> before 2099. But others have said the trend is slowing.
>>
>
> I think, the highest memory capacity of single-system-image computers
> is stuck at 24TB for 7 or 8 years.

24TB is a strange value, how did you get to it? Does all those high-end
systems have factors of three memory slots?

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Stefan Monnier wrote:
> Stephen Fuld [2021-10-19 12:49:11] wrote:
>> On 10/11/2021 10:13 AM, George Neuner wrote:
>>> Address space won't be a problem until 64 bits is too small for a
>>> /single/ program. "Big data" notwithstanding, I don't expect to see
>>> programs of that size any time in this century.
>> You may be right. But historically, desired address space has grown by
>> about 1 bit every 2-3 years.
>
> George was speaking about the segment of the market *not* concerned with
> "big data". While this is a very vague definition of "segment of the
> market", I'd tend to agree with him that it appears to have grown a lot
> slower than "1 bit every 2-3 years".
>
> At least, I have the feeling that the amount of RAM on "average laptops"
> has not even quadrupled over the last 10 years.

My last 4 laptops have been

~2009 Dell 16 GB upgraded HDD multiple times, ending at 1TB
2013 HP 32 GB also a few HDD upgrades, ending at 2 TB
2017 Dell 32 GB (new employer), came with 256 GB SSD, added 2 TB HDD
2020 Dell 32 GB (new employer), came with 2 TB SSD.

So both memory and disk have been pretty much static for a decade.

Have now added about 60 TB of home storage on a Synology NAS, this holds
all the data for https://mapant.no/

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Wednesday, October 20, 2021 at 4:58:07 AM UTC+3, John Levine wrote:
> According to BGB <cr8...@gmail.com>:
> >I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
> >a fairly long time (at least, last I looked at laptops).
> I'm typing this on a 16GB Macbook that I bought two years ago. Apple just announced
> some new M1 based laptops that can go up to 32 or 64GB, although they are very expensive
> and the 64GB is aimed at people doing video editing.
>
> Dell makes a few 32 and 64GB laptops, again pretty expensive.
>
> 16GB is now a normal size. I bought this one off the shelf in an Apple
> store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
> are still special order.
>
> At the high end I see that IBM z Series has this recent history
>
> model year max memory
> zEC12 2013 3TB (42 bits)
> z13 2015 10TB (44 bits)
> z14 2017 32TB (45 bits)
> z15 2019 40TB (46 bits)
>

Which z15 model has more than 16TB of memory installed?

> So it looks to me more like one bit every two years, so mainframes will
> hit 64 bits in the 2050s and normal computers 20 years later.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, October 20, 2021 at 12:22:31 PM UTC+3, Terje Mathisen wrote:
> Michael S wrote:
> > On Tuesday, October 19, 2021 at 10:49:15 PM UTC+3, Stephen Fuld
> > wrote:
> >> On 10/11/2021 10:13 AM, George Neuner wrote:
> >>> On Sun, 10 Oct 2021 16:31:21 -0700, Stephen Fuld
> >>> <sf...@alumni.cmu.edu.invalid> wrote:
> >>>
> >>>> I don't think the question of whether 64 bits is adequate (it
> >>>> is), but for how long into the future will it be adequate, and
> >>>> secondarily, when it does become inadequate, how big a change,
> >>>> hardware and software, will be required to deal with it?
> >>>
> >>> When the time comes that one computer can't run all your
> >>> programs, buy another one.
> >>>
> >>> Address space won't be a problem until 64 bits is too small for
> >>> a /single/ program. "Big data" notwithstanding, I don't expect to
> >>> see programs of that size any time in this century.
> >>
> >> You may be right. But historically, desired address space has grown
> >> by about 1 bit every 2-3 years. Currently we are probably in the
> >> mid forties bits, so if the trend continues then we will exceed 64
> >> before 2099. But others have said the trend is slowing.
> >>
> >
> > I think, the highest memory capacity of single-system-image computers
> > is stuck at 24TB for 7 or 8 years.
> 24TB is a strange value, how did you get to it? Does all those high-end
> systems have factors of three memory slots?
>

It's not "all those systems" it's several generations of one specific system.

Originally it was called Altix UV. Back then it supported 16TB max.
Then it was renamed SGI UV and max. memory was increased to 24 TB, I don't know what happened earlier.
For last ~5 years it is called HPe Superdome Flex.

Earlier 24TB models were based on Intel Xeon processors (probably E7 v2 Family, but I don't remember for sure, may be even older models already supported this capacity) that had 4 memory channels and supported 3 DIMMs per channel.
The latest generation uses Skylake-SP Xeons. They have 6 channels, but it seems only 2 DIMMs per channel, at least as long as one wants supports for top memory speed.

> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

> My sense is this idea is not much better than how things are
> now. I would like to see the decision be under control of
> the source code, perhaps by means of a #pragma:
>
> #pragma STDC SIGNED_OVERFLOW WRAP
> #pragma STDC SIGNED_OVERFLOW TRAP
> #pragma STDC SIGNED_OVERFLOW SATURATE
> #pragma STDC SIGNED_OVERFLOW UNDEFINED
> (..others?..)

I think you are missing the most important one

#pragma STDC SIGNED_OVERFLOW UNSPECIFIED

Specifically the option that signed overflow results in a value within
the bounds of the particular type. Which particular value does not
matter and may vary.

/Benny

On Wednesday, October 20, 2021 at 4:58:07 AM UTC+3, John Levine wrote:
> According to BGB <cr8...@gmail.com>:
> >I am pretty sure much of the laptop space has been stuck at 4GB/8GB for
> >a fairly long time (at least, last I looked at laptops).
> I'm typing this on a 16GB Macbook that I bought two years ago. Apple just announced
> some new M1 based laptops that can go up to 32 or 64GB, although they are very expensive
> and the 64GB is aimed at people doing video editing.

Amazon shows plenty of modern 32 GB laptops in 800 to 1000 USD range.
And few older models that can be bought under 650 USD e.g. Dell Latitude 5580.
But for later I am not so sure that they are able to deliver.

>
> Dell makes a few 32 and 64GB laptops, again pretty expensive.
>
> 16GB is now a normal size. I bought this one off the shelf in an Apple
> store in 2019 when my formerly trusty old laptop croaked. 32 and 64 GB
> are still special order.
>
> At the high end I see that IBM z Series has this recent history
>
> model year max memory
> zEC12 2013 3TB (42 bits)
> z13 2015 10TB (44 bits)
> z14 2017 32TB (45 bits)
> z15 2019 40TB (46 bits)
>
> So it looks to me more like one bit every two years, so mainframes will
> hit 64 bits in the 2050s and normal computers 20 years later.
>
> --
> Regards,
> John Levine, jo...@taugh.com, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

On Wednesday, October 20, 2021 at 2:24:25 PM UTC+3, Benny Lyne Amorsen wrote:
> Tim Rentsch <tr.1...@z991.linuxsc.com> writes:
>
> > My sense is this idea is not much better than how things are
> > now. I would like to see the decision be under control of
> > the source code, perhaps by means of a #pragma:
> >
> > #pragma STDC SIGNED_OVERFLOW WRAP
> > #pragma STDC SIGNED_OVERFLOW TRAP
> > #pragma STDC SIGNED_OVERFLOW SATURATE
> > #pragma STDC SIGNED_OVERFLOW UNDEFINED
> > (..others?..)
> I think you are missing the most important one
>
> #pragma STDC SIGNED_OVERFLOW UNSPECIFIED
>
> Specifically the option that signed overflow results in a value within
> the bounds of the particular type. Which particular value does not
> matter and may vary.
>

The whole subthread started with my suggestion (or wish) that both unspecified and undefined should to be eliminated from future C standards. Or, at very least, strongly discouraged.

>
> /Benny

On 19/10/2021 17:34, Victor Yodaiken wrote:
> On Tuesday, October 19, 2021 at 2:21:11 AM UTC-5, David Brown wrote:
>> On 18/10/2021 19:00, Victor Yodaiken wrote:
>>> On Monday, October 18, 2021 at 11:14:33 AM UTC-5, David Brown wrote:
>>>
>>>> Relying on wrapping is ugly and error-prone. It encourages people to
>>>> write code that makes no logical sense, such as adding two positive
>>>> numbers and checking for them being negative.
>>>
>>> 1. Signed arithmetic is a representation of arithmetic in the residue ring of the integers mod 2^{k}
>> Not in standard C, and many other languages.
>>> 2. Signed arithmetic is a patchy approximation of arithmetic over the integers with known failure cases and
>>> unpredictable results and where the implication of x+1 > x and x <= INT_MAX is that INT_MAX < INT_MAX
>>>
>> Not in standard C, or any other language I know of. x + 1 is not
>> defined for x = INT_MAX, so it can have no implications.
>>> Of course 1 makes no logical sense. Bravo!
>>>
>> Try this exercise - find a random person, and ask them if "x + 1" is
>> always bigger than "x". Assuming you can make it past the "is this a
>> trick question?" stage, you'll get a "yes". C integer arithmetic
>> matches this.
>
> For the record, I agree that using int where you really mean unsigned int is
> sloppy although there are 10s of millions of lines ( at least) of C code that
> has that idiom in it and if I was managing such code I would be beyond
> furious if the compiler changed the game on me.
>

Well, prepare to be beyond furious - compilers don't guarantee that
these "code tricks" work, and never have, and lots of compilers have
gradually stepped up their optimisation in this area over the years.
MSVC had a lift in its optimisation a few years ago, and the blog about
it specifically notes that some of the new features work by assuming
signed integer overflow does not occur. gcc has been doing this for a
couple of decades, with gradually more "no signed overflow"
optimisations each generation, and also a gradual reduction in the
optimisation level before these things kick in. clang has been doing it
since its inception.

As a quick test, go to <https://gotbolt.org> and put in the code :

#include <stdbool.h>

bool ffoo(int x) {
int y = x + 1;
return y < x;
}

Compare the results for various compilers, and their flags, and see
which ones optimise to a "return 0;". gcc up to 7 does so on -O2, gcc 8
onwards does it for -O1. Clang from version 3 (the oldest on godbolt)
does it for -O1, as do all versions of icc on the site. MSVC does not
optimise this particular case, but I've seen it do so for others.

This is not /new/. This is not something that only applies to one
compiler. It is, however, something that is applying to an increasing
number of compilers and versions.

So your choices are to fix the broken code, or to make sure you use
build flags to limit compiler versions or optimisations.

The one thing that won't work is saying you want things to be different,
or that you thought they used to be different, or that other people have
got this wrong.

Anyone who wrote code 20 years ago that depended on wrapping signed
integer arithmetic in C, made a mistake - their code was unreliable or
non-portable 20 years ago, and there were compilers 20 years ago that
would not have given the results the programmer wanted. At most, what
has changed is how often this resulted in problems - it's a matter of
degree, not of absolute change.

> But your argument here is super weak.

My argument was showing that "it makes no sense to try to do arithmetic
on numbers bigger than you can hold" is a far more rational, logical and
intuitive way to do integer arithmetic than "you are working with the
residue ring ℤ/2ⁿ plus additional features such as an sort-of ordering
that doesn't really fit the mathematical algebraic structure".

> .
> Find a random person and ask them if 1/2 is equal to 0.
>
> Ask if they know what INT_MAX is. Then ask them if x+1 > x is a rule.
> Your actual rule is "if x< INT_MAX then x+1 > x".

My /actual/ rule is that you can only do "x + 1" if x < INT_MAX.

>
>
> With modular arithmetic, when the user provides two positive numbers and
> I need to see if they can be multiplied safely I write
> if(x*y < x)wontwork();
> This is a very cheap computation on 99% of 32/64 bit computers
> What's your solution in UB Arithmetic? Maybe there is a good
> solution I don't know.
>

My solution would be to find something that is /correct/ - yours is not,
even when you use wrapping semantics. Let's use 16-bit integers because
the numbers are easier than 32-bit. x = 1000, y = 1000. x * y is
mathematically 1000000, reduced modulo 65536 you get 16950 which is
bigger than x. Ops - your check failed to spot that overflow!

The best solution to doing this correctly and safely depends on the
circumstances. Usually the correct answer is to know what you are
dealing with - it is rare that the only thing you know about the
variables in your code is their type. A difficulty with doing things
well in C is that people tend to use "int" for everything without
thinking, and lose important information such as ranges.

Remember, overflowing your integers gives you the wrong answer. At best
- if you have guaranteed wrapping behaviour - it can give you an error
indication to show if your answer is right or wrong. What are you going
to do with that error indication? Once you have figured that out, and
figured out how the error could arise (did you sanitize the inputs from
outside the code?), you are most of the way towards understanding how to
avoid any possibility of overflow, or how to predict it (rather than
leaping out blindly and trying to guess the size of the jump by the
number of broken bones you got).

The simplest way to handle overflow in general is to use a bigger type
for the operation and then compare the result. gcc has a series of
builtin overflow-detecting functions - it would be great if these were
standardised and supported by other compilers (clang supports them).

>>
>> Find another random person and ask them if they know what a residue ring
>> is. Ask them if they think ℤ/2ⁿ is a natural way to count and do
>> arithmetic.
>
> Do you think mod 2^k arithmetic is too weird for programmers?
> That's a real question, not a rhetorical one.
> When I taught intro computer science, it didn't seem too hard
> for 18 year olds.

No, I don't think it is too hard to understand (as long as you use words
like "wrapping" rather than "residue rings"). But I don't think it is
logical for signed arithmetic. It makes far more sense to say that the
integers are limited in size, and you should not try to use them for
numbers bigger than that. It's that simple.

>
>> Ask them if they know why this is similar, but not
>> identical, to two's complement integers with wrapping. (Hint - think
>> about division.)
>
> Maybe you know something I don't, which is always possible, but as far as I know,
> it is the same as 2s complement with wrapping - and wrapping is implicit
> for 2s complement. Division works as it should.

Again, we will use 16-bit for simplicity. In C integers, as with normal
integers, -1000 / 10 is -100. In ℤ/2ⁿ, -1000 is equivalent to 64536.
Dividing by 10 gives 6453.

For most purposes, if you want wrapping behaviour with signed integer
types in C, the simplest correct solution is to cast the values to
unsigned, do the operation, then cast back to signed (this last cast is
implementation-dependent, thus fully defined on any given
implementation, and I've never heard of a two's complement system that
didn't do it by wrapping). Division is the exception - using signed and
unsigned division gives different results. On the other hand, signed
division won't overflow except on the one awkward case of INT_MIN / -1.

> ( in mathematics they say Z/2^kZ is a ring, not a field, in computer architecture
> its just repeated subtraction )

It is a ring, not a field (division is not an inverse of multiplication,
which is required for a field). But yes, in the computing world it is
usually described in terms of repeated addition/subtraction, or modulo.

>
>> Ask them if they think a logical and natural numbering system should
>> follow basic rules of arithmetic as much as possible in the limited space.
>
> "Basic rules of arithmetic" is context dependent. x/(2*x) == 0 is a basic rule
> for integers (and modulus arithmetic) but not for real numbers or floating
> point.

Integers can't be fractions - that's a basic rule of arithmetic, I would
say.

> The other thing about 64bits is that you usually want a bit more
> address space than physical RAM, for various reasons (note that, e.g.,
> the first implementations of AMD64 supported 48 bits of virtual
> addresses and 40 bits of physical addresses), so if we ever get close
> to needing 64 bits for physical RAM, we probably will switch to
> 128-bit machines a little earlier.

Indeed, it might bring the need to switch a bit closer.

This said, there's another factor at play:

In the past, when a limit was reached it seemed obvious that while
it only affected the top-end of the range, the middle end would be
affected soon as well. So it was worthwhile to invest into a whole
new ISA with significantly larger pointers.

But already for the switch from 32bit to 64bit, this hasn't been nearly
as true as expected: [ignoring supercomputers] the switch to 64bit
started back around 1990, but 30 years later the vast majority of
computer users still wouldn't notice a difference if their OS was using
the old 32bit ISA rather than the new 64bit ISA in their processor.

So maybe when the bigger machines start bumping into the 64bit limit,
the decision to move to 128bit pointers will not be nearly as simple
as it was for 64bit pointers, because the mass market might be
uninterested/unwilling to move to 128bit pointers, drastically affecting
the possible economies of scale.

Stefan

On 20/10/2021 13:24, Benny Lyne Amorsen wrote:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> My sense is this idea is not much better than how things are
>> now. I would like to see the decision be under control of
>> the source code, perhaps by means of a #pragma:
>>
>> #pragma STDC SIGNED_OVERFLOW WRAP
>> #pragma STDC SIGNED_OVERFLOW TRAP
>> #pragma STDC SIGNED_OVERFLOW SATURATE
>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>> (..others?..)
>
> I think you are missing the most important one
>
> #pragma STDC SIGNED_OVERFLOW UNSPECIFIED
>
> Specifically the option that signed overflow results in a value within
> the bounds of the particular type. Which particular value does not
> matter and may vary.
>
>

I agree with you here. "Unspecified" gives the compiler quite a lot of
freedom, but less than "undefined". If x is "undefined", then it is
quite acceptable for neither "if (x < 0)" nor "if (x >= 0)" to succeed -
the compiler can skip both. If x is "unspecified", it can pick which
one it likes to use but exactly one of the paths will be taken.

Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:

> On 10/16/2021 1:02 PM, Tim Rentsch wrote:

[...]

>> I have fond memories of Alan Perlis from when he was teaching at
>> Caltech during the time I was a student there.
>
> When I was an undergrad at CMU (1968-1972), Perlis was chairman of the
> computer science department. There was no undergrad comp sci major (I
> was a Chemistry major), but they did offer some undergraduate courses.
> The introductory course (S600), was taught by Perlis himself, and
> taught Algol (Perlis was on the committee that defined it).

My cirmstances were different. By the time Perlis arrived I was
well past introductory courses. I got to enjoy the interesting
things he said without the worry of having to learn from him as
an instructor.

> The course had a terrible reputation. Apparently he gave one exam
> where, out of 100 points, the average grade was something like 9, 16
> got you an A, and zero was passing.

Now that is quite reminiscent of my time at school, except that zero
wasn't passing. And it wasn't just one department either.

Ivan Godard <ivan@millcomputing.com> writes:

> On 10/19/2021 11:58 AM, Thomas Koenig wrote:
>
>> David Brown <david.brown@hesbynett.no> schrieb:
>>
>>> There are more problems than that. Consider "y = x + 3 - 2;". (Imagine
>>> it is the result of a set of macros, or inline functions and constant
>>> propagation, rather than a hand-written expression.) Can a compiler
>>> change that to "y = x + 1;" with overflow checking there? Does it need
>>> to do two operations, checking twice?
>>
>> In Fortran, it could according to the language definition, as
>> long as parenthethes are kept. The language even allows to change
>> (x - x) into zero for floats, never mind NaNs.
>>
>> Few compilers dare to implement that.
>>
>> It would be illegal for y = (x + 3) - 2.
>
> That rule has always bothered me for a language with operator
> precedence. OP forces parens to resolve precedence: Fortran (b+c)*a is
> not the same as b+c*a, although it is in APL where there is no
> precedence.

I have used languages where extra parentheses sometimes make
a difference, and I share your reaction.

Benny Lyne Amorsen <benny+usenet@amorsen.dk> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> My sense is this idea is not much better than how things are
>> now. I would like to see the decision be under control of
>> the source code, perhaps by means of a #pragma:
>>
>> #pragma STDC SIGNED_OVERFLOW WRAP
>> #pragma STDC SIGNED_OVERFLOW TRAP
>> #pragma STDC SIGNED_OVERFLOW SATURATE
>> #pragma STDC SIGNED_OVERFLOW UNDEFINED
>> (..others?..)
>
> I think you are missing the most important one

The list was deliberately presented as not being complete.

> #pragma STDC SIGNED_OVERFLOW UNSPECIFIED
>
> Specifically the option that signed overflow results in a value within
> the bounds of the particular type. Which particular value does not
> matter and may vary.

I wouldn't mind that behavior being one of the choices. I don't
know how useful it would be, but if that's what someone wants it
seems reasonable to make it available to them.