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

> On 10/19/2021 9:20 AM, EricP wrote:
>
>> Ivan Godard wrote:
>>
>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>
>>>> 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.
>>>
>>> As for example:
>>> enumWithTraits(intNumEnums, overflowCode,
>>> excepting,
>>> modulo,
>>> saturating,
>>> widening
>>> );
>>> available in every kind of operation that can overflow?
>>
>> I don't know what you mean.
>>
>> I mean that only the programmer knows their intent and since
>> that intent changes and they need a way to express it.
>> A one-size-fits-all approach isn't flexible enough.
>>
>> The compiler already handles overloading operators for different
>> integral and float data types and sizes. This expands on that mechanism.
>
> I think the disconnect is the following. Ivan showed what
> capabilities are/will be in the Mill hardware ISA. You talked about
> what the programmer intends. The disconnect is that the current C
> language doesn't provide a mechanism to "connect" the two, at least in
> many cases. [..]

This reminds me of something Butler Lampson said when asked
about ways of defining language extensions. He said, "We
already have that. They're called procedures. They work
great."

> I should note that at least a good part of these are specifiable in,
> for example Ada. The very extensive type system in Ada is, IMO one of
> its biggest strengths.

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

According to BGB <cr88192@gmail.com>:
>> 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.

No, they're people who do stuff that Macs do well. In my case, I have a
Mac because it is a full Unix system underneath, with well supported versions
of browsers and mail programs and all the other stuff you need. I have
used linux on laptops which works mostly, and the browsers and stuff work,
usually. Other people have Macs because they are doing graphic design or
video editing where the Mac apps are way better than the alternative.

Also, Macs last a long time. A five year old Mac works fine, and is fully
supported by current software.

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

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.

R's,
John
--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

According to Michael S <already5chosen@yahoo.com>:
>On Wednesday, October 20, 2021 at 4:58:07 AM UTC+3, John Levine wrote:
>> 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?

The redbook says Max190 can have 5 processor drawers with
a total of 40TB. I have no idea what size machines people
actually buy.

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

Ivan Godard wrote:
> 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. Don't you find that precedence parens masquerading as
> optimization-control parens sometimes engender bad code?

It provides an easy mechanism for programmer to pass intent to a compiler.
Historically mostly useful for floating point,
but could be used for overflow and saturating integers too.

It wouldn't work well as a default behavior in C because
macros use so many parens.

Do you have an alternative idea of how to succinctly instruct
that this expression precedence must be interpreted as given?
One could add a reserved word to a language like "exact (expression)"
but that would get tedious if you were writing hundreds of thousands
or millions of lines of weather or black hole simulations.

On 10/20/2021 7:47 AM, Tim Rentsch wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>
>> On 10/19/2021 9:20 AM, EricP wrote:
>>
>>> Ivan Godard wrote:
>>>
>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>
>>>>> 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.
>>>>
>>>> As for example:
>>>> enumWithTraits(intNumEnums, overflowCode,
>>>> excepting,
>>>> modulo,
>>>> saturating,
>>>> widening
>>>> );
>>>> available in every kind of operation that can overflow?
>>>
>>> I don't know what you mean.
>>>
>>> I mean that only the programmer knows their intent and since
>>> that intent changes and they need a way to express it.
>>> A one-size-fits-all approach isn't flexible enough.
>>>
>>> The compiler already handles overloading operators for different
>>> integral and float data types and sizes. This expands on that mechanism.
>>
>> I think the disconnect is the following. Ivan showed what
>> capabilities are/will be in the Mill hardware ISA. You talked about
>> what the programmer intends. The disconnect is that the current C
>> language doesn't provide a mechanism to "connect" the two, at least in
>> many cases. [..]
>
> This reminds me of something Butler Lampson said when asked
> about ways of defining language extensions. He said, "We
> already have that. They're called procedures. They work
> great."
>
>> I should note that at least a good part of these are specifiable in,
>> for example Ada. The very extensive type system in Ada is, IMO one of
>> its biggest strengths.
>
> 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.

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.

But once again, I am not an Ada programmer, and others would be much
better than me at answering your questions.

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

According to Stephen Fuld <sfuld@alumni.cmu.edu.invalid>:
>> 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).

The killer app is databases, and specifically database updates. If you
are a bank and a customer sends in a $100K transfer, the money either is
in the account or it isn't. The database can have a thousand transactions
active at once, but if they're all on one big computer, they can do the
locking in RAM with instructions like compare-and-swap rather than with
network transactions that are orders of magnitude slower.

