On Wed, 20 Oct 2021 15:48:21 -0000 (UTC), John Levine
<johnl@taugh.com> wrote:

>These days desktop PCs are a shrinking niche. Everyone gets a laptop
>and you can't build one from parts. When I'm home my laptop is plugged
>into a real keyboard and mouse, a big screen, and a wired LAN. If I
>ever take a trip again, I can unplug it and have the same computer with
>me I have at home.

For given capability, the laptop costs 3..4 times as much as the
equivalent desktop (including keyboard, mouse, speakers, webcam, etc.
and even throwing in a decently large 20+ inch screen).

YMMV, but I think that is a very high premium to pay simply for
portability.

Even including software developers <wink>, the majority of business
users do not need portability and /should/ have desk units.
[I worked as a software developer for almost 15 years without having
or ever even using a laptop.]

Same with schools - the idea to give every child a laptop or pad is
just wasteful. For roughly 2/3 what they are currently spending on
portables, school systems could put thin terminals at every desk and
give every student a small desk computer to use at home.

Do *I* have a laptop? Of course ... but wrt capability it is not even
in the same ballpark as the mid-tower workstation at my desk - even
though I paid roughly the same amount for each of them.

George

On 10/21/2021 12:16 AM, George Neuner wrote:
> On Wed, 20 Oct 2021 15:48:21 -0000 (UTC), John Levine
> <johnl@taugh.com> wrote:
>
>
>> These days desktop PCs are a shrinking niche. Everyone gets a laptop
>> and you can't build one from parts. When I'm home my laptop is plugged
>> into a real keyboard and mouse, a big screen, and a wired LAN. If I
>> ever take a trip again, I can unplug it and have the same computer with
>> me I have at home.
>
> For given capability, the laptop costs 3..4 times as much as the
> equivalent desktop (including keyboard, mouse, speakers, webcam, etc.
> and even throwing in a decently large 20+ inch screen).
>
> YMMV, but I think that is a very high premium to pay simply for
> portability.
>

Agreed.

For around $500 in parts, one can build a decent-ish PC.
Or they can get a refurbished laptop with kinda meh hardware stats.

If one is willing to use some older second-hand or refurbished parts,
this cost can be reduced somewhat.

The last few "PC build" cycles, I had gotten CPUs from roughly one
generation prior. Mostly as after a new generation is released the older
generation gets cheaper.

So, Zen1 came out, FX suddenly got cheaper;
Zen2 came out, Zen1 suddenly got cheaper, ...

One could argue that a high-end chip from a prior generation is
(typically) a better value than a lower-end chip from a newer generation.

Or, at least it was this way in the past, not sure about the current
parts shortage.

> Even including software developers <wink>, the majority of business
> users do not need portability and /should/ have desk units.
> [I worked as a software developer for almost 15 years without having
> or ever even using a laptop.]
>

Agreed. Using a laptop as a primary PC would not be terribly helpful in
my mainline development efforts.

> Same with schools - the idea to give every child a laptop or pad is
> just wasteful. For roughly 2/3 what they are currently spending on
> portables, school systems could put thin terminals at every desk and
> give every student a small desk computer to use at home.
>

Do any schools actually do this?...

Usual thing on the news is schools having issues with inability to pay
teachers due to budget shortfalls and similar, inability to afford
textbooks, ...

>
> Do *I* have a laptop? Of course ... but wrt capability it is not even
> in the same ballpark as the mid-tower workstation at my desk - even
> though I paid roughly the same amount for each of them.
>

I have a laptop, it originally came with Vista and has 4GB of RAM and a
Celeron, and a "pretty much awful" Intel GMA graphics chip (struggles
running much of any games much newer than Quake3 or Half-Life; basically
incapable of running Minecraft).

IIRC, it was around $900, roughly 12 years ago.

Otherwise basically works at other "basic laptop tasks".

Granted, not even going to attempt trying to run Vivado on it though...

David Brown <david.brown@hesbynett.no> writes:
>On 20/10/2021 18:40, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [wrapping]
>>> It is a ring, not a field (division is not an inverse of multiplication,
>>> which is required for a field).
>>
>> By contrast, standard C signed integers are not even a magma (neither
>> for addition nor for multiplication). They are not closed.
>>
>
>Correct.
>
>I'm not quite sure what the correct mathematical term would be.

<https://en.wikipedia.org/wiki/Magma_(algebra)#Classification_by_properties>
provides three names of structures without totality: semigroupoid,
small category, and groupoid. They all require associativity, which
standard C integers do not provide, neither with + nor with *.

My guess is that every mathematician who researched such structures
found that they are mathematically uninteresting. But go ahead,
become famous by describing the interesting mathematical properties of
a non-closed non-associative algebra, how great they are for proofs
etc.

>It's a long time since I studied algebraic structures, but I don't think
>the field of mathematical algebra had much to say about partial
>functions or partial operations.

Obviously not about operations that are neither complete nor
associative.

>Perhaps it is something mathematicians
>should cover more - it's certainly critical to all kinds of things in
>the programming world.

I don't think so. Coming back to integers in computers, we have a
number of solutions:

* Bignums (a ring, as long as you supply enough memory) for those who
want Z.

* modular arithmetic (also a ring) aka wrapping, very useful in many
ways, including in its overflow behaviour, although there are some
who don't want to make use of the overflow behaviour.

* saturation (not associative, but at least closed), more useful than
modular in certain contexts.

