On 3/13/2023 9:32 AM, Simon Clubley wrote:
> On 2023-03-10, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> So /POINTER=64 is default. I should make a note about that.
>>
>> Curious about long being 64 bit.
>>
>> So:
>> Alpha & Itanium x86-64
>> short 16 16
>> int 32 32
>> long 32 64
>> long long 64 ?
>>
>> ?
>>
>> I guess it is way overdue to always use intxx_t!
>
> Even better is to use uintXX_t unless you really want a signed integer. :-)
>
> A big mistake languages made (IMHO) was to make their integers signed
> by default, instead of you needing to ask for a signed integer if you
> really needed one.

That is not really C specific.

Fortran INTEGER is signed. Pascal INTEGER is signed (even though Pascal
got CARDINAL for unsigned).

Java does not have unsigned integers.

Arne

On 2023-03-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/13/2023 9:32 AM, Simon Clubley wrote:
>>
>> Even better is to use uintXX_t unless you really want a signed integer. :-)
>>
>> A big mistake languages made (IMHO) was to make their integers signed
>> by default, instead of you needing to ask for a signed integer if you
>> really needed one.
>
> That is not really C specific.
>

Notice I didn't say C, but "languages". :-)

I consider it a general design flaw in languages, probably based on the
need to mirror underlying early architecture and then it just became
established as the default.

> Fortran INTEGER is signed. Pascal INTEGER is signed (even though Pascal
> got CARDINAL for unsigned).
>
> Java does not have unsigned integers.
>

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/13/2023 10:01 AM, Simon Clubley wrote:
> On 2023-03-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/13/2023 9:32 AM, Simon Clubley wrote:
>>>
>>> Even better is to use uintXX_t unless you really want a signed integer. :-)
>>>
>>> A big mistake languages made (IMHO) was to make their integers signed
>>> by default, instead of you needing to ask for a signed integer if you
>>> really needed one.
>>
>> That is not really C specific.
>
> Notice I didn't say C, but "languages". :-)
>
> I consider it a general design flaw in languages, probably based on the
> need to mirror underlying early architecture and then it just became
> established as the default.

I consider it rather natural to have integers signed by default.

Except byte that I like unsigned.

I really like C# where short, int and long are signed while
byte is unsigned - and one can pick ushort, uint, ulong and
sbyte when one want the other way.

Arne

On 3/13/2023 5:56 AM, Andreas Gruhl wrote:
> Arne Vajhøj schrieb am Freitag, 10. März 2023 um 22:01:40 UTC+1:
>> Pre-release for comments:
>>
>> https://www.vajhoej.dk/arne/articles/vms64.html

> I like to add, that you can successfully access the lower 2 GB of P2
> (%X00000000 80000000..%X00000000 FFFFFFFF) with 32 bit
> pointers and descriptors.
> You only have to treat the pointers as unsigned instead of signed
> avoiding them to be interpreted as S0/S1 addresses.
> We successfully use this in Pascal, which is missing 64-Bit descriptors.
> The caller of a routine can then simply pass a structure in lower P2
> without any special adaptions (except having to use the compiler
> qualifier /USAGE=64BIT_TO_DESCR).
> The routine itself has to do some additional work. It must extract the
> structure's address from the descriptor and copy it to a 64-Bit Pointer
> WITHOUT sign extension.
> This makes the structure directly accessible although it resides in P2.

Is /USAGE=64BIT_TO_DESCR new for x86-64?

Arne

On 3/13/23 8:40 AM, John Dallman wrote:
> In article <tugdbo$25f5e$1@dont-email.me>, craigberry@nospam.mac.com
> (Craig A. Berry) wrote:
>
>> Looks good. Thanks for doing that. You may be interested in the
>> following tidbits that showed up in the release notes for the new
>> clang++ compiler:
>>
>> 1.3 Differences Between C++ on OpenVMS Itanium and OpenVMS x86
>>
>> The datatypes 'long', 'size_t', 'nullptr_t', 'ptrdiff_t' are 64-bits
>> wide on OpenVMS x86 but only 32-bits wide on OpenVMS Itanium.
>
> Have you got a link for that?

As far as I know it's only available in the service portal for people
with a support contract. I assume it will become part of the standard,
publicly-available docs once that compiler is out of field test.