There aren't a whole lot of databases big enough for this to be an issue
but for the ones that are, a few million dollars to get reliable high
performance consistent transactions is a bargain.

--
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 Wednesday, October 20, 2021 at 7:02:11 PM UTC+3, John Levine wrote:
> According to Michael S <already...@yahoo.com>:
> >On Wednesday, October 20, 2021 at 4:58:07 AM UTC+3, John Levine wrote:
> >> 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?
> The redbook says Max190 can have 5 processor drawers with
> a total of 40TB. I have no idea what size machines people
> actually buy.
> --
> 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

Thank you.
I relied on google that somehow failed to find this configuration.
Now I see that each z15 drawer is equipped with 4 SMP links so 5-drawer single-system configuration is possible.

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.

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

Stefan Monnier wrote:
>> 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.

What is this 128-bit address space going to be used for?
I believe that HP's "The Machine" was talking about 128-bit
addresses but they were also talking about something like a
single address space holding all data for an organization
in persistent memristor storage (which was, so we were told,
going to be faster than cache and cheaper than disk).

Going the other direction, my ISA includes two sizes of absolute address,
64 bit, and sign extended 32 bit allows direct addressing the bottom
2 GB where most user code static data reside,
and (unsigned) top 2 GB where OS and its static data reside.

The compacting linker by default tries to locate code in lower/upper 2 GB
and then compacts any absolute addresses, which should almost always work.

I figure 2 GB for each of user and OS code code should cover most situations.

On 10/20/2021 9:09 AM, EricP wrote:
> Ivan Godard wrote:
>> 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. Don't you find that precedence parens masquerading as
>> optimization-control parens sometimes engender bad code?
>
> It provides an easy mechanism for programmer to pass intent to a compiler.
> Historically mostly useful for floating point,
> but could be used for overflow and saturating integers too.
>
> It wouldn't work well as a default behavior in C because
> macros use so many parens.
>
> Do you have an alternative idea of how to succinctly instruct
> that this expression precedence must be interpreted as given?
> One could add a reserved word to a language like "exact (expression)"
> but that would get tedious if you were writing hundreds of thousands
> or millions of lines of weather or black hole simulations.

An alternative is to dump precedence (what's the precedence of a left
circular shift?) and add "sic{...}".

Ivan Godard wrote:
> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>> On 10/19/2021 9:20 AM, EricP wrote:
>>> Ivan Godard wrote:
>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>
>>>>> 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.
>>>>
>>>> As for example:
>>>> enumWithTraits(intNumEnums, overflowCode,
>>>> excepting,
>>>> modulo,
>>>> saturating,
>>>> widening
>>>> );
>>>> available in every kind of operation that can overflow?
>>>>
>>>
>>> I don't know what you mean.
>>>
>>> I mean that only the programmer knows their intent and since
>>> that intent changes and they need a way to express it.
>>> A one-size-fits-all approach isn't flexible enough.
>>>
>>> The compiler already handles overloading operators for different
>>> integral and float data types and sizes. This expands on that mechanism.
>>
>> I think the disconnect is the following. Ivan showed what
>> capabilities are/will be in the Mill hardware ISA. You talked about
>> what the programmer intends. The disconnect is that the current C
>> language doesn't provide a mechanism to "connect" the two, at least in
>> many cases. Several proposals have been made here (pragmas, compile
>> options, etc.), but none are apparently part of the standard.
>>
>> I should note that at least a good part of these are specifiable in,
>> for example Ada. The very extensive type system in Ada is, IMO one of
>> its biggest strengths.
>
> Well put. Besides Ada, also consider C++ in which you can define classes
> saturatingShort, saturatingInt, etc and overload the operators to
> produce an intrinsic which in turn invokes a native instruction (Mill)
> or sequence (whatever). Writing the library is annoying, but using it is
> convenient and natural.

One reason one might want data types defined in a language is the
handling of compile-time constant expressions where the operators
or rules for optimization change based on data type.
e.g. float vs int reordering rules, or single might be different
from double, or maybe float round mode would be given by its data type.

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>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.

I am pretty sure they would notice because many programs are using the
64-bit ISA. But even assuming 32-bit versions of the programs exist,
I expect that may people use at least one program that uses more
address space and/or memory than available in 32-bit OSs. E.g., we
recently replaced a 32GB RAM machine from 2009 with a 128GB machine,
because emacs regularly ran out of memory for me on the 32GB machine.