* trapping (not associative; if you consider the trap to be a result,
you can consider it closed but it's a stretch). Probably most
useful to those who actually want Z, but think their numbers are
small enough that they can avoid the expense of Bignums.

And we have a non-solution, which is what the C standard provides.
This is fine, if you see the C standard for what it is, a very partial
specification that is to be completed elsewhere (as is done for, e.g.,
system calls). It's not fine if you see it as an excuse to dismiss
bug reports.

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>I think the fact that in 2021 you still have to list such anecdotes to
>argue that a 64bit ISA is needed argues in favor of my point ;-)

In that case, your belief that 32-bit is still sufficient for most
desktop users is non-falsifiable, i.e., it is a religious belief.

But just in case it isn't:

The first story is one where 35 bits worth of physical and virtual
memory is not enough, and for Emacs this corresponds to (I guess) 39
bits.

I ran into the limits of 32-bit Emacs several years before we switched
to a 64-bit machine for that job (in 2009 at the latest), long enough
earlier to notice that the limit was lower at first and was raised
with a later version of Emacs (don't remember which).

Runes of Magic was released in 2009 (closed beta in 2008). From the
beginning it crashed regularly because of lack of memory, but I
understand why they developed it as a 32-bit application at the time.

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

On 2021-10-21 0:39, Ivan Godard wrote:
> On 10/20/2021 11:12 AM, Niklas Holsti wrote:

[snip]

>> In Ada, untyped compile-time constants are considered to be of
>> "universal" integer or real types. Compile-time computation with such
>> numbers uses unbounded range and precision (bignums, in effect). A
>> literal constant used in a typed expression adopts the type of the
>> expression -- in effect, literal numbers are overloaded to be of any
>> desired numerical type, depending on the context.
>>
>> For example:
>>
>>     One_Third : constant := 1.0 / 3.0;
>>     -- A real number that is exactly 1/3, to any desired number of
>>     -- decimals (in effect, a rational number).
>>
>>     Ten_Thirds : constant := 10.0 * One_Third;
>>     -- Computed exactly at compile-time (as the rational 10/3).
>>
>>     F : Float := Ten_Thirds;
>>     -- F is initialized to the closest floating-point approximation
>>     -- of the rational number 10/3.
>>
>
> Never understood the problem with literals and types. The type  of 3 is
> "3".

That's pretty much the case in Ada, but the types of 3 and 3.0 are
different (universal integer vs. universal real).

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

> On 10/20/2021 7:47 AM, Tim Rentsch wrote:
>
>> Can you say what sorts of things Ada's type system lets you
>> accomplish, and what sorts of thing you would like it to do
>> that it doesn't? (I have just finished reading through the
>> part of the Ada reference manual that deals with types and
>> declarations.)
>
> Look at
>
> https://learn.adacore.com/courses/
> Ada_For_The_CPP_Java_Developer/chapters/05_Type_System.html
>
> for some examples.

I have used Ada-like type systems before. I just was wondering
what you in particular found useful.

> For me, things like ranges are really nice. They allow you to
> specify say the number of elements in an array and the conditions
> for a loop over that array with the same, hopefully meaningful
> syntax, that very much eases maintenance changes. For example,
> say you have a store with currently 10 types of products. You can
> define a variable "ProductType" as having a range of 1-10. An
> array of product type names would be dimensioned not with a
> number, but with a meaningful name. When you want to loop over
> the array of product types, instead of saying 1-10, you just give
> the same variable name. Then if you add an eleventh product type
> later, you only have to change one place instead of say trying to
> find all the occurrences of "10", checking if they are relevant,
> then changing some of them to "11".
>
> They also address the issues of things like the overflow that we
> have been discussing as a "subset" of a more general case.
> i.e. an unsigned 8 bit variable is just one with a range of 0-255.
>
> I also like the ability to specify some variables as modular,
> which addresses some of the overflow semantics.
>
> And, it can catch some programming errors at compile time that,
> languages with lesser type systems leave unspecified and error
> prone.
>
> And I really like that it doesn't use pointers for array accesses,
> which prevents a many buffer overflow type problems.

I believe it is the case that none of these properties addresses
the matter of differentiating (as one example) wrapping signed
operations versus saturating signed operations. AFAICT the Ada
type system doesn't help in any significant way in addressing
this issue. Do you think that's right, or is there something I
have overlooked?

Anton Ertl [2021-10-21 09:26:04] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think the fact that in 2021 you still have to list such anecdotes to
>> argue that a 64bit ISA is needed argues in favor of my point ;-)
> In that case, your belief that 32-bit is still sufficient for most
> desktop users is non-falsifiable, i.e., it is a religious belief.

You're probably right.

[ Tho as much as it pains me to admit it, most desktop users don't use
Emacs, and I think this is *despite* my religion. ]

My religion also tells me that for those mythical "most desktop users"
the largest process is likely to be the web browser (and if we had to
do with a 32bit ISA, I suspect that those browsers would be split into
fewer threads and more processes).

Stefan