On 3/13/2023 2:53 PM, John Dallman wrote:
> In article <tunp6s$3sc9i$1@dont-email.me>, craigberry@nospam.mac.com
> (Craig A. Berry) wrote:
>> On 3/13/23 8:40 AM, John Dallman wrote:
>>> Have you got a link for that?
>>
>> As far as I know it's only available in the service portal for
>> people with a support contract. I assume it will become part of the
>> standard, publicly-available docs once that compiler is out of field
>> test.
>
> Makes sense, thanks. It makes porting C/C++ applications to VMS a good
> deal simpler.

I believe it always have been the message that:
* Fortran, Pascal, Cobol, Basic and C will get all the DCL command
qualifiers, VMS specific language extensions and VMS specific CRTL
functions needed to compile old existing code
* C++ would be clang ported to VMS close to "as is"

When such a high level idea meet reality, then things can change
a little.

But it makes sense. There are probably not that many old
VMS specific C++ applications out there. For the simple
reason that when C++ for VMS showed up and became
reasonable stable, then VMS was no longer a common
platform choice for new applications.

But there are a lot of stuff developed on *nix and Windows
that need a C++ compiler with support for newer C++ standards
to be able to build on VMS. Including latest versions of
MySQL/MariaDB and OpenJDK.

Arne

On 3/13/2023 10:19 AM, Arne Vajhøj wrote:
> On 3/13/2023 10:01 AM, Simon Clubley wrote:
>> On 2023-03-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 3/13/2023 9:32 AM, Simon Clubley wrote:
>>>>
>>>> Even better is to use uintXX_t unless you really want a signed integer. :-)
>>>>
>>>> A big mistake languages made (IMHO) was to make their integers signed
>>>> by default, instead of you needing to ask for a signed integer if you
>>>> really needed one.
>>>
>>> That is not really C specific.
>>
>> Notice I didn't say C, but "languages". :-)
>>
>> I consider it a general design flaw in languages, probably based on the
>> need to mirror underlying early architecture and then it just became
>> established as the default.
>
> I consider it rather natural to have integers signed by default.

The way most/all people consider math, numbers can be either positive or
negative. Yes, "natural". Computer languages were developed using this
concept. While unsigned numbers are useful, they aren't something people
normally consider. Not sure where Simon is coming from with his assertions.

> Except byte that I like unsigned.
>
> I really like C# where short, int and long are signed while
> byte is unsigned - and one can pick ushort, uint, ulong and
> sbyte when one want the other way.

The problem with all of those is they are vague, and are defined differently on
different HW and software. Precision is to be desired.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/13/2023 8:39 AM, Jan-Erik Söderholm wrote:
> Den 2023-03-13 kl. 11:22, skrev JOUKJ:
>> Arne Vajhøj wrote:
>>>
>>> Pre-release for comments:
>>>
>>> https://www.vajhoej.dk/arne/articles/vms64.html
>>>
>>> Arne
>
>
> A bit pre-dated also... :-)
>
>
> Article history:
> Version Date Description
> 0.9 March 10th 20223 Pre-release
>
>

Ah, the extreme power and capability of a keystroke, even time travel.

:-)

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/13/2023 3:17 PM, Dave Froble wrote:
> On 3/13/2023 10:19 AM, Arne Vajhøj wrote:
>> I really like C# where short, int and long are signed while
>> byte is unsigned - and one can pick ushort, uint, ulong and
>> sbyte when one want the other way.
>
> The problem with all of those is they are vague, and are defined
> differently on different HW and software.  Precision is to be desired.

In C the types short, int and long are vaguely defined.

Not in C# and Java - there they are 16, 32 and 64 bit two's complement.
Only aspect left optional is big vs little endian.

Arne

On Monday, March 13, 2023 at 2:53:57 PM UTC-4, John Dallman wrote:
> In article <tunp6s$3sc9i$1...@dont-email.me>, craig...@nospam.mac.com
> (Craig A. Berry) wrote:
>
> > On 3/13/23 8:40 AM, John Dallman wrote:
> > > Have you got a link for that?
> >
> > As far as I know it's only available in the service portal for
> > people with a support contract. I assume it will become part of the
> > standard, publicly-available docs once that compiler is out of field
> > test.
> Makes sense, thanks. It makes porting C/C++ applications to VMS a good
> deal simpler.
>
> John
That /USAGE qualifier is a Pascal qualifier. It asks the Pascal compiler to violate
the Calling Standard and not sign-extend a 32-bit pointer to duplicate what you can
get (by accident) on Itanium.

It wouldn't be a C or C++ qualifier since neither of those compilers do anything with
descriptors behind your back.