I also remember a time when I ran into the 32-bit limits of Emacs (at
significantly less then 4GB); that was a long time ago, so I noticed
the difference then.

But Emacs is not the only use case. A collegue of mine upgraded his
laptop some years ago to one with more RAM (I don't remember if the
new or old one had 16GB), because his old laptop was no longer big
enough for his mailbox.

Another use case is the game Runes of Magic. The client you get from
Gameforge still uses IA-32. It instantly uses a little over 1GB of
RAM, but that can grow depending on what you do in the game, and the
game crashes somewhat frequently because it runs out of memory and
cannot deal with that. There is another version of the game, called
Arcadia, from a different publisher who has produced a 64-bit client.
From what I hear, crashes are much rarer on Arcadia. The fact that
Gameforge sticks with the 32-bit client is a frequently criticised
point.

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

On 10/20/2021 10:48 AM, John Levine wrote:
> According to BGB <cr88192@gmail.com>:
>>> 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.
>
> No, they're people who do stuff that Macs do well. In my case, I have a
> Mac because it is a full Unix system underneath, with well supported versions
> of browsers and mail programs and all the other stuff you need. I have
> used linux on laptops which works mostly, and the browsers and stuff work,
> usually. Other people have Macs because they are doing graphic design or
> video editing where the Mac apps are way better than the alternative.
>
> Also, Macs last a long time. A five year old Mac works fine, and is fully
> supported by current software.
>

Depending on ones' income level and expenses, a person could easily end
up needing to save up money for multiple years to be able to afford a
Mac, it just may not be worth it.

If one can get a normal desktop PC assembled for (merely) a few months
wages, it might be more viable for them to go this route.

Not sure what impact the whole "raising the minimum wage" thing would
have, either people could afford to buy a PC faster, or companies end up
doing mass layoffs because it is not cost-effective for the companies to
pay $15 or so. Not sure what happens then, I guess the tent city gets a
few more residents.

Though, one big drawback of tent cities is lack of reliable access to
power, water, or internet access (nor any real sort of "escape path"; in
pretty much all sense, a person "falls out of the system" at this point).

....

Meanwhile, yeah, Linux works well at least, I tend to run Linux on many
of my secondary PCs.

>> New pre-built PCs tend to be overpriced and kinda weak regarding their
>> hardware stats (at least from places like BestBuy).
>
> 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.
>

The laptop I have is from 2009 (and an older one from 2003).

Had considered getting a newer one, but too expensive for not enough
improvement in terms of baseline stats to make it seem all that worthwhile.

It also seems like laptops were cheaper in the 2000s.

On 10/20/2021 6:54 AM, Michael S wrote:
> 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.
>

OK, if so, the situation is better than the last time I looked
(admittedly, a few years ago), where it was mostly 4GB and 8GB models in
this price range.

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. A
partial ring, perhaps? They certainly form a partial group.

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

John Levine <johnl@taugh.com> writes:

> According to BGB <cr88192@gmail.com>:
>>> 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.
>
> No, they're people who do stuff that Macs do well. In my case, I have a
> Mac because it is a full Unix system underneath, with well supported versions
> of browsers and mail programs and all the other stuff you need. I have
> used linux on laptops which works mostly, and the browsers and stuff work,
> usually. Other people have Macs because they are doing graphic design or
> video editing where the Mac apps are way better than the alternative.
>
> Also, Macs last a long time. A five year old Mac works fine, and is
> fully supported by current software.

Apple's hardware does last a long time [1], Apple's software (support)
is not nearly as impressive in longevity department

>
>>New pre-built PCs tend to be overpriced and kinda weak regarding their
>>hardware stats (at least from places like BestBuy).
>
> 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.
>
> R's,
> John

[1] https://boblycat.org/~malc/scratch/minis.png