> I ran into the limits of 32-bit Emacs several years before we switched
> to a 64-bit machine for that job (in 2009 at the latest), long enough
> earlier to notice that the limit was lower at first and was raised
> with a later version of Emacs (don't remember which).

AFAIK Emacs's memory use should only ever get near or past the 32bit
limit if you edit files that are themselves large (that's because Emacs's
heap management is quite primitive so if the heap itself (which doesn't
include the buffers's text) grows to such large values Emacs tends to
become unusable because of the GC freezes).
Back in the 32bit days, there were already files >4GB of course
[actually, for a 32bit build, Emacs's limit is 512MB files], and Emacs
users just refrained from using Emacs to view or edit such large files
(tho some users developed workarounds such as `vlf.el` which lets you
view a chunk of the file).

> * trapping (not associative; if you consider the trap to be a result,
> you can consider it closed but it's a stretch). Probably most
> useful to those who actually want Z, but think their numbers are
> small enough that they can avoid the expense of Bignums.

From the language's point of view, there is also a distinction to be
made between trapping in a way that can be observed (e.g. an exception
that can be caught and handled) and trapping in a way that can't be
observed from within the program because it terminates the program
(arguably comparable to a bignum when you run out of memory).

The observable kind is not "optimizable" whereas the non-observable one
is to some extent (at least as long as the optimization reduces rather
than increases the cases where the program terminates prematurely).

Stefan

On 10/21/2021 5:39 AM, Tim Rentsch wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>
>> On 10/20/2021 7:47 AM, Tim Rentsch wrote:
>>
>>> Can you say what sorts of things Ada's type system lets you
>>> accomplish, and what sorts of thing you would like it to do
>>> that it doesn't? (I have just finished reading through the
>>> part of the Ada reference manual that deals with types and
>>> declarations.)
>>
>> Look at
>>
>> https://learn.adacore.com/courses/
>> Ada_For_The_CPP_Java_Developer/chapters/05_Type_System.html
>>
>> for some examples.
>
> I have used Ada-like type systems before. I just was wondering
> what you in particular found useful.

Oh, sorry. I misinterpreted what you asked for.

>> For me, things like ranges are really nice. They allow you to
>> specify say the number of elements in an array and the conditions
>> for a loop over that array with the same, hopefully meaningful
>> syntax, that very much eases maintenance changes. For example,
>> say you have a store with currently 10 types of products. You can
>> define a variable "ProductType" as having a range of 1-10. An
>> array of product type names would be dimensioned not with a
>> number, but with a meaningful name. When you want to loop over
>> the array of product types, instead of saying 1-10, you just give
>> the same variable name. Then if you add an eleventh product type
>> later, you only have to change one place instead of say trying to
>> find all the occurrences of "10", checking if they are relevant,
>> then changing some of them to "11".
>>
>> They also address the issues of things like the overflow that we
>> have been discussing as a "subset" of a more general case.
>> i.e. an unsigned 8 bit variable is just one with a range of 0-255.
>>
>> I also like the ability to specify some variables as modular,
>> which addresses some of the overflow semantics.
>>
>> And, it can catch some programming errors at compile time that,
>> languages with lesser type systems leave unspecified and error
>> prone.
>>
>> And I really like that it doesn't use pointers for array accesses,
>> which prevents a many buffer overflow type problems.
>
> I believe it is the case that none of these properties addresses
> the matter of differentiating (as one example) wrapping signed
> operations versus saturating signed operations. AFAICT the Ada
> type system doesn't help in any significant way in addressing
> this issue. Do you think that's right, or is there something I
> have overlooked?

I confess that I personally never had to worry about that particular
issue, as it just didn't come up in the kind of programming I did. And
my understanding of Ada is more theoretical than actual. So I can't
really help in answering your question. Perhaps others more familiar
with the details can provide the answer you are looking for.

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

Stefan Monnier wrote:
> Anton Ertl [2021-10-21 09:26:04] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I think the fact that in 2021 you still have to list such anecdotes to
>>> argue that a 64bit ISA is needed argues in favor of my point ;-)
>> In that case, your belief that 32-bit is still sufficient for most
>> desktop users is non-falsifiable, i.e., it is a religious belief.
>
> You're probably right.
>
> [ Tho as much as it pains me to admit it, most desktop users don't use
> Emacs, and I think this is *despite* my religion. ]
>
> My religion also tells me that for those mythical "most desktop users"
> the largest process is likely to be the web browser (and if we had to
> do with a 32bit ISA, I suspect that those browsers would be split into
> fewer threads and more processes).
>
>
> Stefan
>
>
>> I ran into the limits of 32-bit Emacs several years before we switched
>> to a 64-bit machine for that job (in 2009 at the latest), long enough
>> earlier to notice that the limit was lower at first and was raised
>> with a later version of Emacs (don't remember which).
>
> AFAIK Emacs's memory use should only ever get near or past the 32bit
> limit if you edit files that are themselves large (that's because Emacs's
> heap management is quite primitive so if the heap itself (which doesn't
> include the buffers's text) grows to such large values Emacs tends to
> become unusable because of the GC freezes).
> Back in the 32bit days, there were already files >4GB of course
> [actually, for a 32bit build, Emacs's limit is 512MB files], and Emacs
> users just refrained from using Emacs to view or edit such large files
> (tho some users developed workarounds such as `vlf.el` which lets you
> view a chunk of the file).

It sounds like it is trying to map whole files rather than
managing moving windows onto mapped files or buffered IO.

On 2021-10-21 15:39, Tim Rentsch wrote:

> I believe it is the case that none of these properties [of the Ada
> type system] addresses the matter of differentiating (as one example)
> wrapping signed operations versus saturating signed operations.
> AFAICT the Ada type system doesn't help in any significant way in
> addressing this issue.

Ada has two kinds of built-in integer types: signed integer types and
modular integer types.

While a signed integer type can be constrained to a non-negative range
by subtyping, it still uses signed integer operations and
representations, and the results of expressions can be negative. The
range is checked only when a value is assigned to a variable of the
subtype, or passed as a parameter of the subtype, or in other similar
subtype-constrained contexts.

Signed integer overflow or underflow are required to raise the
Constraint_Error exception. There are no built-in options for signed
wrap-around or saturation, but one can of course define one's own types
with such operations overloading "+", "-" etc.)

Modular integer types are truly unsigned and all operations produce
non-negative results, using modular arithmetic (wrapping), and never
raise exceptions (except for division by zero). The modulus can be any
positive number, not necessarily a power of two, but must be known at
compile time (a static expression).

The upcoming new Ada standard, Ada 2022, adds standard libraries for
big-number arithmetic, both integer and real.

For the point under discussion, it seems to me that the main difference
between C and Ada is that signed overflow is undefined behaviour in the
C standard, but in Ada is required to raise an exception.

On 10/21/2021 8:23 AM, Niklas Holsti wrote:
> On 2021-10-21 15:39, Tim Rentsch wrote:
>
>> I believe it is the case that none of these properties [of the Ada
>> type system] addresses the matter of differentiating (as one example)
>> wrapping signed operations versus saturating signed operations.
>> AFAICT the Ada type system doesn't help in any significant way in
>> addressing this issue.
>
>
> Ada has two kinds of built-in integer types: signed integer types and
> modular integer types.
>
> While a signed integer type can be constrained to a non-negative range
> by subtyping, it still uses signed integer operations and
> representations, and the results of expressions can be negative. The
> range is checked only when a value is assigned to a variable of the
> subtype, or passed as a parameter of the subtype, or in other similar
> subtype-constrained contexts.

I may have asked this some time ago (My memory isn't what it used to
be), but then presumably

If A,B,C and D are all signed integers, and D has a range subtype, then

D = A + B - C is not the same as

D = A + B
D = D - C

in that the second range checks the intermediate value, but the first
doesn't. And the compiler understands that and won't optimize the
second into the first (unless it knows from some other information that
the range can't be exceeded).

Is that correct?

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> * trapping (not associative; if you consider the trap to be a result,
>> you can consider it closed but it's a stretch). Probably most
>> useful to those who actually want Z, but think their numbers are
>> small enough that they can avoid the expense of Bignums.
>
>From the language's point of view, there is also a distinction to be
>made between trapping in a way that can be observed (e.g. an exception
>that can be caught and handled) and trapping in a way that can't be
>observed from within the program because it terminates the program
>(arguably comparable to a bignum when you run out of memory).

Taking a step back from the language to the intent of the programmer,
there are a) those cases where the programmer does not intend a trap
to happen (it's more an accident of having too-large numbers), and b)
those were the programmer does intend a trap to happen; there is also
the question of what to do on an overflow trap. You may be right that
if there is no handler for the condition, the intent is probably a).
If there is a handler, it's harder to tell. The conservative
assumption is b).

Getting back to the language level, if you don't want to go with
conservative assumptions (or worse, aggressive assumptions like have
become fashionable among C compiler writers), you need a way to make
the actual intent explicit. But I am not sure if that is worth the
language complication in this case.

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

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>Anton Ertl [2021-10-21 09:26:04] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> I think the fact that in 2021 you still have to list such anecdotes to
>>> argue that a 64bit ISA is needed argues in favor of my point ;-)
>> In that case, your belief that 32-bit is still sufficient for most
>> desktop users is non-falsifiable, i.e., it is a religious belief.
>
>You're probably right.
>
>[ Tho as much as it pains me to admit it, most desktop users don't use
> Emacs, and I think this is *despite* my religion. ]
>
>My religion also tells me that for those mythical "most desktop users"
>the largest process is likely to be the web browser (and if we had to
>do with a 32bit ISA, I suspect that those browsers would be split into
>fewer threads and more processes).

Remember the case of my collegue who bought a new laptop in order to
be able to deal with his mailbox. But in my case, at the moment you
are right: On my Laptop the process with the biggest VIRTual size is
firefox (5.7GB).

And sure, you could just as well tell the server programmers to use
multiple processes to work around the limits of 32 bits, and then
triumph, and say that 64-bit is unnecessary.

And then have a glorified PAE that allows to access 24TB or 40TB (and
you can probably find the things Linus Torvalds had to say about PAE).

All of this costs programming effort (and development money), but
everyone will gladly pay this as a tithe to the 32-bit religion.

>> I ran into the limits of 32-bit Emacs several years before we switched
>> to a 64-bit machine for that job (in 2009 at the latest), long enough
>> earlier to notice that the limit was lower at first and was raised
>> with a later version of Emacs (don't remember which).
>
>AFAIK Emacs's memory use should only ever get near or past the 32bit
>limit if you edit files that are themselves large (that's because Emacs's
>heap management is quite primitive so if the heap itself (which doesn't
>include the buffers's text) grows to such large values Emacs tends to
>become unusable because of the GC freezes).

Yes, I edit large files. The unusability took the form that emacs
fails to load the large file (which is nicer than some other kinds of
unusability).

>Back in the 32bit days, there were already files >4GB of course
>[actually, for a 32bit build, Emacs's limit is 512MB files], and Emacs
>users just refrained from using Emacs to view or edit such large files

That is certainly a sacrifice we are willing to make for the 32-bit
religion.

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

> And sure, you could just as well tell the server programmers to use
> multiple processes to work around the limits of 32 bits, and then
> triumph, and say that 64-bit is unnecessary.

Just to clarify: I did not intend to say that 64bit is unnecessary.
I was only talking about the delay between:
(A) 32bit is creating major problems for big machines
(A) 32bit is creating major problems for the mass market

The delay between introduction of 64bit ISAs in big machines and mass
market machines can be estimated as 12 years (1991 for R4000 and 2003
for Opteron), and it would arguably have been shorter if Intel had
taken a lead on x86-64 instead of promoting Itanium.
But I think the delay between A and B has been much longer, and I don't
think that was expected: it's been due to the slowdown in Moore's law,
Dennard scaling and such, right around that time.

I suspect that for the 64bit limit, the corresponding delay could be
much longer. And I wonder what it would imply since currently the ISA
is usually the same across most of the spectrum (from smartphones to
supercomputers): would it mean that we'd see new 128bit ISAs dedicated
to big machines, or that mass market machines will grow a 128bit ISA
several decades before they bump into the 64bit address space limit,
just for the benefit of big machines?

Stefan

On 2021-10-21 18:54, Stephen Fuld wrote:
> On 10/21/2021 8:23 AM, Niklas Holsti wrote:
>> On 2021-10-21 15:39, Tim Rentsch wrote:
>>
>>> I believe it is the case that none of these properties [of the Ada
>>> type system] addresses the matter of differentiating (as one example)
>>> wrapping signed operations versus saturating signed operations.
>>> AFAICT the Ada type system doesn't help in any significant way in
>>> addressing this issue.
>>
>>
>> Ada has two kinds of built-in integer types: signed integer types and
>> modular integer types.
>>
>> While a signed integer type can be constrained to a non-negative range
>> by subtyping, it still uses signed integer operations and
>> representations, and the results of expressions can be negative. The
>> range is checked only when a value is assigned to a variable of the
>> subtype, or passed as a parameter of the subtype, or in other similar
>> subtype-constrained contexts.
>
> I may have asked this some time ago (My memory isn't what it used to
> be), but then presumably
>
> If A,B,C and D are all signed integers, and D has a range subtype, then
>
> D = A + B - C   is not the same as
>
> D = A + B
> D = D - C
>
> in that the second range checks the intermediate value, but the first
> doesn't.

Rather, the second form _might_ range-check the intermediate value, but
also might not.

> And the compiler understands that and won't optimize the
> second into the first (unless it knows from some other information that
> the range can't be exceeded).
>
> Is that correct?

As I understand it, if the compiler can generate code that combines the
two assignments into one assignment to D, while ensuring that the
mathematically correct final value, (A+B)-C, is used in the remaining
assignment, it can do so even if the intermediate result (A+B) violates
the range of D. This is a consequence of a general rule in the Ada
standard that lets the compiler omit all range checks on internal
computations as long as the final observable behaviour is correct (and
involves no erroneous execution such as array index range violations).

I believe that in principle the two assignments can be combined even if
the intermediate result wraps around, as long as the final result is
correct, as if computed with unbounded range and no wrap-around. An
overflow/underflow exception is required only if the mathematically
correct result cannot be produced for the final assignment to D. In
practice I expect that any signed arithmetic operator that overflows or
underflows will raise an exception.

However, if D is marked as volatile, then of course the two assignments
cannot be combined, and each includes a range check.

Further however, some non-optimizing compilers might not combine the two
assignments with a non-volatile D, in which case an exception would be
raised if A+B violates the range of D in the first assignment.

One corollary of these rules is that in Ada one should never use (just)
an assignment to check that a certain value is in a certain range,
because the compiler might combine that assignment into a later
assignment, or omit the assignment entirely if the assigned value is not
used later. One can instead use the range test, "if X in T then ...", to
check if the value X is in the range of the subtype T, or put the
condition "X in T" in an assertion.

It appears that George Neuner <gneuner2@comcast.net> said:
>>These days desktop PCs are a shrinking niche. ...

>YMMV, but I think that is a very high premium to pay simply for
>portability. ...

I think the people reading comp.arch are a very skewed subset of computer
users. Typical users run browsers, spreadsheets, word processing,
and these days zoom and slack or teams, all of which work fine on a $400 laptop.

>Same with schools - the idea to give every child a laptop or pad is
>just wasteful. For roughly 2/3 what they are currently spending on
>portables, school systems could put thin terminals at every desk

I don't get the impression you have priced chromebooks lately. Best
Buy has a low end one with an 11" screen and 4GB RAM for $99, and a
bunch of 14" for $149. Of course, a chromebook basically *is* a thin
terminal.

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

John Levine <johnl@taugh.com> schrieb:
> It appears that George Neuner <gneuner2@comcast.net> said:
>>>These days desktop PCs are a shrinking niche. ...
>
>>YMMV, but I think that is a very high premium to pay simply for
>>portability. ...
>
> I think the people reading comp.arch are a very skewed subset of computer
> users. Typical users run browsers, spreadsheets, word processing,
> and these days zoom and slack or teams, all of which work fine on a $400 laptop.

Teams, Office and a browser almost require 16 GB these days for
smooth working, I have found.

On Saturday, October 16, 2021 at 8:21:31 AM UTC-5, chris wrote:
> On 10/15/21 22:35, Anton Ertl wrote:
> > cla...@hotmail.com writes:
> >> What possessed creators of AIX to make address zero readable
> >
> > Omagic (and IIRC the NMAGIC) a.out format starts at address 0; it took
> > until ZMAGIC to start elsewhere.
> >
> > When Unix acquired virtual memory (on the VAX), there was no urgent
> > need to change the memory layout, so being able to access 0 is one of
> > the features that were denounced as Vaxocentrism.
> Well, address zero is the start of the interrupt vector table. On
> pdp11 as well and early 68K, though later 68K had a register to
> point to the start. Perhaps not so unusual after all...
<
The problem, here, is that the IVT,... should not be in the SAME
address space as user memory.
> >
> > It's not surprising that a commercial Unix like AIX also implemented
> > this feature. After all, they wanted to run the software available
> > for the mainstream of Unix.
> >
> > What is more surprising is that the Unix community then switched to a
> > consensus that the first page is not accessible.
> >
> >> and thus
> >> completely breaking the expectations of Mono?
> >
> > Mono (2004) came several decades after Unix (1970), Unix on VAX
> > (~1980), and AIX (1986). Could it be that Mono is Linux-centric?
<
Mono sounds like a disease that teenagers get.......
> >
> > - anton

On Saturday, October 16, 2021 at 8:52:24 AM UTC-5, Anton Ertl wrote:
> Victor Yodaiken <victor....@gmail.com> writes:
> >1. Why do I have to pay the price of snooping cache everywhere when programs don't
> >usually share much memory?
<
User programs like to read and write files. If the cache is not snooped,
the overhead of making sure the data is in memory for the I/O device
to access is excessive.
<
> I think there has been hardware without any cache consistency. This
> has pretty much died out. Apparently it's cheap enough to provide
> cache consistency (through snooping or other techniques, such as
> directories) for the number of CPUs available in shared-memory
> machines, and too hard for software to deal with total lack of cache
> consistency.
<
Correct, it is cheaper to "make the entirety" of the problem go away by
throwing HW at the problem, than to even have a meeting on making SW
do all the dirty work.
>
> But it seems to me the more common approach of those who shied away
> from cache consistency has been to use private memory and message
> passing. This may be ok for some supercomputer applications, but is
> not particularly useful in general; IBM and Sony tried it with the
> Cell architecture, but game programmers found it too hard to use.
>
> But on another level your wish has been granted. Hardware people
> don't give us sequential consistency between cores, but more or less
> weaker memory models, and instructions for achieving more consistency
> (up to sequential consistency) where needed.
<
By the time an LD (or ST) has been AGENed, the FETCH unit could be
several hundred instructions ahead. So HW has no reasonable guarantee
of snooping FETCH stream.
<
Larger GBOoO machines may not even compute the addresses in a
reasonable order. yet optimistically fetch data on cache misses even
when the memory reference could be abandoned (mispredict shadow)
by the time memory data arrives.
<
Sequential consistency adds latency and subtracts performance.
>
> Unfortunately, these instructions are quite slow, which results in a
> bad situation for programmers: They should at the same time minimize
> the use as many of these instructions as necessary while minimizing
> their use in order to avoid slowdowns; and the bad thing about that
> situation is that it is hard to tell if you have used enough of these
> instructions in the right places if you try to minimize them. So the
> situation is:
<
Errrrrr, not quite.....
<
The real problem is the HW has no way of knowing if a vanilla LD
requires SC, or even coherence because there are no encoding bits
to carry this information. Thus, one has to resort to making performance
ROBBING decisions because there was no room. {In addition, languages
do not have facilities in which these requirements can be manifest.
That is: if this LD requires SC, then the source code should specify
that SC is required on that memory reference.}
<
In the RISC tradition:: why not make instructions that require these
kinds of added detail take more bits that the vanilla instructions
that do not ??
>
> * If you want to be sure that you have enough of these instructions,
> just put them everywhere in your shared-memory access code; as a
> result, your program will crawl if it accesses the shared-memory
> stuff with any frequency at all.
>
> * Or you try to minimize the use of these instructions, and risk that
> you opened up your program to some inconsistency, which is hard to
> test for and debug.
>
> There has been some work on sequential consistency in hardware
> [daya+14], but my impression is that we will not such features in
> commercial hardware unless this becomes a sellable feature. For now
> they seem to be content with the situation that a few specialists
> puzzle out the problem described above, and the masses program
> sequentially or at best by calling libraries written be the
> specialists.
>
> Of course, one might provide other features rather than sequential
> consistency, and Intel made a go at it with TSX. But unfortunately
> that seems to be too hard to implement. E.g., it is disabled in the
> 1135G7 CPU of my laptop and is not even mentioned on
> <https://ark.intel.com/content/www/us/en/ark/products/208658/intel-core-i5-1135g7-processor-8m-cache-up-to-4-20-ghz.html>;
> it's at least mentioned on
> <https://ark.intel.com/content/www/us/en/ark/products/212261/intel-xeon-e2378-processor-16m-cache-2-60-ghz.html>,
> but disabled.
>
> @InProceedings{daya+14,
> author = {Bhavya K. Daya and Chia-Hsin Owen Chen and Suvinay
> Subramanian and Woo-Cheol Kwon and Sunghyun Park and
> Tushar Krishna and Jim Holt and Anantha
> P. Chandrakasan and L-Shiuan Peh},
> title = {{SCORPIO}: A 36-Core Research-Chip Demonstrating
> Snoopy Coherence on a Scalable Mesh {NoC} with
> In-Network Ordering},
> crossref = {isca14},
> OPTpages = {},
> url = {http://projects.csail.mit.edu/wiki/pub/LSPgroup/PublicationList/scorpio_isca2014.pdf},
> annote = {The cores on the chip described in this paper access
> their shared memory in a sequentially consistent
> manner; what's more, the chip provides a significant
> speedup in comparison to the distributed directory
> and HyperTransport coherence protocols. The main
> idea is to deal with the ordering separately from
> the data, in a distributed way. The ordering
> messages are relatively small (one bit per core).
> For details see the paper.}
> }
>
> >2. with the increasing numbers of registers, shouldn't we have a dirty bit so
> >a process can save register state more efficiently with a "save-dirty-registers"
> >instruction and a "fetch bitmap; load-saved-registers" instruction? Or otherwise reduce
> >the expense of context switch?
> Did not work well for the VAX call instruction, why should it work
> better now? CPUs have become better since that time at processing
> blocks of data unconditionally, but not so much better at doing it
> conditionally: a VAX instruction typically took 10 cycles; store and
> load throughput currently typically is at 1-3 per cycle, while a
> mispredicted branch costs around 20 cycles.
<
If you can save ¼ of the register file in a single cycle, you have
eliminated the need for ready bits--but notice if you can do this
dirty bits create work...............
<
> >3. Why is device IO so effin complex if devices are getting smarter.
> I don't know much about this, but I can think of two contributing
> factors:
>
> * Simple device interfaces would be slow, because round trips to I/O
> are slow thanks to I/O being relatively far from the CPU core (and
> these paths being not as optimized, and I/O-devices being slow). So
> one invents "smart" interfaces that result in fewer round-trips, but
> these are by necessity more complex than the simple interfaces.
>
> * There is little pressure to make a good design for these device
> interfaces. For Windows and Android the hardware manufacturers
> develop the device driver themselves, so the hardware people can
> just tell their software people: This is the hardware, deal with it.
> And the free software people tend to also just deal with it, because
> device availability (thanks to Windows or Android) trumps easy
> programming.
> - anton
> --
> 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7...@googlegroups.com>

On Saturday, October 16, 2021 at 9:52:18 AM UTC-5, Ivan Godard wrote:
> On 10/16/2021 7:21 AM, Stephen Fuld wrote:
> > On 10/16/2021 3:49 AM, Thomas Koenig wrote:
> >> MitchAlsup <Mitch...@aol.com> schrieb:

> >> Ideas? Comments?
> >
> > The run time cost of things like buffer overrun checking is reduced on
> > modern OoO CPUs, as (assuming the compiler makes the information
> > available) the checking can be done in parallel with the subsequent
> > instructions, and only commit those instructions if the check passes.
> > The same idea might help with the signed overflow problems.
<
Real HW designers have been doing that since at least 1990............
<
> Signed overflow does not require delayed check; it requires control of
> delivery of the checked event. Not everything is vanilla C; there are
> other languages with other rules, and even in C there are pragmas and
> flags. So sometimes you should check and sometimes not, and you can't
> afford control flow to decide.
<
There was an argument in 16-bit machines, that became harder in 32-bit
machine, that becomes indefensible in 64-bit machines:: not performing
signed overflow/underflow checks.

On Saturday, October 16, 2021 at 3:28:37 PM UTC-5, Niklas Holsti wrote:
> On 2021-10-16 20:49, Thomas Koenig wrote:
> > Anton Ertl <an...@mips.complang.tuwien.ac.at> schrieb:
> >> Thomas Koenig <tko...@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.
> >
> > $ cat mm.f90
> > module mm
> > implicit none
> > contains
> > subroutine do_mm (a,b,c)
> > real, dimension(:,:), intent(in) :: a, b
> > real, dimension(:,:), intent(out) :: c
> (Btw, shouldn't C be "in out"? I got a correct warning from GNAT when I
> made it just "in".)
<
You have 2 choices:
1) C needs to be in-out (because it is not initialized anywhere in do_mm)
2) C is out but there needs to be an initializer of c(i,j) in the loops.
<
> > integer :: i, j, k
> > do j=1, size(b,2)
> > do k=1, size(a,2)
> > do i=1, size(a,1)
> > c(i,j) = c(i,j) + a(i,k) * b(k,j)
> > end do
> > end do
> > end do
> > end subroutine do_mm
> > end module mm
> >
> > $ cat main.f90
> > program main
> > use mm
> > implicit none
> > real, dimension(:,:), allocatable :: a, b, c
> > character (len=20) :: line
> > real :: t1, t2
> > allocate (a(1000,1000), b(1000,1000), c(1000,1000))
> > call random_number (a)
> > call random_number (b)
> > call cpu_time (t1)
> > call do_mm(a,b,c)
> > call cpu_time (t2)
> > write (unit=line,fmt=*) c(1,1)
> > write (*,*) t2-t1
> > end program main
> > $ gfortran -O3 mm.f90 main.f90
> > $ ./a.out
> > 9.59559977E-02
> > $ gfortran -fcheck=bounds -O3 mm.f90 main.f90
> > $ ./a.out
> > 0.563069999
> >
> > Is a factor of 5.8 significant enough for you?
> With Ada/GNAT -O2 on a small MacBook Air, I found no significant
> slow-down from all checks suppressed (-gnatp) to checks on (-gnato),
> compared to the standard deviation in 10 test executions of each case.
> This is a bit surprising, but nice (if true). The program did steadily
> use close to 100% of a processor core, so it seems there was scant
> interference from other jobs. The absolute times are all larger than in
> the Fortran case, above, but of course the computers are different too.
>
> Program follows. Note that I added some preconditions to Do_MM, on the
> sanity of the matrix index ranges. However, these seem to have no
> significant effect on the execution time, whether checks are enabled or
> suppressed.
>
> $ cat mm.ads
>
> package MM is
>
> type Matrix is array (Positive range <>, Positive range <>) of Float;
>
> procedure Randomize (M : out Matrix);
>
> procedure Do_MM (A, B : in Matrix; C : in out Matrix)
> with Pre =>
> A'First(2) = B'First(1)
> and A'Last (2) = B'Last (1)
> and C'First(1) = A'First(1)
> and C'Last (1) = A'Last (1)
> and C'First(2) = B'First(2)
> and C'Last (2) = B'Last (2);
>
> end MM;
>
>
> $ cat mm.adb
> with Ada.Numerics.Float_Random;
>
> package body MM is
>
> procedure Randomize (M : out Matrix)
> is
> use Ada.Numerics.Float_Random;
> Gen : Generator;
> begin
> Reset (Gen);
> for I in M'Range(1) loop
> for J in M'Range(2) loop
> M(I,J) := Random (Gen);
> end loop;
> end loop;
> end Randomize;
>
>
> procedure Do_MM (A, B : in Matrix; C : in out Matrix)
> is
> begin
> for J in B'Range(2) loop
> for K in A'Range(2) loop
> for I in A'Range(1) loop
> C(I,J) := C(I,J) + A(I,K) * B(K,J);
> end loop;
> end loop;
> end loop;
> end Do_MM;
>
> end MM;
>
>
> $ cat main.adb
> with Ada.Real_Time;
> with Ada.Text_IO;
>
> with MM;
>
> procedure Main
> is
> use Ada.Real_Time;
> type Matrix_Ref is access MM.Matrix;
> A, B, C : Matrix_Ref := new MM.Matrix (1 .. 1000, 1 .. 1000);
> T1, T2: Time with Volatile;
>
> begin
>
> MM.Randomize (A.all);
> MM.Randomize (B.all);
> MM.Randomize (C.all);
>
> T1 := Clock;
> MM.Do_MM (A.all, B.all, C.all);
> T2 := Clock;
>
> Ada.Text_IO.Put_Line (Duration'Image (
> To_Duration (T2 - T1)));
>
> end Main;

On Saturday, October 16, 2021 at 10:19:56 PM UTC-5, Branimir Maksimovic wrote:
> On 2021-10-15, MitchAlsup <Mitch...@aol.com> wrote:
> > You know, there is a very fine NG suited to discuss the nuances of C,
> > what it is, what it is not, and what has been left grey {intentionally,
> > or by omission}: comp.lan.c
> >
> > This, however, is a NG devoted to architectures that can run C and
> > all sorts of other languages. Architectures and implementations of
> > those architectures.
> >
> > It should a design goal of any architect to provide an efficient and
> > straightforward instruction set that enables compilers to produce
> > small, efficient, correct applications from a given set of source code.
> >
> > The past has taught us that a deft hand is required to put in enough
> > "stuff" to make the expression of the compiler efficient, and leave
> > out enough "stuff" to allow the implementations to be fast and
> > efficient. This paragraph should be what a discussion of what C in
> > this NG should be is about--what goes in ISA to make the compiler's
> > expression efficient, and what stays out of ISA that makes the
> > implementations efficient.
> >
> > I would suggest what stays out and what goes ISA in has changed
> > "a bit" since the RISC revolution burst onto the scene and then withered.
>
> RISC is for compilers CISC for HUMANS :P
<
RISC is easier to read and to write than CISC.
> --
>
> 7-77-777
> Evil Sinner!
> with software, you repeat same experiment, expecting different results...

On Tuesday, October 12, 2021 at 11:26:17 AM UTC-6, Stefan Monnier wrote:

> I think the solution involves going carefully over every case of UB
> and refining it (on a case-by-case basis) so it still provides the
> freedom the compilers need while giving sufficient guarantees for the
> programmers when they know the properties of their underlying system
> (e.g. so they can write code which depends on a flat address space
> without fearing the compiler).
>
> This is hard work and I'm not volunteering.

I do not blame you for not volunteering for this task.

But I think your characterization of it as "hard work" may be
less than accurate.

It certainly is possible to write a compiler for "old-fashioned" C
that still has some optimization capabilities, enough to make it
useful. But I think it is clear that what the two camps in this
particular conflict want are incompatible, and can only be
resolved by having at the least a compiler switch, and at the
most by having two separate languages.

So I think the task of defining every case of undefined behavior
so as to make both sides happy is not difficult, but impossible.

John Savard

On 2021-10-22, MitchAlsup <MitchAlsup@aol.com> wrote:
> On Saturday, October 16, 2021 at 10:19:56 PM UTC-5, Branimir Maksimovic wrote:
>> On 2021-10-15, MitchAlsup <Mitch...@aol.com> wrote:
>> > You know, there is a very fine NG suited to discuss the nuances of C,
>> > what it is, what it is not, and what has been left grey {intentionally,
>> > or by omission}: comp.lan.c
>> >
>> > This, however, is a NG devoted to architectures that can run C and
>> > all sorts of other languages. Architectures and implementations of
>> > those architectures.
>> >
>> > It should a design goal of any architect to provide an efficient and
>> > straightforward instruction set that enables compilers to produce
>> > small, efficient, correct applications from a given set of source code.
>> >
>> > The past has taught us that a deft hand is required to put in enough
>> > "stuff" to make the expression of the compiler efficient, and leave
>> > out enough "stuff" to allow the implementations to be fast and
>> > efficient. This paragraph should be what a discussion of what C in
>> > this NG should be is about--what goes in ISA to make the compiler's
>> > expression efficient, and what stays out of ISA that makes the
>> > implementations efficient.
>> >
>> > I would suggest what stays out and what goes ISA in has changed
>> > "a bit" since the RISC revolution burst onto the scene and then withered.
>>
>> RISC is for compilers CISC for HUMANS :P
><
> RISC is easier to read and to write than CISC.
That is why compilers are better on RISC :P

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...