On Monday, March 13, 2023 at 3:08:34 PM UTC-4, Arne Vajhøj wrote:
> On 3/13/2023 2:53 PM, John Dallman wrote:
> > In article <tunp6s$3sc9i$1...@dont-email.me>, craig...@nospam.mac.com
> > (Craig A. Berry) wrote:
> >> On 3/13/23 8:40 AM, John Dallman wrote:
> >>> Have you got a link for that?
> >>
> >> As far as I know it's only available in the service portal for
> >> people with a support contract. I assume it will become part of the
> >> standard, publicly-available docs once that compiler is out of field
> >> test.
> >
> > Makes sense, thanks. It makes porting C/C++ applications to VMS a good
> > deal simpler.
> I believe it always have been the message that:
> * Fortran, Pascal, Cobol, Basic and C will get all the DCL command
> qualifiers, VMS specific language extensions and VMS specific CRTL
> functions needed to compile old existing code
> * C++ would be clang ported to VMS close to "as is"
>
There has been a constant drumbeat from customers (including many here
on this forum) about our odd choice of long=32-bit; ptrdiff_t=32-bit;
size_t=32-bit all while you can say /POINTER=64. For C++/clang, we just
get what clang gives you for a 64-bit compiler.

We have yet to provide a similar setting for the C frontend as so far it hasn't been
necessary.

We have modified/enhanced some headers to replace "long" with "int" to make sure
that certain fields that are 32-bits are still 32-bits with both x86 C and x86 C++.

My desire is to limit the # of clang OpenVMS-isms to those actually needed and to
skip the ones that have been just dragged forward from VAX for no real reason other
than just the fear of pissing off a customer. I'm in the "if you need it, ask and we'll
talk about it" camp.

On 3/13/2023 6:08 PM, John Reagan wrote:
> That /USAGE qualifier is a Pascal qualifier. It asks the Pascal compiler to violate
> the Calling Standard and not sign-extend a 32-bit pointer to duplicate what you can
> get (by accident) on Itanium.

Is it x86-64 only?

The value is not accepted with Pascal 6.2 on neither Alpha nor Itanium.

Arne

On Monday, March 13, 2023 at 9:04:53 PM UTC-4, Arne Vajhøj wrote:
> On 3/13/2023 6:08 PM, John Reagan wrote:
> > That /USAGE qualifier is a Pascal qualifier. It asks the Pascal compiler to violate
> > the Calling Standard and not sign-extend a 32-bit pointer to duplicate what you can
> > get (by accident) on Itanium.
> Is it x86-64 only?
>
> The value is not accepted with Pascal 6.2 on neither Alpha nor Itanium.
>
> Arne
There hasn't been a Alpha or Itanium release with it. Since neither Alpha or Itanium
put code into P2 space that first chunk of memory is where a 64-bit NEW would
get memory from. With code in P2 space on x86, that shoves the 64-bit heap
up more and you need to get help from the compiler. It has never been a good thing
to pass around P2 addresses in the 32-bit field of descriptors.

On 2023-03-13, Dave Froble <davef@tsoft-inc.com> wrote:
>
> The way most/all people consider math, numbers can be either positive or
> negative. Yes, "natural". Computer languages were developed using this
> concept. While unsigned numbers are useful, they aren't something people
> normally consider. Not sure where Simon is coming from with his assertions.
>

Much of the time you don't need signed integers and the problem you are
trying to solve is a better match with unsigned integers.

Let me put it this way: How many filesystems and file sizes and other
limits through computing history are half the maximum size they should
be because everyone used signed integers instead of unsigned integers ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2023-03-13 15:01, Simon Clubley wrote:
> On 2023-03-13, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 3/13/2023 9:32 AM, Simon Clubley wrote:
>>>
>>> Even better is to use uintXX_t unless you really want a signed integer. :-)
>>>
>>> A big mistake languages made (IMHO) was to make their integers signed
>>> by default, instead of you needing to ask for a signed integer if you
>>> really needed one.
>>
>> That is not really C specific.
>>
>
> Notice I didn't say C, but "languages". :-)
>
> I consider it a general design flaw in languages, probably based on the
> need to mirror underlying early architecture and then it just became
> established as the default.

I don't think there is anything in the underlying architecture that
leads one way or another on this topic (no matter which architecture).

I think it's much more likely that the chose to have them signed as most
people when they work with integers expect them to be able to represent
both positive and negative numbers.

Johnny