The box at the bottom is a 7447A PPC mac mini given to me as a
birthday present by colleagues in 2008, it still works, under Linux
that is (DVD drive died ages ago and i had to replace hard disk, but
otherwise it's in a tip-top working condition)

[2] Second generation iPhone that i have given as birthday present to my
mother still works too

[3] I managed to sell 2014 i5 mac mini along with mac book air (same
year) and with the that money acquire M1 mini earlier this year

[4] While it would require superhuman effort to pry PPC mini from my
cold dead hands i would have gladly parted with the Core Duo one,
alas no suitors...

[5] iPad №4 (a gift to my grandmother) was associated with some Apple
thing (find my device?) she does not remember her password so now it
serves as a pretty kitchen timer and is unsellable

Takeaways:
* i like the hardware (Apple produces itself)
* "of the shelf" parts that it doesn't are a mixed bag
* Apple's SW supports HW in the vicinity to the latest and greatest only
* macOS GUI is not for me
* Apple make nice gifts that people don't mind receiving

On 10/20/2021 8:09 AM, Stefan Monnier wrote:
>> 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.
>

This is partly why I am going to a 48-bit baseline addressing scheme,
with 96-bit (extended) addressing.

I don't expect 48-bits is likely to be hit by all that much. Meanwhile,
96-bits should be large enough to be extended far into the future.

One drawback would be that, in effect, there would be two different
pointer sizes (like in MS-DOS or Win16).

But, it is likely that a system with 64/128 bit storage sizes for
pointers, will be more useful than one with purely 128 bit pointers.

As for the tradeoff between 48-bit pointers and full 64-bit pointers,
this ship has already partly sailed in my case (couldn't switch over to
full 64-bits without breaking binary compatibility with existing code).

....

On 2021-10-20 20:03, EricP wrote:
> Ivan Godard wrote:
>> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>>> On 10/19/2021 9:20 AM, EricP wrote:
>>>> Ivan Godard wrote:
>>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>>
>>>>>> 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.
>>>>>
>>>>> As for example:
>>>>>    enumWithTraits(intNumEnums, overflowCode,
>>>>>                     excepting,
>>>>>                     modulo,
>>>>>                     saturating,
>>>>>                     widening
>>>>>                     );
>>>>> available in every kind of operation that can overflow?
>>>>>

[snip]

>>> Ivan showed what
>>> capabilities are/will be in the Mill hardware ISA.  You talked about
>>> what the programmer intends.  The disconnect is that the current C
>>> language doesn't provide a mechanism to "connect" the two, at least
>>> in many cases.  Several proposals have been made here (pragmas,
>>> compile options, etc.), but none are apparently part of the standard.
>>>
>>> I should note that at least a good part of these are specifiable in,
>>> for example Ada.  The very extensive type system in Ada is, IMO one
>>> of its biggest strengths.
>>
>> Well put. Besides Ada, also consider C++ in which you can define
>> classes saturatingShort, saturatingInt, etc and overload the operators
>> to produce an intrinsic which in turn invokes a native instruction
>> (Mill) or sequence (whatever). Writing the library is annoying, but
>> using it is convenient and natural.
>
> One reason one might want data types defined in a language is the
> handling of compile-time constant expressions where the operators
> or rules for optimization change based on data type.
> e.g. float vs int reordering rules, or single might be different
> from double, or maybe float round mode would be given by its data type.

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.

According to EricP <ThatWouldBeTelling@thevillage.com>:
>What is this 128-bit address space going to be used for?
>I believe that HP's "The Machine" was talking about 128-bit
>addresses but they were also talking about something like a
>single address space holding all data for an organization
>in persistent memristor storage (which was, so we were told,
>going to be faster than cache and cheaper than disk).

IBM series i, formerly AS/400, formerly System/38 has 128 bit
pointers. It does indeed have a single address space for
everything on the machine. Its users love it and they've
sold something like a million of them which is pretty impressive
for a midrange system that is not cheap.

The 128 bit addresses are not implemented in hardware. It has a virtual
instruction set called TIMI which is translated into the local machine
code the first time a program is run.

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

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

Stefan

Anton Ertl [2021-10-20 16:55:13] wrote:

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>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.
>
> I am pretty sure they would notice because many programs are using the
> 64-bit ISA. But even assuming 32-bit versions of the programs exist,
> I expect that may people use at least one program that uses more
> address space and/or memory than available in 32-bit OSs. E.g., we
> recently replaced a 32GB RAM machine from 2009 with a 128GB machine,
> because emacs regularly ran out of memory for me on the 32GB machine.
>
> I also remember a time when I ran into the 32-bit limits of Emacs (at
> significantly less then 4GB); that was a long time ago, so I noticed
> the difference then.
>
> But Emacs is not the only use case. A collegue of mine upgraded his
> laptop some years ago to one with more RAM (I don't remember if the
> new or old one had 16GB), because his old laptop was no longer big
> enough for his mailbox.
>
> Another use case is the game Runes of Magic. The client you get from
> Gameforge still uses IA-32. It instantly uses a little over 1GB of
> RAM, but that can grow depending on what you do in the game, and the
> game crashes somewhat frequently because it runs out of memory and
> cannot deal with that. There is another version of the game, called
> Arcadia, from a different publisher who has produced a 64-bit client.
> From what I hear, crashes are much rarer on Arcadia. The fact that
> Gameforge sticks with the 32-bit client is a frequently criticised
> point.
>
> - anton

On 10/20/2021 11:12 AM, Niklas Holsti wrote:
> On 2021-10-20 20:03, EricP wrote:
>> Ivan Godard wrote:
>>> On 10/19/2021 11:08 AM, Stephen Fuld wrote:
>>>> On 10/19/2021 9:20 AM, EricP wrote:
>>>>> Ivan Godard wrote:
>>>>>> On 10/18/2021 2:23 PM, EricP wrote:
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> As for example:
>>>>>>    enumWithTraits(intNumEnums, overflowCode,
>>>>>>                     excepting,
>>>>>>                     modulo,
>>>>>>                     saturating,
>>>>>>                     widening
>>>>>>                     );
>>>>>> available in every kind of operation that can overflow?
>>>>>>
>
>
>    [snip]
>
>>>> Ivan showed what capabilities are/will be in the Mill hardware ISA.
>>>> You talked about what the programmer intends.  The disconnect is
>>>> that the current C language doesn't provide a mechanism to "connect"
>>>> the two, at least in many cases.  Several proposals have been made
>>>> here (pragmas, compile options, etc.), but none are apparently part
>>>> of the standard.
>>>>
>>>> I should note that at least a good part of these are specifiable in,
>>>> for example Ada.  The very extensive type system in Ada is, IMO one
>>>> of its biggest strengths.
>>>
>>> Well put. Besides Ada, also consider C++ in which you can define
>>> classes saturatingShort, saturatingInt, etc and overload the
>>> operators to produce an intrinsic which in turn invokes a native
>>> instruction (Mill) or sequence (whatever). Writing the library is
>>> annoying, but using it is convenient and natural.
>>
>> One reason one might want data types defined in a language is the
>> handling of compile-time constant expressions where the operators
>> or rules for optimization change based on data type.
>> e.g. float vs int reordering rules, or single might be different
>> from double, or maybe float round mode would be given by its data type.
>
>
> 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".

On 10/20/2021 4:12 PM, Stefan Monnier wrote:
> 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 ;-)
>

Looking at task manager:
Running programs which exceed 32-bit limits:
Firefox, Minecraft
Programs which fit within 32 bits:
Everything else.

Something like 32-bit VA + 36-bit PA (such as via PAE) would likely have
still been "mostly sufficient" for most current end-user systems.

Granted, by this point PAE (as it was) would be about at the limits of
its usable lifespan.

Something like Minecraft would be a little more difficult, but this is
likely more the exception rather the rule.

Meanwhile, back in Win16 days, hardly anything could fit into 16-bits,
so in practice one was *still* using 32-bit (far) pointers for the most
part.

Many decades into the future, it seems likely that (realistically)
needing much larger than 48 or 64 bits will be still be a bit of a
novelty for most "sanely designed" software (assuming that "code bloat"
doesn't run too much out of hand, relative absence of things like "imma
malloc a 1TB array, because I can!", ...).

>
> Stefan
>
>
> Anton Ertl [2021-10-20 16:55:13] wrote:
>
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> 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.
>>
>> I am pretty sure they would notice because many programs are using the
>> 64-bit ISA. But even assuming 32-bit versions of the programs exist,
>> I expect that may people use at least one program that uses more
>> address space and/or memory than available in 32-bit OSs. E.g., we
>> recently replaced a 32GB RAM machine from 2009 with a 128GB machine,
>> because emacs regularly ran out of memory for me on the 32GB machine.
>>
>> I also remember a time when I ran into the 32-bit limits of Emacs (at
>> significantly less then 4GB); that was a long time ago, so I noticed
>> the difference then.
>>
>> But Emacs is not the only use case. A collegue of mine upgraded his
>> laptop some years ago to one with more RAM (I don't remember if the
>> new or old one had 16GB), because his old laptop was no longer big
>> enough for his mailbox.
>>
>> Another use case is the game Runes of Magic. The client you get from
>> Gameforge still uses IA-32. It instantly uses a little over 1GB of
>> RAM, but that can grow depending on what you do in the game, and the
>> game crashes somewhat frequently because it runs out of memory and
>> cannot deal with that. There is another version of the game, called
>> Arcadia, from a different publisher who has produced a 64-bit client.
>> From what I hear, crashes are much rarer on Arcadia. The fact that
>> Gameforge sticks with the 32-bit client is a frequently criticised
>> point.
>>
>> - anton

In article <87fstdumxd.fsf@hotmail.com>, <clamky@hotmail.com> wrote:
>Might strike a cord with Anton and/or Mich
>
>https://www.yodaiken.com/2021/10/06/plos-2021-paper-how-iso-c-became-unusable-for-operating-system-development/

Let me summarize some of the arguments in a different way:

1) The ISO C standard leaves a large area of Undefined Behavior (UB).
A C compiler that ignores UB in code it compiles is a valid
compiler. But a C program containing any UB is always broken
even if it seems to be working today. C compilers have grabbed
the entire space--they reserve the right to release a new
compiler that treats any UB as an optimization and change C code
that was working to non-working, and provide no mechanism to
warn that they are doing so, nor to provide the old behavior.
The problem is new UB optimizations (detecting UB that compilers
don't currently detect) which lead to new optimizations which
will break more programs. It's possible every non-trivial C
program accidentally touches some UB behavior. If everything
is illegal, it's the laws which are wrong.

2) A C Standard should enable the C Standard Library to be written in
fully conforming C (without triggering undefined behavior).
Examples: malloc()/free(), etc. ISO C does not allow
this due to undefined behavior inherent in some of the routines.
This looks like a mistake in ISO C.