On 3/14/2023 9:08 AM, Simon Clubley wrote:
> On 2023-03-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>
>> The way most/all people consider math, numbers can be either positive or
>> negative. Yes, "natural". Computer languages were developed using this
>> concept. While unsigned numbers are useful, they aren't something people
>> normally consider. Not sure where Simon is coming from with his assertions.
>>
>
> Much of the time you don't need signed integers and the problem you are
> trying to solve is a better match with unsigned integers.
>
> Let me put it this way: How many filesystems and file sizes and other
> limits through computing history are half the maximum size they should
> be because everyone used signed integers instead of unsigned integers ?
>
> Simon.
>

Understand, I think unsigned numbers would be very useful. I wish Basic support
such. But my point is, they are not so "natural" to humans, and after all,
humans are the users of computers. So development followed what people do.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/14/2023 1:37 PM, Dave Froble wrote:
> On 3/14/2023 9:08 AM, Simon Clubley wrote:
>> On 2023-03-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>> The way most/all people consider math, numbers can be either positive or
>>> negative.  Yes, "natural".  Computer languages were developed using this
>>> concept.  While unsigned numbers are useful, they aren't something
>>> people
>>> normally consider.
>>
>> Much of the time you don't need signed integers and the problem you are
>> trying to solve is a better match with unsigned integers.
>>
>> Let me put it this way: How many filesystems and file sizes and other
>> limits through computing history are half the maximum size they should
>> be because everyone used signed integers instead of unsigned integers ?

When it involves data size and the demand grow x2 every 2 years or so,
then that extra bit will not save they day for long.

> Understand, I think unsigned numbers would be very useful.  I wish Basic
> support such.

I miss them in Java as well.

>   But my point is, they are not so "natural" to humans, and
> after all, humans are the users of computers.  So development followed
> what people do.

If you stop 100 random people on the street and ask about integers, then
99 will include negative numbers, that is the common definition in
math/english/danish/whatever.

Those that remember their math will remember the term natural
numbers to exclude negative numbers.

Arne

On 3/14/2023 2:05 PM, Arne Vajhøj wrote:
> On 3/14/2023 1:37 PM, Dave Froble wrote:
>> On 3/14/2023 9:08 AM, Simon Clubley wrote:
>>> On 2023-03-13, Dave Froble <davef@tsoft-inc.com> wrote:
>>>> The way most/all people consider math, numbers can be either
>>>> positive or
>>>> negative.  Yes, "natural".  Computer languages were developed using
>>>> this
>>>> concept.  While unsigned numbers are useful, they aren't something
>>>> people
>>>> normally consider.
>>>
>>> Much of the time you don't need signed integers and the problem you are
>>> trying to solve is a better match with unsigned integers.
>>>
>>> Let me put it this way: How many filesystems and file sizes and other
>>> limits through computing history are half the maximum size they should
>>> be because everyone used signed integers instead of unsigned integers ?
>
> When it involves data size and the demand grow x2 every 2 years or so,
> then that extra bit will not save they day for long.
>
>> Understand, I think unsigned numbers would be very useful.  I wish
>> Basic support such.
>
> I miss them in Java as well.
>
>>               But my point is, they are not so "natural" to humans,
>> and after all, humans are the users of computers.  So development
>> followed what people do.
>
> If you stop 100 random people on the street and ask about integers, then
> 99 will include negative numbers, that is the common definition in
> math/english/danish/whatever.
>
> Those that remember their math will remember the term natural
> numbers to exclude negative numbers.

Note that it is really highly unlikely that a given
problem domain actually need types:

-2147483648..2147483647
0..4294967295

It is way more likely to have a need for types like:

1..100
0..99
-10..10
etc.

But that is not in fashion today (Pascal, Modula-2,
Oberon, Ada etc. are rare today).

Arne

On 2023-03-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
> It is way more likely to have a need for types like:
>
> 1..100
> 0..99
> -10..10
> etc.
>
> But that is not in fashion today (Pascal, Modula-2,
> Oberon, Ada etc. are rare today).
>