3) The ISO C standard is complex enough that very smart people can argue
about basic points for weeks and not reach agreement. It's
hard to agree on what even is UB. The ISO C Standard is 683 pages
and costs $250USD. (Those "in the know" can get it for free).
But any C program which accidentally uses UB behavior (despite
-Wall, -Wextra, -fsanitize=undefined, etc. passing) is buggy and
written by someone incompetent. It should not be necessary to
be a C compiler writer to be able to write valid C code.

Kent

On 2021-10-17, Michael S <already5chosen@yahoo.com> wrote:
> On Sunday, October 17, 2021 at 6:18:11 AM UTC+3, Branimir Maksimovic wrote:
>> On 2021-10-15, Michael S <already...@yahoo.com> wrote:
>> > On Friday, October 15, 2021 at 12:11:58 PM UTC+3, Branimir Maksimovic
>> > wrote:
>> >> On 2021-10-14, Thomas Koenig <tko...@netcologne.de> wrote:
>> >> > Branimir Maksimovic <branimir....@icloud.com> schrieb:
>> >> >
>> >> >> Fortran is pre structured era, spagetti code.
>> >> >
>> >> > Your knowledge seems to be stuck in the 1980s.
>> >> >
>> >> > To see what was available in Fortran 95, around 25 years ago, you could
>> >> > try reading https://en.wikipedia.org/wiki/Fortran_95_language_features
>> >> So what do you recommend? Fortran or ADA? --
>> >
>> > The name of the language is Ada. ADA is a misspelling preferred by Mitch
>> > Alsup. I don't know what are his reasons.
>> >
>> OK, Ada. What do you recommend?
>
>
> Me, personally? Neither. Others, I'd guess, would be able to answer only if
> you specify a sort of software that you are planning to develop.
>
For my purposes, Pike would be ideal, it's just you have to look into
source code to obtain documentation :P
Pike is secret weapon, I believe :P
--

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

On 2021-10-17, David Brown <david.brown@hesbynett.no> wrote:
> On 16/10/2021 18:07, Anton Ertl wrote:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>
>>> 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.
>>
>
> Just for completeness, I can give you the answer here. If char is
> smaller than int, then the addition of two signed chars is always going
> to be fully defined. If char is the same size as int, then it could
> overflow (of course it could not overflow when adding 127 + 127, as int
> will always be big enough to hold 254).
>
> The conversion from int down to signed char is fully defined if the
> signed char can hold the value, otherwise it is "implementation-defined
> or an implementation-defined signal is raised". That means the
> implementation has to document a specific handling here - but it is
> allowed to have some kind of trap or error handling rather than a
> particular value.
>
> In practice, of course, virtually all compilers will do the conversion
> as modulo reduction (or two's complement wrapping, if you prefer).
> Maybe some will offer trapping as an alternative to aid in debugging.
>
> So - defined by the implementation, not undefined.
>
I wouldn't waste time with thinking if program would work or not.
For such things, non portable code is only choice...

--

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