Unfortunately. :-(

Are there any languages other than the Wirth-inspired ones which do
have them as part of the core language ?

BTW, given what the Rust people claim about Rust's target markets,
I consider that to be a surprising omission from Rust, given that they
had all these languages to look at when they were designing Rust.

Such types are used to help model the underlying problem more accurately,
which is exactly the kind of thing the Rust people (and any other such
language designers) should have latched onto.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/2023 2:31 PM, Simon Clubley wrote:
> On 2023-03-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> It is way more likely to have a need for types like:
>>
>> 1..100
>> 0..99
>> -10..10
>> etc.
>>
>> But that is not in fashion today (Pascal, Modula-2,
>> Oberon, Ada etc. are rare today).
>>
>
> Unfortunately. :-(
>
> Are there any languages other than the Wirth-inspired ones which do
> have them as part of the core language ?

Not that I am aware of.

> BTW, given what the Rust people claim about Rust's target markets,
> I consider that to be a surprising omission from Rust, given that they
> had all these languages to look at when they were designing Rust.

A large chunk of Rust target market is the low level
near to the hardware market and there it may actually
be the requirement that there is N bits to fill out.

But in the much bigger business related market then there is
rarely a bit requirements - most likely those defining the
requirements do not know what a bit is.

Arne

On 3/14/2023 2:05 PM, Arne Vajhøj wrote:
>
>
> If you stop 100 random people on the street and ask about integers, then
> 99 will include negative numbers,

If you stop 100 random people on the street and ask about integers, then
99 won't have a clue what you are talking about.

bill

On 3/14/2023 2:53 PM, bill wrote:
> On 3/14/2023 2:05 PM, Arne Vajhøj wrote:
>> If you stop 100 random people on the street and ask about integers, then
>> 99 will include negative numbers,
>
> If you stop 100 random people on the street and ask about integers, then
> 99 won't have a clue what you are talking about.

Those that remember their math should think of Z.

The rest should vaguely remember that "numbers without decimals" are
called integers.

Arne

> If you stop 100 random people on the street and ask about integers, then
> 99 won't have a clue what you are talking about.

99 might be high, but I'd guess at least 90. Unless you choose the
street _very_ carefully.

> Those that remember their math should think of Z.

You can't remember what you never learned. I live in a country where
store clerks can't make change for a dollar in their heads. Back when I
commonly used cash, and wasn't feeling depressed enough, I could buy
something, hand over some bills, wait for the register to calculate the
change, and then hand over some coins to reduce the number of coins
returned. And watch the puny-brain at the register suffer a complete
intellectual collapse.

So, no, I wouldn't expect 99% of "random people on the street" to
have any idea what an integer is.

> The rest should vaguely remember that "numbers without decimals" are
> called integers.

"should" and "would" are spelled differently for a reason.

Thirty-odd years ago, on a business trip to California, I had
breakfast a few times at a Burger King in Fremont which was convenient
to the motel. I was late enough to miss the morning rush, so I dealt
with the manager, who rang up the sale, entering the purchase total as
the amount tendered. He then made change, correctly, using his head
rather than the register. I was so thrilled by this performance that I
almost wrote a commendation letter to the company. But I realized that
he was violating company policy, and decided not to risk getting him
reprimanded (or worse).

But he was an immigrant, not educated here.

On 2023-03-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 3/14/2023 2:31 PM, Simon Clubley wrote:
>> On 2023-03-14, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>
>>> It is way more likely to have a need for types like:
>>>
>>> 1..100
>>> 0..99
>>> -10..10
>>> etc.
>>>
>>> But that is not in fashion today (Pascal, Modula-2,
>>> Oberon, Ada etc. are rare today).
>>>
>>
>> Unfortunately. :-(
>>
>> Are there any languages other than the Wirth-inspired ones which do
>> have them as part of the core language ?
>
> Not that I am aware of.
>
>> BTW, given what the Rust people claim about Rust's target markets,
>> I consider that to be a surprising omission from Rust, given that they
>> had all these languages to look at when they were designing Rust.
>
> A large chunk of Rust target market is the low level
> near to the hardware market and there it may actually
> be the requirement that there is N bits to fill out.
>
> But in the much bigger business related market then there is
> rarely a bit requirements - most likely those defining the
> requirements do not know what a bit is.
>

True, but we are not really talking about bit requirements here.

What we are talking about is implementing a model of some real-world
process, where the legal values for a data type in that process are a
subset of the possible values that could fit in it when that data type
is implemented within a program.

Having the above types of ranges directly supported in a language
helps to implement that model more accurately, and allows the language
to enforce that only this subset of values is ever allowed in a program.

That ability has a range of applications both within lower-level and
higher-level languages.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 3/14/2023 2:53 PM, bill wrote:
> On 3/14/2023 2:05 PM, Arne Vajhøj wrote:
>>
>>
>> If you stop 100 random people on the street and ask about integers, then
>> 99 will include negative numbers,
>
> If you stop 100 random people on the street and ask about integers, then
> 99 won't have a clue what you are talking about.
>
> bill
>
>

Is that like asking "what continent is Europe on"?

My son used this with an old girlfriend when she irritated him. She never
caught on.

Or similar to Jay Leno's "jaywalking" videos?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486