Something C might need

[David Kleinecke]

I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.

There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.

But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.

What we seem to need is operators, call them
":=" and "=:" with the semantics and constraints:
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.

In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.

I know C doesn't NEED these operators. But IMO
they would give it a kind of completion.

[Robert Wessel]

On Thu, 21 Sep 2017 20:50:48 -0700 (PDT), David Kleinecke

Post by David Kleinecke
I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.
There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.
What we seem to need is operators, call them
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.
In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.
I know C doesn't NEED these operators. But IMO
they would give it a kind of completion.

C lacks several features useful for implementing multiple-precision
arithmetic, including double width multiplications results, carries
from addition and subtraction, and double width dividends in
divisions, and the remainders from such double width divisions. All
on both signed and unsigned numbers. Remainders from single width
divisions of signed numbers are provided by the div() family of
functions.

I think it would be reasonable to provide such, but standard library
functions would be adequate, on the assumption that most compilers
would inline them.

Far more useful, however, would be to make a bignum library a part of
the standard library.

[Robert Wessel]

On Fri, 22 Sep 2017 01:15:44 -0500, Robert Wessel

Post by Robert Wessel
On Thu, 21 Sep 2017 20:50:48 -0700 (PDT), David Kleinecke

Post by David Kleinecke
I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.
There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.
What we seem to need is operators, call them
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.
In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.
I know C doesn't NEED these operators. But IMO
they would give it a kind of completion.

C lacks several features useful for implementing multiple-precision
arithmetic, including double width multiplications results, carries
from addition and subtraction, and double width dividends in
divisions, and the remainders from such double width divisions. All
on both signed and unsigned numbers. Remainders from single width
divisions of signed numbers are provided by the div() family of
functions.
I think it would be reasonable to provide such, but standard library
functions would be adequate, on the assumption that most compilers
would inline them.
Far more useful, however, would be to make a bignum library a part of
the standard library.

And addition and subtraction functions that accept a carry in would
need to be provided as well.

[fir]

Post by David Kleinecke
I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.
There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.
What we seem to need is operators, call them
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.
In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.
I know C doesn't NEED these operators. But IMO
they would give it a kind of completion.

im not sure if i understood what you mean here above but if to just copy to upper part its better tu use

b.high = a

where .higha and .low denote higher and lower parts;

same help could be used for .mantisa .exponent and .sign

it calso cn be used for carry

c = a + b

d + = c.carry

(i thought once on just using free keyword "carry"
that would caarry state but it coyuld be confusing
probabbly better to tie it given value)

(there is also doubt if not to enable such carry arithmetic in the bacground)

[Noob]

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.

Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.

int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}

wide_mult:
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

[Robert Wessel]

Post by Noob

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.
Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.
int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

That doesn't help if you want the full result of a multiplication of
the largest type.

[Richard Damon]

Post by Robert Wessel

Post by Noob

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.
Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.
int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

That doesn't help if you want the full result of a multiplication of
the largest type.

Bit if an issue if you want an integral type that is twice as big as the
biggest integral type. f you got it, suddenly you don't anymore as you
have a new biggest integral type.

If you do need this, then you need to get into 'Big Num' math, which
tend to use as a base, something no bigger than 1/2 the bit width of the
biggest type, so it can support this sort of thing.

[David Kleinecke]

Post by Richard Damon

Post by Robert Wessel

Post by Noob

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.
Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.
int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

That doesn't help if you want the full result of a multiplication of
the largest type.

Bit if an issue if you want an integral type that is twice as big as the
biggest integral type. f you got it, suddenly you don't anymore as you
have a new biggest integral type.
If you do need this, then you need to get into 'Big Num' math, which
tend to use as a base, something no bigger than 1/2 the bit width of the
biggest type, so it can support this sort of thing.

Another, nastier approach would be a unary operator - call it "$"
that chops off the lower half of a value.

Arithmetic on a n-bit computer - according to my definition -
is modulo 2^n arithmetic - unless one does something to
prevent it. In standard implementations division already
deviates because division makes no consistent sense in
modulo arithmetic. For example, in modulo 8
5/3 == 7

The nomenclature of C makes 32-bit the natural it. Because
the integer sizes are then:
char, short, int, long
But the natural int from the computer point-of-view is the
arithmetic modulo size. There seems to be a movement toward
what are called 64-bit implementations but I confess to not
knowing whether these implementations do modulo 2^64
arithmetic.

[s***@casperkitty.com]

Post by David Kleinecke
Another, nastier approach would be a unary operator - call it "$"
that chops off the lower half of a value.

I could see some usefulness for operators +>>, ->>, and *>>, which when
applied to matching non-promoted unsigned operands x and y, would compute
the whole-number arithmetical value of (x+y)/(UINT_MAX+1) [or the max for
the appropriate type], (x-y)/(UINT_MAX+1), or (x*y)/(UINT_MAX+1). I could
also see usefulness for a /<< operator which would compute the arithmetical
value of (x*(UINT_MAX+1))/y.

Post by David Kleinecke
Arithmetic on a n-bit computer - according to my definition -
is modulo 2^n arithmetic - unless one does something to
prevent it.

Allowing a compiler to perform integer arithmetic with larger types when
it sees fit, while maintaining mod-wrapping behavior with whatever types
it does happen to use, would allow many useful optimizations which would
be impossible if programmers had to avoid integer overflow at all costs.

[Richard Damon]

Post by David Kleinecke

Post by Richard Damon

Post by Robert Wessel

Post by Noob

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.
Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.
int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

That doesn't help if you want the full result of a multiplication of
the largest type.

Bit if an issue if you want an integral type that is twice as big as the
biggest integral type. f you got it, suddenly you don't anymore as you
have a new biggest integral type.
If you do need this, then you need to get into 'Big Num' math, which
tend to use as a base, something no bigger than 1/2 the bit width of the
biggest type, so it can support this sort of thing.

Another, nastier approach would be a unary operator - call it "$"
that chops off the lower half of a value.

What's the problem with that? Returning only half the bits of a value is
easy, presumably you mean $x gives the upper half of x. Need to define
what to do with an odd number of bits, and the type of the results (the
C default would be int/unsigned unless x was a type with over twice the
number of bits of an int).

Now, if you mean to use it as a way to get the lost bits of the
multiply, it would need some very special wording, as $(a*b) would by
the basic grammar be too late to retrieve them.

Post by David Kleinecke
Arithmetic on a n-bit computer - according to my definition -
is modulo 2^n arithmetic - unless one does something to
prevent it. In standard implementations division already
deviates because division makes no consistent sense in
modulo arithmetic. For example, in modulo 8
5/3 == 7

Maybe your definition but not the Standards. (and what do you consider
5/2 to be?) The standard doesn't define all the values to represent an
equivalence class mod 2^n, but each number represents the base value and
results (for unsigned values) are reduced by modulo arithmetic into the
available range.

Post by David Kleinecke
The nomenclature of C makes 32-bit the natural it. Because
char, short, int, long
But the natural int from the computer point-of-view is the
arithmetic modulo size. There seems to be a movement toward
what are called 64-bit implementations but I confess to not
knowing whether these implementations do modulo 2^64
arithmetic.

When C started, then 'normal' sizes (normal != required, but typical for
mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
most common processors had 16 bit primary registers (and these sizes are
reflected in the minimum allowed ranges for the types). These machines
were typically called 16 bit processors.

When processors started having 32 bit registers (and 32 bit pointers),
int was often promoted to having 32 bit (but many earlier systems might
have still kept it 16 bits, at least as an option, to keep from breaking
broken code). Some machines would go as far as making long 64 bits when
int when to 32 bits since the processor typically would support it, and
some programs assumed long was twice the size of int to allow full
precision multiplies for instance. Now the common sizes for 32 bit
machines are char=8b, short=16b, int=32b, long=64b.

Moving to 64 bits gives us an issue even bigger than before. Registers
ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
would move to 64 bits, but then we run out of standard names for the
smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
Because of this, some just keep int being 32 bits. (Some have proposed
that we need to add a type 'long short' to be the 32 bit type, or make
short be 32 bits and have a 'short short' type for 16 bits.

[Keith Thompson]

Richard Damon <***@Damon-Family.org> writes:
[...]

Post by Richard Damon
When C started, then 'normal' sizes (normal != required, but typical for
mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
most common processors had 16 bit primary registers (and these sizes are
reflected in the minimum allowed ranges for the types). These machines
were typically called 16 bit processors.

K&R1, published in 1978, shows systems with 16-bit, 32-bit, and 36-bit
int.

[...]

Post by Richard Damon
Moving to 64 bits gives us an issue even bigger than before. Registers
ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
would move to 64 bits, but then we run out of standard names for the
smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
Because of this, some just keep int being 32 bits. (Some have proposed
that we need to add a type 'long short' to be the 32 bit type, or make
short be 32 bits and have a 'short short' type for 16 bits.

My suggestion, requiring no changes to the language, would be to define
extended integer types for the intermediate sizes, and then define
[u]intN_t in terms of those types. That way if you specifically want 32
bits you can use int32_t (or int_fast32_t, or int_least32_t).

[s***@casperkitty.com]

Post by Keith Thompson
My suggestion, requiring no changes to the language, would be to define
extended integer types for the intermediate sizes, and then define
[u]intN_t in terms of those types. That way if you specifically want 32
bits you can use int32_t (or int_fast32_t, or int_least32_t).

I'd rather see a standard way of specifying what qualities of an integer
type one does or doesn't care about, in such a way that existing
implementations could use the preprocessor to handle specifications for
types they already support [e.g. if code says it needs something that
behaves as a 16-bit unsigned value that will be promoted to a 32-bit int
when used in computation, and doesn't care about endianness, padding, or
trap representations, a typical 32-bit implementation could simply make
that an alias for "unsigned short"; existing 36-bit implementations would
likely not support a type, but could be adapted to support code that would
require them (whereas such implementations would be unable to support a
conforming uint16_t at all except by making *all* operations on *all* types
ignore four bits of every word).

[David Brown]

Post by Keith Thompson
[...]

Post by Richard Damon
When C started, then 'normal' sizes (normal != required, but typical for
mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
most common processors had 16 bit primary registers (and these sizes are
reflected in the minimum allowed ranges for the types). These machines
were typically called 16 bit processors.

K&R1, published in 1978, shows systems with 16-bit, 32-bit, and 36-bit
int.
[...]

Post by Richard Damon
Moving to 64 bits gives us an issue even bigger than before. Registers
ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
would move to 64 bits, but then we run out of standard names for the
smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
Because of this, some just keep int being 32 bits. (Some have proposed
that we need to add a type 'long short' to be the 32 bit type, or make
short be 32 bits and have a 'short short' type for 16 bits.

My suggestion, requiring no changes to the language, would be to define
extended integer types for the intermediate sizes, and then define
[u]intN_t in terms of those types. That way if you specifically want 32
bits you can use int32_t (or int_fast32_t, or int_least32_t).

That would be nice. But I see a challenge here with types like uint8_t,
on targets that have CHAR_BIT > 8. I don't think you can add an
extended integer type that is smaller than "char". Of course a compiler
can always simulate a type that is smaller than its natural smallest
unit, but in doing so would not that new type become "char" ?


At the other end of the scale, you can't add extended integers that are
bigger than "long long" without having to change intmax_t - and that
might easily go against a target's ABI. (That is, I believe, why gcc
supports __int128 on many platforms but can't call it int128_t and it is
technically not an extended integer type.)

[s***@casperkitty.com]

Post by David Brown
That would be nice. But I see a challenge here with types like uint8_t,
on targets that have CHAR_BIT > 8. I don't think you can add an
extended integer type that is smaller than "char". Of course a compiler
can always simulate a type that is smaller than its natural smallest
unit, but in doing so would not that new type become "char" ?

Any type whose range is smaller than "unsigned char" would necessarily
include padding bits, but if there were a way of specifying a variable
type which is 8 bits with as much padding as needed to fill a "char",
as well as a 16-bit type comprising two of those in big-endian, or
little-endian, or compiler-preferred-endian order, a 32-bit type
comprising two of those, etc. I don't see any problem with larger-char
systems being able to process code written specifically for octet-
based systems.

[Keith Thompson]

David Brown <***@hesbynett.no> writes:
[...]

Post by David Brown
That would be nice. But I see a challenge here with types like uint8_t,
on targets that have CHAR_BIT > 8.

An implementation with CHAR_BIT > 8 cannot define uint8_t.

Post by David Brown
At the other end of the scale, you can't add extended integers that are
bigger than "long long" without having to change intmax_t - and that
might easily go against a target's ABI. (That is, I believe, why gcc
supports __int128 on many platforms but can't call it int128_t and it is
technically not an extended integer type.)

Yes, I've complained about that before.

[David Brown]

Post by Keith Thompson
[...]

Post by David Brown
That would be nice. But I see a challenge here with types like uint8_t,
on targets that have CHAR_BIT > 8.

An implementation with CHAR_BIT > 8 cannot define uint8_t.

That's the point. You suggested that implementations that don't have
standard types corresponding to types like in32_t could have extended
integer types that they would then use. I think that's a good idea, but
it can't be used for uint8_t on targets with CHAT_BIT > 8. You only
talked about the intermediate sizes, which could be defined as extended
integer types. I am just saying that it is unfortunate that the same
process cannot be used to get uint8_t (etc.) when these are smaller than
char. In my experience with DSP's with CHAR_BIT > 8, it is the small
types like uint8_t you miss the most.

Post by Keith Thompson

Post by David Brown
At the other end of the scale, you can't add extended integers that are
bigger than "long long" without having to change intmax_t - and that
might easily go against a target's ABI. (That is, I believe, why gcc
supports __int128 on many platforms but can't call it int128_t and it is
technically not an extended integer type.)

Yes, I've complained about that before.

[David Kleinecke]

Post by Richard Damon

Post by David Kleinecke

Post by Richard Damon

Post by Robert Wessel

Post by Noob

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.
Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.
int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

That doesn't help if you want the full result of a multiplication of
the largest type.

Bit if an issue if you want an integral type that is twice as big as the
biggest integral type. f you got it, suddenly you don't anymore as you
have a new biggest integral type.
If you do need this, then you need to get into 'Big Num' math, which
tend to use as a base, something no bigger than 1/2 the bit width of the
biggest type, so it can support this sort of thing.

Another, nastier approach would be a unary operator - call it "$"
that chops off the lower half of a value.

What's the problem with that? Returning only half the bits of a value is
easy, presumably you mean $x gives the upper half of x. Need to define
what to do with an odd number of bits, and the type of the results (the
C default would be int/unsigned unless x was a type with over twice the
number of bits of an int).
Now, if you mean to use it as a way to get the lost bits of the
multiply, it would need some very special wording, as $(a*b) would by
the basic grammar be too late to retrieve them.

Post by David Kleinecke
Arithmetic on a n-bit computer - according to my definition -
is modulo 2^n arithmetic - unless one does something to
prevent it. In standard implementations division already
deviates because division makes no consistent sense in
modulo arithmetic. For example, in modulo 8
5/3 == 7

Maybe your definition but not the Standards. (and what do you consider
5/2 to be?) The standard doesn't define all the values to represent an
equivalence class mod 2^n, but each number represents the base value and
results (for unsigned values) are reduced by modulo arithmetic into the
available range.

Post by David Kleinecke
The nomenclature of C makes 32-bit the natural it. Because
char, short, int, long
But the natural int from the computer point-of-view is the
arithmetic modulo size. There seems to be a movement toward
what are called 64-bit implementations but I confess to not
knowing whether these implementations do modulo 2^64
arithmetic.

When C started, then 'normal' sizes (normal != required, but typical for
mainstream processors) was char=8b, short=16b, int=16b, long=32b, as the
most common processors had 16 bit primary registers (and these sizes are
reflected in the minimum allowed ranges for the types). These machines
were typically called 16 bit processors.
When processors started having 32 bit registers (and 32 bit pointers),
int was often promoted to having 32 bit (but many earlier systems might
have still kept it 16 bits, at least as an option, to keep from breaking
broken code). Some machines would go as far as making long 64 bits when
int when to 32 bits since the processor typically would support it, and
some programs assumed long was twice the size of int to allow full
precision multiplies for instance. Now the common sizes for 32 bit
machines are char=8b, short=16b, int=32b, long=64b.
Moving to 64 bits gives us an issue even bigger than before. Registers
ARE 64 bits, and we get natural arithmetic module 2^64, so ideally, int
would move to 64 bits, but then we run out of standard names for the
smaller types, having 3 sizes 8, 16, 32 but only two names char, short.
Because of this, some just keep int being 32 bits. (Some have proposed
that we need to add a type 'long short' to be the 32 bit type, or make
short be 32 bits and have a 'short short' type for 16 bits.

Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

[Keith Thompson]

David Kleinecke <***@gmail.com> writes:
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

[David Kleinecke]

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.

I wasn't addressing existing code at all. I have no
desire to even bend any of it.

I am looking forward. What I see is people using types
like "uint8_t" instead of "unsigned char". I was trying
bring the old C nomenclature back into good repute.

IMO if one writes a program that depends on the bit size
of one of the types one needs to document the fact and,
hopefully, test early on that the size (in bytes) is
correct. I think machine that are not byte-based need to
used with great care and lots of special bells and
whistles.

[David Brown]

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.
I am looking forward. What I see is people using types
like "uint8_t" instead of "unsigned char". I was trying
bring the old C nomenclature back into good repute.

Why?

The "old" - i.e., "real" C nomenclature is doing just fine. People are
happy to use these types. And when people want size specific types, the
C99 types like int32_t do the job (I use these extensively for my
programming). Picking new meanings for the existing C type names with
specific sizes seems like the worst possible combination of what we have
today while ensuring that you break /all/ existing code, whether it uses
"int" or "int32_t".

Post by David Kleinecke
IMO if one writes a program that depends on the bit size
of one of the types one needs to document the fact and,
hopefully, test early on that the size (in bytes) is
correct. I think machine that are not byte-based need to
used with great care and lots of special bells and
whistles.

Using types like uint8_t /is/ documenting that you depend on a
particular bit size, and it tests at compile time that this size is
supported.

[bartc]

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.
I am looking forward. What I see is people using types
like "uint8_t" instead of "unsigned char". I was trying
bring the old C nomenclature back into good repute.

In that case it's easy:

char 8 bits
short 16
int 32
long 64
long long 128 (Optional)

float 32
double 64

void* 32 or 64

Since this is what typical /computers/ running C will actually have (not
just any device, no matter how tiny, that happens to be programmable).

And it also matches languages such as C#, Java, Go, and Rust. They will
use different designations, but you know where you are with them.

At the minute, no one can use 'int' or 'long' if they expect one to be
32 bits and the other 64, and no wider.

Post by David Kleinecke
I think machine that are not byte-based need to
used with great care and lots of special bells and
whistles.

I think forget about those.

[Jerry Stuckle]

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.
I am looking forward. What I see is people using types
like "uint8_t" instead of "unsigned char". I was trying
bring the old C nomenclature back into good repute.

   char         8 bits
   short       16
   int         32
   long        64
   long long  128   (Optional)
   float       32
   double      64
   void*       32 or 64
Since this is what typical /computers/ running C will actually have (not
just any device, no matter how tiny, that happens to be programmable).

Because C can be compiled on systems other than what you call
/computers/. And it is used on a lot of those systems. Arguably more
individual systems than your /computers/.

And it also matches languages such as C#, Java, Go, and Rust. They will
use different designations, but you know where you are with them.

So what? Different languages, different rules. Why not make C look like
COBOL or RPG instead?

At the minute, no one can use 'int' or 'long' if they expect one to be
32 bits and the other 64, and no wider.

Which is why there are specific types for specific sizes.

Post by David Kleinecke
I think machine that are not byte-based need to
used with great care and lots of special bells and
whistles.

I think forget about those.

I think you would be in deep crap without those chips. They are used in
all kinds of things - from microwave ovens to automobiles to MP3
players. Nowadays most electronic items use one or more of these chips.
And the most common language used to program them is C.

[Reinhardt Behm]

Post by Jerry Stuckle

Post by bartc

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.
I am looking forward. What I see is people using types
like "uint8_t" instead of "unsigned char". I was trying
bring the old C nomenclature back into good repute.

char 8 bits
short 16
int 32
long 64
long long 128 (Optional)
float 32
double 64
void* 32 or 64
Since this is what typical /computers/ running C will actually have (not
just any device, no matter how tiny, that happens to be programmable).

Because C can be compiled on systems other than what you call
/computers/. And it is used on a lot of those systems. Arguably more
individual systems than your /computers/.

Post by bartc
And it also matches languages such as C#, Java, Go, and Rust. They will
use different designations, but you know where you are with them.

So what? Different languages, different rules. Why not make C look like
COBOL or RPG instead?

Post by bartc
At the minute, no one can use 'int' or 'long' if they expect one to be
32 bits and the other 64, and no wider.

Which is why there are specific types for specific sizes.

Post by bartc

Post by David Kleinecke
I think machine that are not byte-based need to
used with great care and lots of special bells and
whistles.

I think forget about those.

I think you would be in deep crap without those chips. They are used in
all kinds of things - from microwave ovens to automobiles to MP3
players. Nowadays most electronic items use one or more of these chips.
And the most common language used to program them is C.

Not to forget the keyboard and mouse he is using to post his nonsense.

[bartc]

Post by Reinhardt Behm

Post by Jerry Stuckle
I think you would be in deep crap without those chips. They are used in
all kinds of things - from microwave ovens to automobiles to MP3
players. Nowadays most electronic items use one or more of these chips.
And the most common language used to program them is C.

Not to forget the keyboard and mouse he is using to post his nonsense.

Between c. 1976 and 1985 I am 99% certain that the keyboards I used did
not contain any microprogrammable controller let alone be coded in C.
(After that I used an ibm pc-compatible keyboard and I have no idea what
went on inside it.)

The point: keyboards don't need to depend on C to function. (Why they
even needed a microcontroller, until it was necessary to support USB, I
don't know.)

The 'nonsense' you mention is presumably my suggestion to concentrate on
8, 16, 32 and 64-bit data types.

This is the same nonsense as adopted by Java, Go, D, C# and Rust. How
are /those/ used on microcontrollers? Or do they just leave that side of
things to C!

Well, I'm sure it's been suggested many times that C should have split
into a language still suitable for all those dozens of assorted devices,
and a one aimed at the sorts of processors we're all using when posting
to usenet or running compilers.

Then you can streamline each one, rather than ALL users still running
around trying to figure out exactly how wide 'long' is or what stdint.h
type is best or what print format needs to be used.

[s***@casperkitty.com]

Post by bartc
Between c. 1976 and 1985 I am 99% certain that the keyboards I used did
not contain any microprogrammable controller let alone be coded in C.
(After that I used an ibm pc-compatible keyboard and I have no idea what
went on inside it.)
The point: keyboards don't need to depend on C to function. (Why they
even needed a microcontroller, until it was necessary to support USB, I
don't know.)

It is possible to build a keyboard controller out of discrete logic, but
unless one wants to have the main processor scan the keyboard using a
timer-tick interrupt (the approach used by the VIC-20 and Commodore 64,
and likely many other machines as well) the amount of logic required is
fairly substantial. Microcontrollers that could act as all-in-one-chip
solutions were developed in the 1970s, so except in cases where the
VIC-20-style keyboard scanning would be practical they provide the cheapest
way of interfacing keyboards.

[bartc]

Post by s***@casperkitty.com

Post by bartc
Between c. 1976 and 1985 I am 99% certain that the keyboards I used did
not contain any microprogrammable controller let alone be coded in C.
(After that I used an ibm pc-compatible keyboard and I have no idea what
went on inside it.)
The point: keyboards don't need to depend on C to function. (Why they
even needed a microcontroller, until it was necessary to support USB, I
don't know.)

It is possible to build a keyboard controller out of discrete logic, but
unless one wants to have the main processor scan the keyboard using a
timer-tick interrupt (the approach used by the VIC-20 and Commodore 64,
and likely many other machines as well) the amount of logic required is
fairly substantial. Microcontrollers that could act as all-in-one-chip
solutions were developed in the 1970s, so except in cases where the
VIC-20-style keyboard scanning would be practical they provide the cheapest
way of interfacing keyboards.

I don't think the logic is that difficult. You wouldn't have discrete
logic chips (74 series gates etc) anyway, there can be a custom chip but
it needn't be a microcontroller.

The first keyboard I bought was accessed via a 8-bit port; I think the
top bit indicated a key was ready.

The ones my company bought for its microcomputers I think had a more
elaborate controller, but were still accessed in parallel mode (via a
flat cable as it was in the same case). I forget the details, but
certainly nothing as hairy as a floppy or hard disk controller.

Anyway, suppose there was a programmable controller involved; how many
lines of line would be needed? Would it really be necessary to use C;
does no other language - other than the controller's machine code -
exist that works at this level?

[s***@casperkitty.com]

Post by bartc

Post by s***@casperkitty.com
It is possible to build a keyboard controller out of discrete logic, but
unless one wants to have the main processor scan the keyboard using a
timer-tick interrupt (the approach used by the VIC-20 and Commodore 64,
and likely many other machines as well) the amount of logic required is
fairly substantial. Microcontrollers that could act as all-in-one-chip
solutions were developed in the 1970s, so except in cases where the
VIC-20-style keyboard scanning would be practical they provide the cheapest
way of interfacing keyboards.

I don't think the logic is that difficult. You wouldn't have discrete
logic chips (74 series gates etc) anyway, there can be a custom chip but
it needn't be a microcontroller.
The first keyboard I bought was accessed via a 8-bit port; I think the
top bit indicated a key was ready.

The Apple ][ did that using discrete logic and required that the physical
keyboard grid line up with character codes. The Apple //e used a custom
chip for the keyboard so as to be software compatible while offering a
keyboard layout that better matched more recent computers (e.g. putting
parentheses on 9 and 0 rather than 8 and 9, making = a base key rather
than a shifted -, etc.)

While it's certainly possible to use custom logic for a keyboard
controller, using a microcontroller makes it easy to add things like
type-ahead buffering, programmable key repeat, etc. without having to
add circuitry. Even in the 1970s, cheap mask-ROM microcontrollers were,
well, cheap. Although many keyboard controllers were programmed before
there were any C-ish compilers for tiny 8-bit micros, someone in the
late 1970s who had one of today's C-ish compilers for the PIC16C57 (and
something to run it on) could probably have written keyboard controller
firmware more quickly than using assembly language (I no longer have my
old 1970s data book, but I think some of the 1970s General Instruments
PICs used the exact same instruction set as today's Microchip PIC16C57
except that instead of using the OPTION and TRIS instructions to control
RTC/watchdog configuration and port direction, one had to instruct the
factory what settings to use.)

Actually, if I were in charge of standards I would mark many features
like double-precision floating-point math as things that quality
implementations should seek to provide whenever possible, but allow
low-end implementations that couldn't very well provide them to be
recognized as conforming nonetheless. Many of the cases where C offers
the biggest advantages over machine code are those which involve math
larger than a CPU's register size. If x, y, and z are 16 bits, it's
a lot easier to read or write:

x=y+z;

than

movf y,w ; WREG = lower byte of y
addwf z,w ; WREG += lower byte of z
movwf x ; store lower byte of x
movf y+1,w ; WREG = upper byte of y
btfsc 3,0 ; Skip next instruction if carry not set
incf y+1,w ; WREG = 1 + upper byte of y
addwf z+1,w ; WREG += upper byte of z
movwf x+1 ; store upper byte of x

Given how useful C can be on such platforms, it seems a shame that there's
no usable standard for the language on them.

[bartc]

Post by s***@casperkitty.com

Post by bartc
The first keyboard I bought was accessed via a 8-bit port; I think the
top bit indicated a key was ready.

The Apple ][ did that using discrete logic and required that the physical
keyboard grid line up with character codes. The Apple //e used a custom
chip for the keyboard so as to be software compatible while offering a
keyboard layout that better matched more recent computers (e.g. putting
parentheses on 9 and 0 rather than 8 and 9, making = a base key rather
than a shifted -, etc.)
While it's certainly possible to use custom logic for a keyboard
controller, using a microcontroller makes it easy to add things like
type-ahead buffering, programmable key repeat, etc.

My first keyboard had built-in non-programmable repeat. With sensible
settings, it's preferable than programmable. (Which means, on every new
computer, having to find out how to set it. And on some having to find
out how to make it persistent. They always start off too slow.

without having to

Post by s***@casperkitty.com
add circuitry. Even in the 1970s, cheap mask-ROM microcontrollers were,
well, cheap. Although many keyboard controllers were programmed before
there were any C-ish compilers for tiny 8-bit micros, someone in the
late 1970s who had one of today's C-ish compilers for the PIC16C57 (and
something to run it on) could probably have written keyboard controller
firmware more quickly than using assembly language

Maybe, but how long would it have taken, compared with other design
tasks such as drawing the schematics, making the PCB layout, making and
debugging the prototype board (and sourcing all the actual keys and
microswitches)?

Post by s***@casperkitty.com
Actually, if I were in charge of standards I would mark many features
like double-precision floating-point math as things that quality
implementations should seek to provide whenever possible,

Double precision is a big deal. Even on x86, you would avoid 64-bit
floating point if it had to be done in software. You wouldn't demand it
of a microcontroller.

but allow

Post by s***@casperkitty.com
low-end implementations that couldn't very well provide them to be
recognized as conforming nonetheless. Many of the cases where C offers
the biggest advantages over machine code are those which involve math
larger than a CPU's register size. If x, y, and z are 16 bits, it's
x=y+z;
than
movf y,w ; WREG = lower byte of y
addwf z,w ; WREG += lower byte of z
movwf x ; store lower byte of x
movf y+1,w ; WREG = upper byte of y
btfsc 3,0 ; Skip next instruction if carry not set
incf y+1,w ; WREG = 1 + upper byte of y
addwf z+1,w ; WREG += upper byte of z
movwf x+1 ; store upper byte of x

Except that it probably wouldn't be done that way. You'd use a function,
or whatever macro facilities the assembler had. (And actually in those
days I'd have to write my assembler first. I would a few things to make
life easier.)

Programmers will always find a way of not having to do so much work.

[Jerry Stuckle]

Post by bartc

Post by Reinhardt Behm

I think you would be in deep crap without those chips.  They are used in
all kinds of things - from microwave ovens to automobiles to MP3
players.  Nowadays most electronic items use one or more of these chips.
   And the most common language used to program them is C.

Not to forget the keyboard and mouse he is using to post his nonsense.

Between c. 1976 and 1985 I am 99% certain that the keyboards I used did
not contain any microprogrammable controller let alone be coded in C.
(After that I used an ibm pc-compatible keyboard and I have no idea what
went on inside it.)
The point: keyboards don't need to depend on C to function. (Why they
even needed a microcontroller, until it was necessary to support USB, I
don't know.)

Yes, and automobiles can do just fine with a carburetor and a hand crank
to start. Just because keyboards 30 years ago didn't have
microcontrollers means nothing.

Post by bartc
The 'nonsense' you mention is presumably my suggestion to concentrate on
8, 16, 32 and 64-bit data types.

And take most of the electronics in your house and car back to the 1960's.

Post by bartc
This is the same nonsense as adopted by Java, Go, D, C# and Rust. How
are /those/ used on microcontrollers? Or do they just leave that side of
things to C!

Those languages aren't used on microcontrollers.

Post by bartc
Well, I'm sure it's been suggested many times that C should have split
into a language still suitable for all those dozens of assorted devices,
and a one aimed at the sorts of processors we're all using when posting
to usenet or running compilers.

You can keep suggesting it. The rest of the world disagrees with you.
But hey - you're free to create your own language.

Post by bartc
Then you can streamline each one, rather than ALL users still running
around trying to figure out exactly how wide 'long' is or what stdint.h
type is best or what print format needs to be used.

C already does that - without being split into multiple languages.
That's one of its powers.

[s***@casperkitty.com]

Post by bartc
char 8 bits
short 16
int 32
long 64
long long 128 (Optional)

How about allowing the sizes to be configured via compiler options or
directives that precede the first usage of the types in question?
Compilers for the Macintosh in the 1980s were able to process "int" as
either 16 or 32 bits, and most modern processors should have little
difficulty handling any combination of power-of-two integer sizes. If
code will called upon in some applications to process lots of values
smaller than two billion, but in other applications it may need to
process much larger values, having it use "long" but changing the
compiler configuration based upon requirements would allow the code
to be more efficient in the first application (32-bit values can be
cached twice as efficiently as 64-bit ones) but also satisfy the needs
of the latter application when built for 64-bit "int".

[bartc]

Post by s***@casperkitty.com

Post by bartc
char 8 bits
short 16
int 32
long 64
long long 128 (Optional)

How about allowing the sizes to be configured via compiler options or
directives that precede the first usage of the types in question?

Then you lose the advantage of just /knowing/ that int is 32 bits.

Suppose you want to combine several sets of functions from different
sources into one module, but they make different assumptions about 'int'
or each requires different set up.

But then, they will all be using common code in this application which
has its own requirements for int.

Post by s***@casperkitty.com
Compilers for the Macintosh in the 1980s were able to process "int" as
either 16 or 32 bits,

Didn't that use the 68K? That couldn't make up its mind if it was a 16-
or 32-bit device. The rest of the microcomputer world was in transition
(I didn't switch 'int' 16-bit to 32-bit until 2002 I think).

Now, for the main processors used in computers, an int of 32 bits is
expected, but there is no pressing need for it to be 64 bits, especially
if 'long' fills that role.

If int was 32, and long was 64 bits, then people would just use one or
the other, or both.

(In my dynamic language, there is one main 'int' type and that is 64
bits. Narrower ones are for packed storage. In the static one, 'int' is
32 bits and 'dint' is 64 bits, while 'intm' is the machine's native word
size and will be 32 or 64 bits.)

Post by s***@casperkitty.com
and most modern processors should have little
difficulty handling any combination of power-of-two integer sizes. If
code will called upon in some applications to process lots of values
smaller than two billion, but in other applications it may need to
process much larger values, having it use "long" but changing the
compiler configuration based upon requirements would allow the code
to be more efficient in the first application (32-bit values can be
cached twice as efficiently as 64-bit ones) but also satisfy the needs
of the latter application when built for 64-bit "int".

You mean that the same application can be built for 32- or 64-bit
machines, but with different limitations? So that the 32-bit/2GB machine
doesn't waste effort on 64-bit ops that would never be needed because
counts won't go above 32 bits.

Something like my idea of using 'intm' might come in useful here, which
adapts itself to the machine. (Doesn't size_t do what in C?)

But I did face such a problem (whether my interpreter should use 32-bit
internal byte-code or 64-bit (byte-code includes pointers). But there
were some other complications and in the end I used 64-bit for both, for
simplicity.

[s***@casperkitty.com]

Post by bartc

Post by s***@casperkitty.com
How about allowing the sizes to be configured via compiler options or
directives that precede the first usage of the types in question?

Then you lose the advantage of just /knowing/ that int is 32 bits.

Almost no code can be expected to work usefully on a compiler that is
not configured properly for use with it. I would like to see standardized
way by which code could specify a configuration via directives and either
have a compiler automatically configure itself to fit the indicated
requirements or refuse compilation when able to do so, but compilers
must be configured *somehow*.

If configurable int sizes were seen as a desirable feature, however, then
code which expects "int" to be 32 bits would not be limited to platforms
where "int" would default to 32 bits, but would also be usable on those
where it would default to some other size but could be configured to be
32 bits anyway.

Post by bartc
Suppose you want to combine several sets of functions from different
sources into one module, but they make different assumptions about 'int'
or each requires different set up.

Combining such functions in one module would likely not be possible unless
a compiler included directives that could be used within a source file. On
the other hand, a build system could allow compilation units with different
integer sizes to be combined within a single program if it has a directive
to request name mangling based on parameter types [used mainly for library
functions] and code which doesn't use that directive uses fixed-sized types
in its interfaces.

Provided that it's possible to specify data types with particular sizes and
semantics when needed, having other more "flexible" ways of specifying data
types may improve efficiency as well, especially if it's possible to give
compilers more flexibility than they now have (e.g. declare a type which
will need to hold values -5000..+5000, but which a compiler may replace with
a larger type at its convenience. On many processors, code like:

T array[50000];
for (unsigned i=0; i<50000; i++) T[i]=1234;

will run faster if T is int16_t than if it's int32_t, but code like:

T foo;
....
foo++;
if (foo) ...;

would run slower with int16_t than int32_t [on a system where "int"
is 32 bits, incrementing an int16_t that holds 32767 would have to yield
-32768 unless an implementation documents that it adds code that would slow
down in-range computations]. Having a type that could behave as int16_t in
the former scenario but could (at the compiler's discretion) behave as
int32_t in the latter, would allow more efficient code generation than would
be possible under today's rules.

Post by bartc

Post by s***@casperkitty.com
Compilers for the Macintosh in the 1980s were able to process "int" as
either 16 or 32 bits,

Didn't that use the 68K? That couldn't make up its mind if it was a 16-
or 32-bit device. The rest of the microcomputer world was in transition
(I didn't switch 'int' 16-bit to 32-bit until 2002 I think).

On the 68000, most 16-bit operations had a slight speed advantage over
32-bit operations. On today's processors, even those which without
question are "64-bit" systems, operations on smaller types will still
often have a speed advantage over those on larger ones, either because
of vectorization or because of caching issues.

In addition, by the time people were writing C compilers for the Macintosh
there was already a lot of C code that had been written for 16-bit systems,
and an option to make "int" be 16 bits made it easier to port such code
for use on the Macintosh.

Post by bartc
Now, for the main processors used in computers, an int of 32 bits is
expected, but there is no pressing need for it to be 64 bits, especially
if 'long' fills that role.

Is there any reason "long long" or "int64_t" couldn't fulfill the need for
a longer type just as well?

Since the mid 1980s, a lot of code has been written with the premise that:

char -- 8
short -- 16
int -- 16 or 32
long -- 32

Obviously such types won't work on a 36-bit system, but I see no reason why
a compiler for an octet-based machine shouldn't be configurable to work with
code that expects such types.

Post by bartc

Post by s***@casperkitty.com
and most modern processors should have little
difficulty handling any combination of power-of-two integer sizes. If
code will called upon in some applications to process lots of values
smaller than two billion, but in other applications it may need to
process much larger values, having it use "long" but changing the
compiler configuration based upon requirements would allow the code
to be more efficient in the first application (32-bit values can be
cached twice as efficiently as 64-bit ones) but also satisfy the needs
of the latter application when built for 64-bit "int".

You mean that the same application can be built for 32- or 64-bit
machines, but with different limitations? So that the 32-bit/2GB machine
doesn't waste effort on 64-bit ops that would never be needed because
counts won't go above 32 bits.

That would be one purpose. Though if an implementation could use name
mangling for routines that have types like "int" in their signatures
it would even be possible to combine pieces of code that have different
expectations about integer sizes into one program. The only cases that
would be particularly problematic would be those where it's necessary
to pass a va_list to code that does not expect to pass arguments using
the largest size of object [if all arguments are physically passed as
64 bits, then code which passes a 16-bit "int" to a variadic function
would need to truncate it to 16 bits and then sign-extend it to 64,
and the code that fetches the argument wouldn't have to know or care
what the original size was].

Post by bartc
Something like my idea of using 'intm' might come in useful here, which
adapts itself to the machine. (Doesn't size_t do what in C?)

I think size_t exists because of platforms like large- or compact-model
8086 or 80286 where pointers are 32 bits, but pointer arithmetic is
limited to a 64K range within any given segment. No individual object is
going to exceed 64K, so there's no need to have sizeof() yield a value
larger than a 16-bit "unsigned". Incidentally, on many such systems,
ptrdiff_t behaves interestingly. Given any two pointers p and q to
different parts of the same object, it's possible that the difference
between p and q will exceed +/- 32768, but p+(q-p)==q will hold anyway.
The Standard doesn't require that, and some pedants might claim such a
thing only works by happenstance, but I think those who designed such
implementations were well aware of the useful properties of modular
arithmetic.

[Keith Thompson]

Post by s***@casperkitty.com

Post by bartc
char 8 bits
short 16
int 32
long 64
long long 128 (Optional)

How about allowing the sizes to be configured via compiler options or
directives that precede the first usage of the types in question?

How about having a distinct copy of the entire standard library (which
is largely defined in terms of the existing predefined types) for each
supported combination of user-defined sizes?

On my system, I can compile a program with default options (x86_64),
with "-m32" (x86), and with "-mx32". Each generates an executable
that links to a lib.so file (which provides the standard library
implementation) in a different directory.

That's not a real problem. Each option essentially specifies a distinct
target environment, and each environment needs its own library
implementation. But letting the user specify the characteristics of the
environment would cause the problem space to blow up.

Infinite flexibility has a cost.

It wouldn't be terribly difficult to do as you suggest. I suspect it
hasn't been done because it truly wouldn't be very useful. We already
have integer types of all useful sizes. Arbitrarily mapping them to C's
predefined types names doesn't buy us much. (Yes, I know about the
issues with arithmetic on types narrower than int.)

[...]

[Gordon Burditt]

Post by s***@casperkitty.com

Post by bartc
char 8 bits
short 16
int 32
long 64
long long 128 (Optional)

How about allowing the sizes to be configured via compiler options or
directives that precede the first usage of the types in question?

Libraries would have problems, though.

Post by s***@casperkitty.com
Compilers for the Macintosh in the 1980s were able to process "int" as
either 16 or 32 bits, and most modern processors should have little
difficulty handling any combination of power-of-two integer sizes. If

Does that mean I need 5 different C libraries (or is it 2**5 = 32
different C libraries, the only difference between them being the
sizes of integer types?

Post by s***@casperkitty.com
code will called upon in some applications to process lots of values
smaller than two billion, but in other applications it may need to
process much larger values, having it use "long" but changing the
compiler configuration based upon requirements would allow the code
to be more efficient in the first application (32-bit values can be
cached twice as efficiently as 64-bit ones) but also satisfy the needs
of the latter application when built for 64-bit "int".

Along with fiddling with the basic integer types, there's also
issues like changing the types such as size_t, ptrdiff_t, and the
POSIX type off_t for the offset of a file. Does the maximum size
of a file *CHANGE* with compiler configuration?

[s***@casperkitty.com]

Post by Gordon Burditt

Post by s***@casperkitty.com

Post by bartc
char 8 bits
short 16
int 32
long 64
long long 128 (Optional)

How about allowing the sizes to be configured via compiler options or
directives that precede the first usage of the types in question?

Libraries would have problems, though.

Hardly insurmountable ones.

Post by Gordon Burditt

Post by s***@casperkitty.com
Compilers for the Macintosh in the 1980s were able to process "int" as
either 16 or 32 bits, and most modern processors should have little
difficulty handling any combination of power-of-two integer sizes. If

Does that mean I need 5 different C libraries (or is it 2**5 = 32
different C libraries, the only difference between them being the
sizes of integer types?

Being able to *specify* any combination of integer types does not mean that
every implementation would be required to support every combination. Which
combinations should be supported by quality implementations in various fields
would depend upon the kinds of programs they would be expected to run. In
practice, only a few combinations have had any significant amount of code
targeted toward them.

If one assumes char==8 and none are longer than 64, the actual number of
legal combinations is nine. Among the types with flexible sizes, the
allowable choices would be 16/16/32, 16/16/64, 16/32/32, 16/32/64,
16/64,64, 32/32/32, 32/32/64, 32/64/64, and 64/64/64.

Back in the days of floppy disks, MS-DOS compilers routinely shipped with
six full copies of the C library, for use with different memory models.
The number of common combinations of sizes is fairly small, and even if
one allowed any of the nine combinations, nine isn't terribly huge.

More importantly, on a platform where all scalars get passed using the same
size register or stack slot, the only library functions whose differences
couldn't be trivially handled call-side would be those which accept pointers
of scalar types. If one uses name mangling for those, one could have a
single library in which the few functions that accept pointers to integers
had a different version for each type they could use. Even most of those
could generally be fairly simple wrappers; the only ones that would be
somewhat problematical would be scanf. For those, the best approach would
probably be to have a "base" v*scanf function that accepts an extra
parameter specifying the sizes of integer types, and then have nine (or
however many) sets of wrappers which chain to that from scanf etc. while
passing the extra argument.

Post by Gordon Burditt

Post by s***@casperkitty.com
code will called upon in some applications to process lots of values
smaller than two billion, but in other applications it may need to
process much larger values, having it use "long" but changing the
compiler configuration based upon requirements would allow the code
to be more efficient in the first application (32-bit values can be
cached twice as efficiently as 64-bit ones) but also satisfy the needs
of the latter application when built for 64-bit "int".

Along with fiddling with the basic integer types, there's also
issues like changing the types such as size_t, ptrdiff_t, and the
POSIX type off_t for the offset of a file. Does the maximum size
of a file *CHANGE* with compiler configuration?

Those aren't generally as much of an issue as the other types. Typically
size_t will either be unsigned or unsigned long (a distinction which would
only matter if those two types were distinct) and most code won't have
any particular problem if size_t is bigger than it would need to be.

[Ben Bacarisse]

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

<snip>

[David Kleinecke]

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long. I had an argument once that the longest
practical size for the arithmetic procession was 128 bits
but I have forgotten it now. Anyway it was only subjective.
If arithmetic were 128 bits then a long long would be 512
bits long. We aren't quite there yet. But who knows?

[Ben Bacarisse]

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about

You talked about it. I no longer think I know what you said about it,
but you definitely talked about it. The words you used seemed to
suggest that it would not longer exist.

Post by David Kleinecke
but it is obvious what it means - a value twice as
long as a long.

How could that be obvious? It's not what C means by long long, and you
seemed to suggest that long long would no longer exist according to some
plan of yours. That would leave only two obvious possibilities: (a)
that long long would not longer exist; or (b) that long long would
remain what it always was which is /not/ twice as long as long.

<snip>

[David Kleinecke]

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about

You talked about it. I no longer think I know what you said about it,
but you definitely talked about it. The words you used seemed to
suggest that it would not longer exist.

Post by David Kleinecke
but it is obvious what it means - a value twice as
long as a long.

How could that be obvious? It's not what C means by long long, and you
seemed to suggest that long long would no longer exist according to some
plan of yours. That would leave only two obvious possibilities: (a)
that long long would not longer exist; or (b) that long long would
remain what it always was which is /not/ twice as long as long.

I'm not trying to lay down any laws. All I insist on as
a desideratum is that "int" mean whatever the arithmetic
execution register's(s'?) length is. The other possible
variable sizes are (aside from "char") specified as
"short", "long", "short short" etc. - "long" meaning
"twice" and "short" meaning "half".

Note that all the various "short"s are effectively storage
only concepts just like "char". I think the standards allow
this. How "long"s work would be implementation-defined. I
think the usual assumption is that a "long" looks, under the
hood, like a two-member struct - both members "int". A
"long long" would, I think, be like a four member struct of
"int" or a two member struct of "long".

I am assuming that the memory fetch size is the same as the
arithmetic register. It could be smaller but if it were
larger I don;t understand where the excess bytes go.

[Richard Damon]

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about

You talked about it. I no longer think I know what you said about it,
but you definitely talked about it. The words you used seemed to
suggest that it would not longer exist.

Post by David Kleinecke
but it is obvious what it means - a value twice as
long as a long.

How could that be obvious? It's not what C means by long long, and you
seemed to suggest that long long would no longer exist according to some
plan of yours. That would leave only two obvious possibilities: (a)
that long long would not longer exist; or (b) that long long would
remain what it always was which is /not/ twice as long as long.

I'm not trying to lay down any laws. All I insist on as
a desideratum is that "int" mean whatever the arithmetic
execution register's(s'?) length is. The other possible
variable sizes are (aside from "char") specified as
"short", "long", "short short" etc. - "long" meaning
"twice" and "short" meaning "half".
Note that all the various "short"s are effectively storage
only concepts just like "char". I think the standards allow
this. How "long"s work would be implementation-defined. I
think the usual assumption is that a "long" looks, under the
hood, like a two-member struct - both members "int". A
"long long" would, I think, be like a four member struct of
"int" or a two member struct of "long".
I am assuming that the memory fetch size is the same as the
arithmetic register. It could be smaller but if it were
larger I don;t understand where the excess bytes go.

First, long does NOT need to be bigger than in int in C, and that is
long established, it only needs to be no smaller than int. long was the
type that had at least 32 bits. int only needs to have 16 bits, but
might also have more, like 32 bits, at which point long could be the
same size as it. Yes, some things might have been easier if long was
defined to be at least twice the size of an int. but it isn't.

short also wasn't half an int, on many early machines both were 16 bit.

As to int being the memory fetch size, many machines had a double load,
or a quad load, that would fetch 2 or 4 'words' (register sized), into a
set of registers (often consecutive). Frequently these instructions had
limitations on the addressed fetched from and the registers load (the
double word had to be on a double word boundry, and into a register 'pair').

For some 64 bit machines, implementers have decided to leave int at 32
bits instead of the more natural 64 bits for several reason, one is to
have a 'basic' name for all of the types: 8 bit (char), 16 bit (short),
32 bit (int), 64 bit (long), and 128 bit (long long). Another is that
there still is code that just assumes int = 32 bits, that would be
broken making it 64 bits (they just didn't learn from the shift if int
from 16 bits to 32 bits).

[Ben Bacarisse]

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about

You talked about it. I no longer think I know what you said about it,
but you definitely talked about it. The words you used seemed to
suggest that it would not longer exist.

Post by David Kleinecke
but it is obvious what it means - a value twice as
long as a long.

How could that be obvious? It's not what C means by long long, and you
seemed to suggest that long long would no longer exist according to some
plan of yours. That would leave only two obvious possibilities: (a)
that long long would not longer exist; or (b) that long long would
remain what it always was which is /not/ twice as long as long.

I'm not trying to lay down any laws.

And I'm just trying to get you to answer Keith's question: "how much
existing code do you want to break?". This question was prompted (in
part, at least) by your suggestion that long long would no longer
exist.

<snip>

[Keith Thompson]

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

If "long long" no longer exists, all code that depends on it would
break. Is that not obvious?

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse
You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about

But you're talking about some future language, or future *something*.
Are you proposing a new language based on C89?

Post by David Kleinecke

Post by Ben Bacarisse
You talked about it. I no longer think I know what you said about it,
but you definitely talked about it. The words you used seemed to
suggest that it would not longer exist.

Post by David Kleinecke
but it is obvious what it means - a value twice as
long as a long.

How could that be obvious? It's not what C means by long long, and you
seemed to suggest that long long would no longer exist according to some
plan of yours. That would leave only two obvious possibilities: (a)
that long long would not longer exist; or (b) that long long would
remain what it always was which is /not/ twice as long as long.

I'm not trying to lay down any laws. All I insist on as
a desideratum is that "int" mean whatever the arithmetic
execution register's(s'?) length is. The other possible
variable sizes are (aside from "char") specified as
"short", "long", "short short" etc. - "long" meaning
"twice" and "short" meaning "half".

You can insist on anything you like. It matters only if you
define your own non-C language, which you'd then be free to discuss
elsewhere. If you're talking about C, the answer is going to be
"no".

In C, "long" does not mean twice, and "short" does not mean half,
and they never have. (The PDP-11 had 16-bit short, 16-bit int,
and eventually 32-bit long.)

Post by David Kleinecke
Note that all the various "short"s are effectively storage
only concepts just like "char". I think the standards allow
this.

That depends on what you mean by "storage only concepts". In actual
C, short and int are both integer types. Values of type short
are promoted to a wider type before any arithmetic operations are
applied to them, but conversions can be applied directly to values
of narrow types.

Post by David Kleinecke
How "long"s work would be implementation-defined. I
think the usual assumption is that a "long" looks, under the
hood, like a two-member struct - both members "int". A
"long long" would, I think, be like a four member struct of
"int" or a two member struct of "long".

That bears no apparent resemblance to the way C's long and long
long types work. What language are you talking about?

Post by David Kleinecke
I am assuming that the memory fetch size is the same as the
arithmetic register. It could be smaller but if it were
larger I don;t understand where the excess bytes go.

There's no requirement in C for int to be the size of a register. It
is intended to have "the natural size suggested by the architecture
of the execution environment", but that's vague enough that different
implementations for the same CPU can have different sizes for int
(though it's commonly constrained by an ABI). I'm typing this
message on a system with 64-bit registers and 32-bit ints.

[David Kleinecke]

Post by Keith Thompson

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

If "long long" no longer exists, all code that depends on it would
break. Is that not obvious?

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Ben Bacarisse
You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about

But you're talking about some future language, or future *something*.
Are you proposing a new language based on C89?

Post by David Kleinecke

Post by Ben Bacarisse
You talked about it. I no longer think I know what you said about it,
but you definitely talked about it. The words you used seemed to
suggest that it would not longer exist.

Post by David Kleinecke
but it is obvious what it means - a value twice as
long as a long.

How could that be obvious? It's not what C means by long long, and you
seemed to suggest that long long would no longer exist according to some
plan of yours. That would leave only two obvious possibilities: (a)
that long long would not longer exist; or (b) that long long would
remain what it always was which is /not/ twice as long as long.

I'm not trying to lay down any laws. All I insist on as
a desideratum is that "int" mean whatever the arithmetic
execution register's(s'?) length is. The other possible
variable sizes are (aside from "char") specified as
"short", "long", "short short" etc. - "long" meaning
"twice" and "short" meaning "half".

You can insist on anything you like. It matters only if you
define your own non-C language, which you'd then be free to discuss
elsewhere. If you're talking about C, the answer is going to be
"no".
In C, "long" does not mean twice, and "short" does not mean half,
and they never have. (The PDP-11 had 16-bit short, 16-bit int,
and eventually 32-bit long.)

Post by David Kleinecke
Note that all the various "short"s are effectively storage
only concepts just like "char". I think the standards allow
this.

That depends on what you mean by "storage only concepts". In actual
C, short and int are both integer types. Values of type short
are promoted to a wider type before any arithmetic operations are
applied to them, but conversions can be applied directly to values
of narrow types.

Post by David Kleinecke
How "long"s work would be implementation-defined. I
think the usual assumption is that a "long" looks, under the
hood, like a two-member struct - both members "int". A
"long long" would, I think, be like a four member struct of
"int" or a two member struct of "long".

That bears no apparent resemblance to the way C's long and long
long types work. What language are you talking about?

Post by David Kleinecke
I am assuming that the memory fetch size is the same as the
arithmetic register. It could be smaller but if it were
larger I don;t understand where the excess bytes go.

There's no requirement in C for int to be the size of a register. It
is intended to have "the natural size suggested by the architecture
of the execution environment", but that's vague enough that different
implementations for the same CPU can have different sizes for int
(though it's commonly constrained by an ABI). I'm typing this
message on a system with 64-bit registers and 32-bit ints.

The standard (C89 if they differ) allows the integer types to have
a wide variety of implementations. I am proposing one possible
system of implementations. I believe I have not proposed anything
the standards forbid. And I offered a reason - which I feel is the
most natural one - for why I made such a proposal.

How and why all the other current ways to handle the integer types
were proposed is relevant only in comparison with my proposal.

And I do not assume the standard library. In the sense that I do
not treat it as in any way privileged or a priori obvious. But it
is available as any other library might be. "stdio" is very
useful.

[Keith Thompson]

David Kleinecke <***@gmail.com> writes:
[...]

Post by David Kleinecke
The standard (C89 if they differ) allows the integer types to have
a wide variety of implementations. I am proposing one possible
system of implementations. I believe I have not proposed anything
the standards forbid. And I offered a reason - which I feel is the
most natural one - for why I made such a proposal.

You have proposed eliminating long long, which is of course forbidden
by C99 and C11 (which replaced C89/C90).

And you have said you "insist" on "long" meaning twice and "short"
meaning half. If you meant that that's your personal preference,
you should have said so.

Post by David Kleinecke
How and why all the other current ways to handle the integer types
were proposed is relevant only in comparison with my proposal.
And I do not assume the standard library. In the sense that I do
not treat it as in any way privileged or a priori obvious. But it
is available as any other library might be. "stdio" is very
useful.

The standard library is an integral part of the C standard (though
freestanding implementations are not required to provide most of it).

What is the intended context for your proposal? Do you want all
implementations to support it? Do you want it to be required by a
future standard?

[David Kleinecke]

Post by Keith Thompson
[...]

Post by David Kleinecke
The standard (C89 if they differ) allows the integer types to have
a wide variety of implementations. I am proposing one possible
system of implementations. I believe I have not proposed anything
the standards forbid. And I offered a reason - which I feel is the
most natural one - for why I made such a proposal.

You have proposed eliminating long long, which is of course forbidden
by C99 and C11 (which replaced C89/C90).
And you have said you "insist" on "long" meaning twice and "short"
meaning half. If you meant that that's your personal preference,
you should have said so.

Post by David Kleinecke
How and why all the other current ways to handle the integer types
were proposed is relevant only in comparison with my proposal.
And I do not assume the standard library. In the sense that I do
not treat it as in any way privileged or a priori obvious. But it
is available as any other library might be. "stdio" is very
useful.

The standard library is an integral part of the C standard (though
freestanding implementations are not required to provide most of it).
What is the intended context for your proposal? Do you want all
implementations to support it? Do you want it to be required by a
future standard?

My proposal - such as it is - should be considered a proposed
discipline not a standard. All I ask is that my discipline fit
within the standard (any standard would do but C89 is simplest
and - I hope - embedded in the later standards).

I am not trying to force anyone to adhere to my disciplines -
all I want is for then to be considered. For example, I don't
use "for" statements. Because their structure feels to me
contrary to the spirit of C and they are easily replaced by
"while" statements. But I don't expect anyone to stop using
"for" just because I said so.

The size-of-int problem is real in some cases (where a certain
size is assumed). If a program makes such an assumption it
seems to me that the first order of business is to check that
invariant.
if (sizeof (int) != 4) exit (666)
for example. This test has to be done at run time (because the
preprocessor doesn't know about "int") and depends on just how
sizeof is implemented. That is, this test assumes that
sizeof (int) is obtained from system information at run time
and is not "hardwired" in by the compiler. I don't know how
any existing compiler (other than mine) determines the value
of sizeof(int).

[bartc]

Post by David Kleinecke

Post by Ben Bacarisse

Post by David Kleinecke

Post by Keith Thompson
[...]

Post by David Kleinecke
Assuming the hardware arithmetic is 64-bit then I think it
would be best to have "short" be 32-bit, char 8-bit and
16-bit "long char". "Wide char" would be more standard but
why introduce a new keyword. "Short short" for 16-bit would
be in the spirit of "long long" (which I assume no longer
would exist).

How much existing code do you want to break?

Ah ha - a major difference in viewpoint.
I wasn't addressing existing code at all. I have no
desire to even bend any of it.

You appeared to suggest the removal of two of standard C integer
types (long long int and, presumably, long long unsigned).

I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.

long long simply means a type at last as wide as a long.

And, on my 64-bit Linux, both long and long long are 64-bit values. But
are different types! (So long long* is incompatible with long*.)

That's why, if you don't need backwards compatibility, it's best to
forget this ancient baggage and start again.

(It's astonishing actually that you had to wait until 1999 - plus a few
more years until it was widely supported - before you could define an
int type of a known width. And this in a low-level language where you'd
think this would be important.)

I had an argument once that the longest

Post by David Kleinecke
practical size for the arithmetic procession was 128 bits
but I have forgotten it now. Anyway it was only subjective.
If arithmetic were 128 bits then a long long would be 512
bits long. We aren't quite there yet. But who knows?

long and long long needn't imply increasing by geometric procession,
although that would be simplest if the latter needs to be wider than the
former.

But a basic 128-bit int (supported by all arithmetic and logical
operators) seems unlikely. The needs for a type wider than even 64 bits
are already outside everyday usage. And for some of those, being
constrained to 128, 256 or 512 bits will still be a limitation (you need
arbitrary precision).

[Ian Collins]

Post by bartc
(It's astonishing actually that you had to wait until 1999 - plus a few
more years until it was widely supported - before you could define an
int type of a known width. And this in a low-level language where you'd
think this would be important.)

We have always been able to specify int type of a known width and every
platform did. The only thing to change was the names being standardised.

[Ben Bacarisse]

<snip>

Post by bartc

Post by David Kleinecke
I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.
long long simply means a type at last as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

<snip>

Post by bartc
That's why, if you don't need backwards compatibility, it's best to
forget this ancient baggage and start again.

C has integer types of known widths (together with the more portable
u?int_fastN_t and u?int_leastN_t variants) so rather than starting again
(what does that even mean?), just start using them.

<snip>

[bartc]

Post by Ben Bacarisse
<snip>

Post by bartc

Post by David Kleinecke
I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.
long long simply means a type at l[e]ast as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

So, what does it mean then?

And yes, it is confusing. While every other language has four distinct
types covering the VERY common widths 8, 16, 32, 64 bits, C has to have
5 types A B C D E which have no predefined widths, except that A is at
least 8 bits, C is at least 16 but might be 32, D at least 32 but might
be 64 and that each successive type is not narrower than the last. Or
maybe all of them are exactly 77 bits.

So, if you're coding for x86, which one, if any, is 32 bits, and no
wider, on both Windows and Linux?

[Keith Thompson]

Post by bartc

Post by Ben Bacarisse
<snip>

Post by bartc

Post by David Kleinecke
I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.
long long simply means a type at l[e]ast as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

So, what does it mean then?

The answer to your question is in n1570.pdf.

Post by bartc
And yes, it is confusing. While every other language has four distinct
types covering the VERY common widths 8, 16, 32, 64 bits, C has to have
5 types A B C D E which have no predefined widths, except that A is at
least 8 bits, C is at least 16 but might be 32, D at least 32 but might
be 64 and that each successive type is not narrower than the last. Or
maybe all of them are exactly 77 bits.

*Every* other language? Nope. But most of those languages came after C.

The designers of the languages you're referring to felt it was more
important for the predefined types to have fixed sizes across all
implementations. The designers of C felt it was more important for the
predefined types to have sizes appropriate to a given target system.
I'm not necessarily going to argue that C is right and the others are
wrong, but there are valid arguments for both designs. And if you need
fixed-width types, C has <stdint.h>.

Java, as I recall, has fixed sizes for its predefined types. What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.

Post by bartc
So, if you're coding for x86, which one, if any, is 32 bits, and no
wider, on both Windows and Linux?

int32_t or uint32_t. But you already knew that.

[bartc]

Post by Keith Thompson

Post by bartc

Post by Ben Bacarisse
<snip>

Post by bartc

Post by David Kleinecke
I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.
long long simply means a type at l[e]ast as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

So, what does it mean then?

The answer to your question is in n1570.pdf.

Why do you guys do this?

Obviously there must be some nuance that I've missed out, but then both
of you suggest I can find the answer in a 700-page reference manual.

WHY DON'T YOU JUST SAY WHAT IT IS?

Is the information copyrighted? Or are you playing this like a radio DJ
who throws out some trivia question then teases the audience by
stringing it out as long as possible before the answer is revealed.

FWIW I've looked at every instance of 'long long' and all it does is go
on and on about ranks, about the order in which constants are converted
to int types, about format codes, about the allowed combinations and
longs and ints, or it just appears in the declarations certain standard
functions.

Give me a clue please.

Post by Keith Thompson

Post by bartc
And yes, it is confusing. While every other language has four distinct
types covering the VERY common widths 8, 16, 32, 64 bits, C has to have
5 types A B C D E which have no predefined widths, except that A is at
least 8 bits, C is at least 16 but might be 32, D at least 32 but might
be 64 and that each successive type is not narrower than the last. Or
maybe all of them are exactly 77 bits.

*Every* other language? Nope. But most of those languages came after C.

Any other language that makes as much of a meal about it as C does?

Post by Keith Thompson
The designers of the languages you're referring to felt it was more
important for the predefined types to have fixed sizes across all
implementations. The designers of C felt it was more important for the
predefined types to have sizes appropriate to a given target system.

Which is ironic, considering that C is the one that is supposed to
'close to the iron'. (If there's a pun in there then it's unintended.)

And it doesn't excuse why there are usually 5 types representing 4
different sizes.

Post by Keith Thompson
I'm not necessarily going to argue that C is right and the others are
wrong, but there are valid arguments for both designs. And if you need
fixed-width types, C has <stdint.h>.
Java, as I recall, has fixed sizes for its predefined types. What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.

What does that even mean? And has anybody ever actually used such a type?

(How do you say in Ada that you want a type that can represent at least
the range 0 to 16383?)

Post by Keith Thompson

Post by bartc
So, if you're coding for x86, which one, if any, is 32 bits, and no
wider, on both Windows and Linux?

int32_t or uint32_t. But you already knew that.

The context here is the classic pre-C99 which is what the OP is
interested in.

And even in C99 and later, int32_t etc is a poor solution. People want
to just write 'int' and be able to use "%d" and "INT_MAX".

[bartc]

Post by bartc
Which is ironic, considering that C is the one that is supposed to
'close to the iron'. (If there's a pun in there then it's unintended.)

I meant 'close to the metal' anyway. I must have been thinking about Rust.

Post by bartc

Post by Keith Thompson
What if I
want a type that's at least N bits and as efficient as possible?  I can
do that in C.

What does that even mean? And has anybody ever actually used such a type?

FWIW there appears to be no instance of int_leastN_t in 21 million lines
of Linux kernel code.

[Keith Thompson]

[...]

Post by bartc

Post by bartc

Post by Keith Thompson
What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.

What does that even mean? And has anybody ever actually used such a type?

FWIW there appears to be no instance of int_leastN_t in 21 million lines
of Linux kernel code.

So you *did* know about the int_leastN_t types. Why did you pretend not
to understand?

[Keith Thompson]

Post by Keith Thompson
[...]

Post by bartc

Post by bartc

Post by Keith Thompson
What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.

What does that even mean? And has anybody ever actually used such a type?

FWIW there appears to be no instance of int_leastN_t in 21 million lines
of Linux kernel code.

So you *did* know about the int_leastN_t types. Why did you pretend not
to understand?

Sorry, my mistake. I was referring to the [u]int_fastN_t types.
You demonstrated familiarity with the int_leastN_t types. But I
don't believe you know about one but not the other.

[David Brown]

Post by bartc

Post by Keith Thompson

Post by bartc

Post by Ben Bacarisse
<snip>

Post by bartc

Post by David Kleinecke
I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.
long long simply means a type at l[e]ast as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

So, what does it mean then?

The answer to your question is in n1570.pdf.

Why do you guys do this?
Obviously there must be some nuance that I've missed out, but then both
of you suggest I can find the answer in a 700-page reference manual.
WHY DON'T YOU JUST SAY WHAT IT IS?

Perhaps because it has been already said dozens of times here? Perhaps
Keith has specifically told you exactly what it means already? I can't
claim to have such a good memory, but it is a recurring theme in c.l.c.
that you claim something is confusing, or claim you don't know
something, or claim something works in a way it does not - and it is
patiently explained to you along with references to the standards. And
you then claim it is all so difficult, so confusing, with "unexpected
twists" - instead of just reading the standard, or looking at a decent
reference source.

Yes, the C standard can be a bit hard to read. But you are claiming to
be writing a C compiler - your task is impossible without the standard.
You can choose to follow the standard, or diverge from it - that is up
to you, as long as you are clear about it. But you need to know what
the standard says. You should have a copy under your pillow, and a pdf
of it open on your desktop at all times. Yes, it will take and effort
for you take to get familiar with it - put in that time and effort.

For a more convenient (and better organised) reference, I like
cppreference.com. It covers C and C++. The apge you are looking for
here is:

<http://en.cppreference.com/w/c/language/arithmetic_types>

You'll also find this useful:

<http://en.cppreference.com/w/c/language/type>


Now, if you have read these two pages and /still/ don't know what a
"long long" is, and why neither "twice as long as long" nor "at least as
wide as long" is a description of the type, then ask again. I promise I
will then give you an explanation.

Post by bartc
Is the information copyrighted? Or are you playing this like a radio DJ
who throws out some trivia question then teases the audience by
stringing it out as long as possible before the answer is revealed.
FWIW I've looked at every instance of 'long long' and all it does is go
on and on about ranks, about the order in which constants are converted
to int types, about format codes, about the allowed combinations and
longs and ints, or it just appears in the declarations certain standard
functions.
Give me a clue please.

Post by Keith Thompson

Post by bartc
And yes, it is confusing. While every other language has four distinct
types covering the VERY common widths 8, 16, 32, 64 bits, C has to have
5 types A B C D E which have no predefined widths, except that A is at
least 8 bits, C is at least 16 but might be 32, D at least 32 but might
be 64 and that each successive type is not narrower than the last. Or
maybe all of them are exactly 77 bits.

*Every* other language? Nope. But most of those languages came after C.

And most other languages are not suitable for the breadth of targets
that C works with. I dismissed D (supposedly a "better C") many years
ago as being useless for my kind of work - precisely because it was
fixed at 32-bit. That is fine for many uses, and can simplify some
things - but it also makes it useless for work on 8-bit microcontrollers
(which /vastly/ outnumber the x86 cpus of this world). Different
languages are useful for different purposes, so if D, or Go, or Java, or
whatever suits your needs, then use that. If you want to use C, learn C
and use it - with the understanding that some features exist because it
is not limited to the ARM/x86 world.

Post by bartc
Any other language that makes as much of a meal about it as C does?

Post by Keith Thompson
The designers of the languages you're referring to felt it was more
important for the predefined types to have fixed sizes across all
implementations. The designers of C felt it was more important for the
predefined types to have sizes appropriate to a given target system.

Which is ironic, considering that C is the one that is supposed to
'close to the iron'. (If there's a pun in there then it's unintended.)
And it doesn't excuse why there are usually 5 types representing 4
different sizes.

Post by Keith Thompson
I'm not necessarily going to argue that C is right and the others are
wrong, but there are valid arguments for both designs. And if you need
fixed-width types, C has <stdint.h>.
Java, as I recall, has fixed sizes for its predefined types. What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.

What does that even mean? And has anybody ever actually used such a type?

He means that C has types like int_least16_t that are as efficient as
possible on the target, with at least 16 bits precision. C already has
these types in the standard!

It does not have types like uint_least27_t for those that want 27 bit
types, but that's because the number of users is going to be rather
small. But the standard says how they should work, if an implementation
wants to provide them.

Post by bartc
(How do you say in Ada that you want a type that can represent at least
the range 0 to 16383?)

Try asking in an Ada newsgroup.

Post by bartc

Post by Keith Thompson

Post by bartc
So, if you're coding for x86, which one, if any, is 32 bits, and no
wider, on both Windows and Linux?

int32_t or uint32_t. But you already knew that.

The context here is the classic pre-C99 which is what the OP is
interested in.

The context in this group is C. Currently, the standard is C11, but
there are still many implementations in use that are C99. C89-only
compilers are rare. It's fine to want to extend C with new features -
it is meaningless to want to extend an outdated version of C. It's like
telling people you have a new invention that will change their futures,
but first we need to roll back to 1989 and scrap all inventions since then.

Post by bartc
And even in C99 and later, int32_t etc is a poor solution. People want
to just write 'int' and be able to use "%d" and "INT_MAX".

/You/ might want to do that. Other people are quite happy with writing
"int32_t" and friends.

[bartc]

Post by David Brown

Post by bartc

Post by Keith Thompson
The answer to your question is in n1570.pdf.

Why do you guys do this?
Obviously there must be some nuance that I've missed out, but then both
of you suggest I can find the answer in a 700-page reference manual.
WHY DON'T YOU JUST SAY WHAT IT IS?

Perhaps because it has been already said dozens of times here? Perhaps
Keith has specifically told you exactly what it means already?

And yours is the third post that beats around the bush.

I said 'long long is a type at least as wide as a long'. Someone else
said 'no it isn't'.

So what did I say wrong? No one is willing to tell me.

Post by David Brown
There are lots of example of long
long being at least as wide a long (indeed it must be). The error was
to say that that is all that long long must be.

So this finally admits that what I said wasn't actually wrong (as
someone else might have thought from 'No it isn't').

I'm starting to think this might be some sort of a wind up.

Post by David Brown
Yes, the C standard can be a bit hard to read. But you are claiming to
be writing a C compiler - your task is impossible without the standard.

That compiler already exists and seems to work well enough. (But I'm
still trying to find a satisfactory code generator that both generates
reasonable code and is simple.)

So whatever the misunderstanding with long long is, that hasn't affected
that project.

Post by David Brown
The apge you are looking for
<http://en.cppreference.com/w/c/language/arithmetic_types>

What does that say about the matter that contradicts my statement?

Post by David Brown

Post by bartc

Post by Keith Thompson
*Every* other language? Nope. But most of those languages came after C.

And most other languages are not suitable for the breadth of targets
that C works with. I dismissed D (supposedly a "better C") many years
ago as being useless for my kind of work - precisely because it was
fixed at 32-bit.

Thanks, that's another for my list.

That is fine for many uses, and can simplify some

Post by David Brown
things - but it also makes it useless for work on 8-bit microcontrollers
(which /vastly/ outnumber the x86 cpus of this world).

8-bit microcontrollers are a niche use and ought to use a niche
language. Not lumber the design choices such a language needs on
everyone else using proper computers.

Different

Post by David Brown
languages are useful for different purposes, so if D, or Go, or Java, or
whatever suits your needs, then use that. If you want to use C, learn C
and use it - with the understanding that some features exist because it
is not limited to the ARM/x86 world.

C is used EXTENSIVELY in the ARM/x86 world, and therefore we're stuck
with it for many purposes.

Post by David Brown
He means that C has types like int_least16_t that are as efficient as
possible on the target, with at least 16 bits precision. C already has
these types in the standard!

Have you ever used any of these int_least types?

[bartc]

[warning: compiler talk]

Post by bartc

Post by David Brown
But you are claiming to
be writing a C compiler - your task is impossible without the standard.

That compiler already exists and seems to work well enough. (But I'm
still trying to find a satisfactory code generator that both generates
reasonable code and is simple.)

A coincidence, but I'd just today abandoned trying to get one code
generator for it up to speed. I was starting to make plans to port the
much better code generator from my non-C language, before I remembered
/why/ I was persisting with this for the C compiler.

I was using the C compiler as a test bed for a better, more robust code
generator (as there is a lot more challenging C test code about), with
the eventual aims of porting it to my non-C compiler!

So there would be little point. Except to end up with a C compiler with
better code output. For that purpose, there are plenty of alternatives.

(Before putting it aside for good, there are a couple of other
interesting aspects to experiment with:

To create a C interpreter, combined with whole-program compiling, to
instantly run any program. I started this actually but got bored when it
started to work; and found out how slow it was (although still a
magnitude faster than Pico C).

Another is to translate C code to my language. Only for the purposes of
looking at the code; C is too chaotic and sprawling to do the job properly.)

[David Brown]

Post by bartc

Post by bartc

Post by Keith Thompson
The answer to your question is in n1570.pdf.

Why do you guys do this?
Obviously there must be some nuance that I've missed out, but then both
of you suggest I can find the answer in a 700-page reference manual.
WHY DON'T YOU JUST SAY WHAT IT IS?

Perhaps because it has been already said dozens of times here?  Perhaps
Keith has specifically told you exactly what it means already?

And yours is the third post that beats around the bush.
I said 'long long is a type at least as wide as a long'. Someone else
said 'no it isn't'.
So what did I say wrong? No one is willing to tell me.

There are lots of example of long
long being at least as wide a long (indeed it must be).  The error was
to say that that is all that long long must be.

So this finally admits that what I said wasn't actually wrong (as
someone else might have thought from 'No it isn't').

You said "long long simply means a type at l[e]ast as wide as long".
That is incorrect. You were /wrong/ - /actually/ wrong.

A "long long" is at least 64 bits, at at least as wide as "long". It is
a standard integer type, and has a higher rank than "long".

It really is not difficult.

Post by bartc
I'm starting to think this might be some sort of a wind up.

Yes, the C standard can be a bit hard to read.  But you are claiming to
be writing a C compiler - your task is impossible without the standard.

That compiler already exists and seems to work well enough. (But I'm
still trying to find a satisfactory code generator that both generates
reasonable code and is simple.)

You don't know what it is supposed to do, because you haven't read or
understood the C standards. How can you say it works well enough?

Post by bartc
So whatever the misunderstanding with long long is, that hasn't affected
that project.

That may be the case - your limited understanding might happen to be
enough for your limited compiler on a limited choice of platforms. But
unless you know what the C standards say, you don't /know/ where you stand.

Post by bartc

The apge you are looking for
<http://en.cppreference.com/w/c/language/arithmetic_types>

What does that say about the matter that contradicts my statement?

It tells you all you need to know about "long long" - which is /not/
merely that it is "at least the size of long". If that was all that
"long long" meant, there would not be much point in having the type!

Post by bartc

Post by bartc

Post by Keith Thompson
*Every* other language?  Nope.  But most of those languages came
after C.

And most other languages are not suitable for the breadth of targets
that C works with.  I dismissed D (supposedly a "better C") many years
ago as being useless for my kind of work - precisely because it was
fixed at 32-bit.

Thanks, that's another for my list.
  That is fine for many uses, and can simplify some

things - but it also makes it useless for work on 8-bit microcontrollers
(which /vastly/ outnumber the x86 cpus of this world).

8-bit microcontrollers are a niche use and ought to use a niche
language. Not lumber the design choices such a language needs on
everyone else using proper computers.

8-bit microcontrollers are a dominating part of the computing world, not
a "niche". And C works just fine for them. When designing a /new/
language, it probably makes sense to pick your target area - "big"
systems like PC's, small systems, weird systems, etc., rather than
trying to make one language that covers them all. But C is not a new
language - and it certainly does not make sense to try to cripple it for
the very devices that use it most.

On the other hand, for PC programming, if you think C is a good choice
for a program, you are probably wrong. It makes sense for some
low-level work - but even there you should consider alternatives first
unless you have historical baggage. It is a fine choice for an
intermediary language, however.

Post by bartc
   Different

languages are useful for different purposes, so if D, or Go, or Java, or
whatever suits your needs, then use that.  If you want to use C, learn C
and use it - with the understanding that some features exist because it
is not limited to the ARM/x86 world.

C is used EXTENSIVELY in the ARM/x86 world, and therefore we're stuck
with it for many purposes.

It is used extensively on almost /all/ platforms. Most C compilers do
not compile for x86 or ARM. If you count in terms of programmers, x86
and ARM are very popular. But if you count in terms of devices, or C
development tools made, then x86 is negligible and ARM is a small (but
rapidly increasing) player.

Languages like Go and Java are /designed/ to be used on 32-bit targets
with lots of memory. C is designed to be usable on just about anything.

Post by bartc

He means that C has types like int_least16_t that are as efficient as
possible on the target, with at least 16 bits precision.  C already has
these types in the standard!

Have you ever used any of these int_least types?

I haven't needed the int_least types, but I have used the int_fast types.

I don't use them much, because a good deal of my code is target-specific
and I know if I will want an "int16_t" or an "int32_t". But
occasionally I will use "int_fast8_t" and similar types for code that
should work well on both 8-bit AVR devices and 32-bit ARM devices. (The
only 16-bit device I use regularly handles 8-bit and 16-bit types
equally fast.)

I haven't done any programming on DSPs for many years, which is where I
would see the int_least types being useful.

But the point was not whether these types are particularly popular (they
are not), but that C has a perfectly good way to express them.

[bartc]

Post by David Brown
It really is not difficult.

Neither is it difficult to simply post a correction or supplementary
information rather than constantly having to have a go.

Here's what Ben said:

"No it isn't".

Here's what I might have said if I'd noticed the issue in someone else's
post:

"long long also needs to be at least 64 bits; long only needs to be at
least 32 bits".

As to the type system itself being difficult, let's see:

long is at least 32 bits, but presumably there is no upper limit

long long is at least 64 bits

long long must also be at least as wide as long

long long will therefore be at least 1x as wide as long, is typically
1x or 2x as long, but can be N times as long as long. N need not be an
integer.

long and long long are distinct types even when they are the same
width.

We haven't even touched on unsigned/signed versions, symmetry of signed
versions, padding bits, or how many times long long might be wider than int.

And after all that, how wide /is/ a 'long' type? We don't know, except
it's at least 32 bits. Is it longer than 'int'? We don't know.

So yes, it's somewhat more difficult than it needs to be.

Post by David Brown

Post by bartc
That compiler already exists and seems to work well enough. (But I'm
still trying to find a satisfactory code generator that both generates
reasonable code and is simple.)

You don't know what it is supposed to do, because you haven't read or
understood the C standards.  How can you say it works well enough?

Post by bartc
So whatever the misunderstanding with long long is, that hasn't
affected that project.

That may be the case - your limited understanding might happen to be
enough for your limited compiler on a limited choice of platforms.  But
unless you know what the C standards say, you don't /know/ where you stand.

Here are the supported types on that implementation:

char 8 bits
short 16 bits
int 32 bits
long long 64 bits

float 32 bits
double 64 bits

void* 32 or 64 bits depending on hardware

I haven't bothered with 'long' as it simply doesn't fit in to that tidy
pattern. If encountered, then on Windows it will be mapped to 'int',
because on Windows, long is usually the same size as int.

Post by David Brown
On the other hand, for PC programming, if you think C is a good choice
for a program, you are probably wrong.  It makes sense for some
low-level work - but even there you should consider alternatives first
unless you have historical baggage.  It is a fine choice for an
intermediary language, however.

Linux is written in C. Python is written in C. Chunks of Windows have
been written in C. Huge numbers of libraries are written in C and
primarily have C APIs.

It's needed as an implementation language for other things. And as such
you really need to know how big an int is and how big a long is.

It is especially a nuisance for me since I very often have to interface
from such a C API from my language, and may need to exactly duplicate a
struct comprised of shorts, ints, longs and pointers, complete with all
the expected alignment and padding.

C as it is is not precise enough.

[Ben Bacarisse]

Post by bartc

Post by David Brown

Post by bartc

Post by Keith Thompson
The answer to your question is in n1570.pdf.

Why do you guys do this?
Obviously there must be some nuance that I've missed out, but then both
of you suggest I can find the answer in a 700-page reference manual.
WHY DON'T YOU JUST SAY WHAT IT IS?

Perhaps because it has been already said dozens of times here? Perhaps
Keith has specifically told you exactly what it means already?

And yours is the third post that beats around the bush.
I said 'long long is a type at least as wide as a long'. Someone else
said 'no it isn't'.

No you didn't say that. You have edited the quoted material to remove
what you actually said and you have re-worded it here so as to make it a
correct statement. You've even put it in quotes to suggest this is
literal quote. I am trying as hard as I can to believe that that's all
just accidental.

Post by bartc
So what did I say wrong? No one is willing to tell me.

Post by David Brown
There are lots of example of long
long being at least as wide a long (indeed it must be). The error was
to say that that is all that long long must be.

So this finally admits that what I said wasn't actually wrong (as
someone else might have thought from 'No it isn't').

How dare you. You have removed what you really said from the quoted
material, re-worded it to be trivial but true, and then you have the
gall to claim I have finally admitted you were "not actually wrong".[1]

I try to stay calm and polite on Usenet but this exchange is testing
that resolve.

Since you will claim you have no idea what I am talking about here is
what you originally wrote:

| long long simply means a type at l[e]ast as wide as a long.

That is not at all the same as

| long long is a type at least as wide as a long

<snip>

[1] Even the "finally" part is spin. I posted "no it isn't" at 1:38,
just before going to bed, and according to you, I "finally admitted"
something first thing this morning. And in case you think I've since
been avoiding the issue, I've been at a seminar all day.

[bartc]

Post by Ben Bacarisse
I try to stay calm and polite on Usenet but this exchange is testing
that resolve.

It's not me making a mountain out of a molehill.

If there was something amiss with my remark, which was aimed at the
misapprehension that a 'long' attribute always doubles the width of a
type, then you could just have posted a correction.

Instead you seemed to delight in calling me out, without telling me (or
the OP) what was irking you. No else bothered either, and it was the
best part of 24 hours before I find out what was you all had in mind.

Post by Ben Bacarisse
Since you will claim you have no idea what I am talking about here is
| long long simply means a type at l[e]ast as wide as a long.

In response to:

"...is obvious what it means - a value twice as long as a long."

To which someone could have replied to my remark:

"and of at least 64 bits"

if they really thought it was that critical. And that would have been
the end of it.

BTW inflammatory comments like this don't help keeping other people calm
and polite:

"You could have find out what it means if you wanted to, but I expect
you'd rather just complain about how it's all so confusing."

[James Kuyper]

...

Post by David Brown
Now, if you have read these two pages and /still/ don't know what a
"long long" is, and why neither "twice as long as long" nor "at least as
wide as long" is a description of the type, then ask again. I promise I
will then give you an explanation.

"twice as long as long" is inaccurate, because a conforming
implementation can have a "long long" type which violates that
specification - but the same is not true about "at least as wide as
long". I'm not sure why you imply that those two statements are equally
objectionable. Neither is complete, but the second one is both true and
important.

...

Post by David Brown
It does not have types like uint_least27_t for those that want 27 bit
types, but that's because the number of users is going to be rather
small. But the standard says how they should work, if an implementation
wants to provide them.

The standard makes precisely as much provision for uint_least27_t as it
does for int32_t. Both types are optional, but neither the types nor the
corresponding macros can be supported unless the corresponding type is
actually supported in the fashion specified by the standard.

Post by David Brown

Post by bartc
And even in C99 and later, int32_t etc is a poor solution. People want
to just write 'int' and be able to use "%d" and "INT_MAX".

/You/ might want to do that. Other people are quite happy with writing
"int32_t" and friends.

Actually, I'm not. In a new language which had no need to retain
backwards compatibility with C89, I'd have preferred simpler names for
the size-named types. But, unlike Bartc, I'm willing to understand the
necessity of maintaining backwards compatibility, and the corresponding
clumsiness in the way that the language has added new features. For
instance, we should have had "var" meaning "variable" rather than
"const" meaning "constant", because "const" should have been the default
- not that I expect Bartc to agree with me about that particular judgment.

[David Brown]

Post by James Kuyper
...

Post by David Brown
Now, if you have read these two pages and /still/ don't know what a
"long long" is, and why neither "twice as long as long" nor "at least as
wide as long" is a description of the type, then ask again. I promise I
will then give you an explanation.

"twice as long as long" is inaccurate, because a conforming
implementation can have a "long long" type which violates that
specification - but the same is not true about "at least as wide as
long". I'm not sure why you imply that those two statements are equally
objectionable. Neither is complete, but the second one is both true and
important.

When they were given as complete descriptions of "long long", both
statements are wrong. Of course it is better to have a statement that
is true but incomplete, than one that is merely true (and incomplete) on
some platforms.

Post by James Kuyper
...

Post by David Brown
It does not have types like uint_least27_t for those that want 27 bit
types, but that's because the number of users is going to be rather
small. But the standard says how they should work, if an implementation
wants to provide them.

The standard makes precisely as much provision for uint_least27_t as it
does for int32_t. Both types are optional, but neither the types nor the
corresponding macros can be supported unless the corresponding type is
actually supported in the fashion specified by the standard.

Exactly.

Post by James Kuyper

Post by David Brown

Post by bartc
And even in C99 and later, int32_t etc is a poor solution. People want
to just write 'int' and be able to use "%d" and "INT_MAX".

/You/ might want to do that. Other people are quite happy with writing
"int32_t" and friends.

Actually, I'm not. In a new language which had no need to retain
backwards compatibility with C89, I'd have preferred simpler names for
the size-named types.

I did not mean to imply that /all/ other people are quite happy with the
C99 <stdint.h> types - merely that at least /some/ are. Certainly I
have no problem with them, and I see them used regularly by others. I
do know that some people dislike the names, and prefer something like
"i32", or perhaps "int32". (I don't know what names /you/ would
prefer.) Personally, however, I really can't see the fuss - they are
fairly succinct and clear. The names like "int_least8_t" and
"uint_fast16_t" are more cumbersome, and that might affect their
popularity (or lack thereof), but I can't think of significantly better
names.

Post by James Kuyper
But, unlike Bartc, I'm willing to understand the
necessity of maintaining backwards compatibility, and the corresponding
clumsiness in the way that the language has added new features. For
instance, we should have had "var" meaning "variable" rather than
"const" meaning "constant", because "const" should have been the default
- not that I expect Bartc to agree with me about that particular judgment.

For what it is worth, /I/ agree with you here about var and const. I'd
also make "static" the default for file-scope functions and objects, and
require an explicit "extern" or perhaps "public" declaration for
exporting symbols.

[bartc]

Post by David Brown
<http://en.cppreference.com/w/c/language/arithmetic_types>
<http://en.cppreference.com/w/c/language/type>
Now, if you have read these two pages and /still/ don't know what a
"long long" is, and why neither "twice as long as long" nor "at least as
wide as long" is a description of the type, then ask again. I promise I
will then give you an explanation.

I missed this part of your post this morning. Some comments:

* I didn't say that long long is 'twice as long as long'

* My remark that 'long long is at least as wide as long' was in response
to the OP who did say it, in the context of the relative widths of int types

* From what I have been able to glean from other posts, my remark is not
actually wrong.

* After perusing the references that people suggested I look at, the C
standard and the links, I still haven't got a clue as to what as
incorrect or objectionable about my comment

* You imply that I don't know what 'long long' is, which I find farcical.

Let me ask you: what do YOU think that I think 'long long' is? You must
have some idea otherwise you wouldn't be able to say that I got it wrong.

[Keith Thompson]

Post by bartc

Post by Keith Thompson

Post by bartc

Post by Ben Bacarisse
<snip>

Post by bartc

Post by David Kleinecke
I work from C89 so "long long" isn't part of what I talked
about but it is obvious what it means - a value twice as
long as a long.

That's what you would think. But not when dealing with C where
everything has to have an unexpected twist.
long long simply means a type at l[e]ast as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

So, what does it mean then?

The answer to your question is in n1570.pdf.

Why do you guys do this?

[...]

Post by bartc
Give me a clue please.

LLONG_MIN must be no greater than -9223372036854775807, and LLONG_MAX
must be no less than +9223372036854775807, implying that long long must
be at least 64 bits. That's the main point you didn't mention.

[...]

Post by bartc

Post by Keith Thompson
Java, as I recall, has fixed sizes for its predefined types. What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.

What does that even mean? And has anybody ever actually used such a type?

In C it's called int_fastN_t, which exists for at least N = 8, 16, 32,
and 64.

Post by bartc
(How do you say in Ada that you want a type that can represent at least
the range 0 to 16383?)

type Whatever is range 0 .. 16383; -- Why do you ask?

(Ada's predefined integer types are similar to C's, with Integer,
Long_Integer, and so forth. The main difference is that Ada, unlike C,
provides a way to define your own integer types with specified ranges.)

Post by bartc

Post by Keith Thompson

Post by bartc
So, if you're coding for x86, which one, if any, is 32 bits, and no
wider, on both Windows and Linux?

int32_t or uint32_t. But you already knew that.

The context here is the classic pre-C99 which is what the OP is
interested in.

Pre-C99 is obsolete. I don't know why the OP is so interested in it.
And there are implementations of <stdint.h> for pre-C99 implementations
(it's one of the easier features of C99 to implement, so it was often
provided before full C99 compliance was possible).

Post by bartc
And even in C99 and later, int32_t etc is a poor solution. People want
to just write 'int' and be able to use "%d" and "INT_MAX".

Does "People" refer to anyone other than you?

[bartc]

Post by Keith Thompson

Post by bartc
Why do you guys do this?

[...]

Post by bartc
Give me a clue please.

LLONG_MIN must be no greater than -9223372036854775807, and LLONG_MAX
must be no less than +9223372036854775807, implying that long long must
be at least 64 bits. That's the main point you didn't mention.

At last; thank you.

With the minimum widths, I don't go into that for int either, but I
touched on that aspect of it here:

"While every other language has four distinct
types covering the VERY common widths 8, 16, 32, 64 bits, C has to have
types A B C D E which have no predefined widths, except that A is at
least 8 bits, C is at least 16 but might be 32, D at least 32 but might
be 64 and that each successive type is not narrower than the last. Or
maybe all of them are exactly 77 bits."

What I was replying to was the misconception that an extra 'long' will
always double the type's width.

Post by Keith Thompson

Post by bartc
(How do you say in Ada that you want a type that can represent at least
the range 0 to 16383?)

type Whatever is range 0 .. 16383; -- Why do you ask?

I was wondering if there was any annotation that was the equivalent of
'fast' or 'least' in C's int_xxxxN_t types.

[Ben Bacarisse]

<snip>

Post by bartc

Post by Keith Thompson

Post by bartc

Post by Ben Bacarisse

Post by bartc
long long simply means a type at l[e]ast as wide as a long.

No it doesn't. You could have find out what it means if you wanted to,
but I expect you'd rather just complain about how it's all so confusing.

So, what does it mean then?

The answer to your question is in n1570.pdf.

Why do you guys do this?
Obviously there must be some nuance that I've missed out, but then
both of you suggest I can find the answer in a 700-page reference
manual.

If you search for "long long" the second hit shows you that the minimum
permitted width of long long is 64 bits. Since I imagine you know that
long is not required to be that wide, you can conclude that long long is
not simply a type at least as wide as long.

<snip>

Post by bartc
FWIW I've looked at every instance of 'long long' and all it does is
go on and on about ranks, about the order in which constants are
converted to int types, about format codes, about the allowed
combinations and longs and ints, or it just appears in the
declarations certain standard functions.

The first hit tells you that long long appeared in "the second edition"
of ISO C (that's C99) and the second tells you it can't be the same
width as a 32-bit long.

<snip>

[Gordon Burditt]

Post by bartc
long long simply means a type at last as wide as a long.

Example: FreeBSD in the amd64 architure: long and long long are
both 64-bit types.

[Ben Bacarisse]

Post by Gordon Burditt

Post by bartc
long long simply means a type at last as wide as a long.

Example: FreeBSD in the amd64 architure: long and long long are
both 64-bit types.

Please don't reply without attribution lines. You also replied to a
post by me but did not quote anything I wrote.

I don't see how that example helps. There are lots of example of long
long being at least as wide a long (indeed it must be). The error was
to say that that is all that long long must be.

[Noob]

Post by Robert Wessel

Post by Noob

But these ideal ints fail when we multiple. The product of two ints
is - conceptually - twice the size of an int. Hence we need "long".
But C, as it stands, does not implement that situation.

Good compilers have been able to recognize the "widening multiply" pattern
for years, if not decades. I don't think it justifies adding new operators.
Consider the following example, for which gcc (as, I'm sure, all modern
compilers) generates the amd64 code below.
int64_t wide_mult(int32_t u, int32_t v)
{
return (int64_t)u * v;
}
movslq %edi, %rax # copy u to RAX
movslq %esi, %rdi # copy v to RDI
imulq %rdi, %rax # write u*v to RAX
ret

That doesn't help if you want the full result of a multiplication of
the largest type.

Do you mean 64x64->128? GCC supports that as well, of course.

u128 wide_mult(u64 u, u64 v)
{
return (u128)u*v;
}

wide_mult:
movq %rdi, %rax # copy u to RAX
mulq %rsi # write u*v to RDX:RAX
ret

It's possible to write optimized arbitrary-width code using
just C.

Regards.

[bartc]

Post by David Kleinecke
I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.
There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int.

Actually, you have the same problem with add.

Adding two 32-bit values may need 33 bits to represent the result. And
multiplying two 32-bit values may need 64 bits.

But this is C; it's low level and you expect things to silently overflow
or be truncated. Otherwise you'd have to worry about the possibility of:

a*b*c*d*e

requiring 160 bits to represent.

Post by David Kleinecke
Hence we need "long".

"long" in C is not guaranteed to give you a wider type than "int". "long
long" I think is.

But C, as

Post by David Kleinecke
it stands, does not implement that situation.
What we seem to need is operators, call them
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.

Apart from the poor choice of ":=" as operator (I think it's the next
most popular choice for assignment after "="), these operations aren't
intuitive.

And a := b can be replaced by a = b>>32 for example. Or you can do it
via macro: a = MSW(b).

Post by David Kleinecke
In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.

You've lost me here.

[Malcolm McLean]

Post by bartc
Actually, you have the same problem with add.
Adding two 32-bit values may need 33 bits to represent the result. And
multiplying two 32-bit values may need 64 bits.
But this is C; it's low level and you expect things to silently overflow
a*b*c*d*e
requiring 160 bits to represent.

It's not really a problem with add or multiply. The value presumably represents
something. If that something cannot be held in an "int" then you mustn't use
int to hold it.
However the problem is that exceptionally many real life values can go over 2 billion,
eg the number of pixels in an image, whilst usually being comfortably less than that
number, and on many architectures int, which is a default integer type, is only 32
bits for efficiency reasons.

[David Brown]

Post by bartc

Post by David Kleinecke
I look upon the addition of two integers as the
philosophical prototype of computing. I see the
concept of "int" in C as indicating the size of
the integers in the prototypical addition.
There is no reason not to do all integer additions
in registers that are the normal maximum size. So
we may want the concepts of "short" and "char" for
smaller integer types that are extended to "int"
when actually added.
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int.

Actually, you have the same problem with add.
Adding two 32-bit values may need 33 bits to represent the result. And
multiplying two 32-bit values may need 64 bits.
But this is C; it's low level and you expect things to silently overflow
a*b*c*d*e
requiring 160 bits to represent.

Post by David Kleinecke
Hence we need "long".

"long" in C is not guaranteed to give you a wider type than "int". "long
long" I think is.

Nope.

"long long" is guaranteed to be at least 64 bits, and but there is
nothing to say that "int" cannot be just as big (it can't be bigger).
There are certainly C implementations in which "int" is 64 bit. I don't
know details about "long long" on such systems, however.

On most modern systems, int is 32-bit, long long is 64-bit, and long is
either 32-bit (such as Windows 32-bit and 64-bit, and *nix 32-bit) or
64-bit (such as *nix 64-bit).

Post by bartc
But C, as

Post by David Kleinecke
it stands, does not implement that situation.
What we seem to need is operators, call them
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.

Apart from the poor choice of ":=" as operator (I think it's the next
most popular choice for assignment after "="), these operations aren't
intuitive.
And a := b can be replaced by a = b>>32 for example. Or you can do it
via macro: a = MSW(b).

This gets messy very quickly when you have signed integer types. It's
best to stick to unsigned types, use compiler builtins, or accept that
this stuff is usually easier or more efficient with some
implementation-specific assumptions.

Post by bartc

Post by David Kleinecke
In the case of division "b / a" b is a long or
a smaller int extended to long. It is possible
for b / a to extend larger than an int so
it is long but b % a is always an int.

You've lost me here.

[Keith Thompson]

bartc <***@freeuk.com> writes:
[...]

Post by bartc
"long" in C is not guaranteed to give you a wider type than "int". "long
long" I think is.

[...]

No, long long can be the same width as int (if int is at least 64 bits).

It would be legal for char, short, int, long, and long long *all* to be
the same width, as long as that width is at least 64 bits.

[Rick C. Hodgin]

Post by David Kleinecke
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.

CAlive handles this by automatically up-sizing the operands in
expressions to their larger form, so as to guarantee that the
value computed will be the one the human expected to see, and
not the one a truncated computation might erroneously yield
due to it not containing enough bits for the correct answer.

This necessarily decreases performance, and it has the ability
through use of a cask to override the auto-upsizing, but it is
the form that should be used.

In addition, CAlive introduces explicitly sized variables as
a native type:

s8,u8 -- signed and unsigned 8-bit quantities
s16,u16 -- Signed and unsigned 16-bit quantities
s32,u32 -- Signed and unsigned 32-bit quantities
s64,u64 -- Signed and unsigned 64-bit quantities
f32,f64 -- 32-bit and 64-bit floating point

I also introduce arbitrary types:

bi,bfp -- Big integer, big floating point

And I also introduce variable sizes for storing in memory to a
particular bit size that are auto-upsized to the next largest
size in computation. These are also signed saturating in the
store:

as8,au8 -- Auto-upsizing 8-bit to 32-bit quantities
as16,au16 -- Auto-upsizing 16-bit to 32-bit quantities
as24,au24 -- Auto-upsizing 24-bit to 32-bit quantities

xs8,xu8 -- Auto-upsizing 8-bit to 64-bit quantities
xs16,xu16 -- Auto-upsizing 16-bit to 64-bit quantities
xs24,xu24 -- Auto-upsizing 24-bit to 64-bit quantities
xs32,xu32 -- Auto-upsizing 32-bit to 64-bit quantities
xs40,xu40 -- Auto-upsizing 40-bit to 64-bit quantities
xs48,xu48 -- Auto-upsizing 48-bit to 64-bit quantities
xs56,xu56 -- Auto-upsizing 56-bit to 64-bit quantities

Note: These are used primarily for data translation from
other systems, and aren't generally intended to be
used internally save the standard forms of 8,16,32.

In this way, you have control over whether or not the values
should be upsized, or whether they should remain, and with
the ability to inject <|overflow?|> and <|underflow?|> casks,
you can handle the exact condition you're looking for.

CAlive looks to be incredible. The more I throw stuff at it
to try and break it, the more I see it being solid. I cannot
wait until it's completed.

I could use help in its development. If you're willing to
look within yourself, and look up to God, and come to Him
asking forgiveness for your sin, and then looking to Him for
how to use the skills you possess in this world ... then this
project could use your skills. I look forward to hearing from
you.

Thank you,
Rick C. Hodgin

[Ben Bacarisse]

"Rick C. Hodgin" <***@gmail.com> writes:
<snip>

CAlive handles this ...

Please stop plugging your personal language.

<snip>

CAlive looks to be incredible.

Yup.

<snip>

[Rick C. Hodgin]

Post by Ben Bacarisse
<snip>

CAlive handles this ...

Please stop plugging your personal language.

As I've told you repeatedly, these ideas I have for enhancements
to C are encapsulated in CAlive. They are NOT exclusive to it.
They will work for C were it to be augmented.

I am providing the example of my time and thought and energy in work-
king on developing specific ideas. I am responding with the fruit
of that time spent in contemplative labor pursuing things that cor-
relate to the similar ideas other people are posting in this clc
group regarding aspects of software development related to C, which
includes enhancements, changes, and extensions needed in C to address
their perceived shortcomings.

The subject material I am bringing up is not off-topic, and I would
like to ask you to stop harassing me regarding CAlive. The ONLY
reason I'm working on CAlive is because I met nothing but resistance
from men like you when I came to these groups in 2014, and 2015, and
2016, asking, and in many cases begging, for C to be extended in some
of these ways.

You flatly refused me then, and now you are trying to curtail my
ongoing efforts to reach out with the knowledge and experience and
creativity I have, that I've poured into this language to make C
better, all culminating in a new product called CAlive ... the very
name of which is an injection of new life into C.

You are exerting efforts toward ruining the advancement of this
dying language, and I find it absolutely deplorable behavior, Ben,
both then in 2014-2016 and now.

Post by Ben Bacarisse
<snip>

CAlive looks to be incredible.

Yup.

If you can legitimately find something to break the design ideas
I propose, or find flaws in the details of the design at various
points as I post them, then I would absolutely welcome your
contribution because it will help everybody, including me. But if
not, then kindly sit down, be quiet, and cease your constant
refutation of my posts simply because they are not exclusive to C.

My posts are valid and poignant ideas that can be used to improve
C. They give other people things to think about, alternate ideas
to consider. Even in many cases a documented syntax that can be
examined, understood, and then improved upon or tweaked to help
their idea bear more fruit.

FWIW, I am flatly amazed that CAlive is shaping up the way it has.
It's like this thing that keeps building itself. I am literally in
the middle of doing other things, of coding regular coding, and idea
after idea pops into my head about some new features I could into C,
but since that's not possible with the inflexible C Standard body
attendants, I incorporate into CAlive where I do have free rein. I
go and write about it in that moment, and over time this whole new
creation is being produced largely outside of my influence, as I am
not the author of these ideas, but merely the conveyer.

I welcome everybody's attempts to refute my thinking in design, and
in my methods of improving the language ... even yours, Ben. But I
will not listen to your attempts to silence me simply because you
are willing only to look as far as your myopic vision of C extends.
The world is a far more diverse and interesting place, and C needs
to evolve or it's going to die a slow, painful death.

The sooner your realize that, and the sooner you start contributing
to that thing C must migrate into, the better off we'll all be.

Thank you,
Rick C. Hodgin

[Ian Collins]

Post by Rick C. Hodgin
You are exerting efforts toward ruining the advancement of this
dying language, and I find it absolutely deplorable behavior, Ben,
both then in 2014-2016 and now.

Which dying language would that be? I can see an elderly but healthy
one and a pipe dream....

[Rick C. Hodgin]

Post by Rick C. Hodgin
You are exerting efforts toward ruining the advancement of this
dying language, and I find it absolutely deplorable behavior, Ben,
both then in 2014-2016 and now.

Which dying language would that be?  I can see an elderly but healthy
one and a pipe dream....

I think you use Solaris, so you might not be able to see graphics in
your web browser LOL, but if you look at the graph in this page:

https://www.tiobe.com/tiobe-index/

...you'll see C and Java both descending rapidly from 2014 at around
18% or so, through until the present time, dropping down to about 8%
or so as many other new languages are coming up, those which offer
easier syntax than C, and less restrictions on data processing than
Java.

Perhaps it's a two+ year burb as C does appear to be turning up
a blip there in recent weeks.

There is too much computing power available to make C worth coding
for in most cases anymore. If it wants to survive, it needs to
get with the times and implement some compiler features that may
take longer to compile, but provide developer with time-saving
additions.

Thank you,
Rick C. Hodgin

[Ian Collins]

Post by Rick C. Hodgin

Post by Ian Collins

Post by Rick C. Hodgin
You are exerting efforts toward ruining the advancement of this
dying language, and I find it absolutely deplorable behavior, Ben,
both then in 2014-2016 and now.

Which dying language would that be? I can see an elderly but healthy
one and a pipe dream....

I think you use Solaris, so you might not be able to see graphics in
https://www.tiobe.com/tiobe-index/
....you'll see C and Java both descending rapidly from 2014 at around
18% or so, through until the present time, dropping down to about 8%
or so as many other new languages are coming up, those which offer
easier syntax than C, and less restrictions on data processing than
Java.

At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

Post by Rick C. Hodgin
There is too much computing power available to make C worth coding
for in most cases anymore. If it wants to survive, it needs to
get with the times and implement some compiler features that may
take longer to compile, but provide developer with time-saving
additions.

One quote of note on that page is "Applications that are written in a
single programming language are getting rarer nowadays." which is very
true. Each language has it's niche on a big project, so there's no need
for any one language to provide the kitchen sink. Contemporary software
projects are more akin to UNIX, with many small parts making up the
whole, than the monolithic Windows world view!

[Rick C. Hodgin]

Post by Ian Collins

Post by Rick C. Hodgin

Post by Rick C. Hodgin
You are exerting efforts toward ruining the advancement of this
dying language, and I find it absolutely deplorable behavior, Ben,
both then in 2014-2016 and now.

Which dying language would that be?  I can see an elderly but healthy
one and a pipe dream....

I think you use Solaris, so you might not be able to see graphics in
      https://www.tiobe.com/tiobe-index/
....you'll see C and Java both descending rapidly from 2014 at around
18% or so, through until the present time, dropping down to about 8%
or so as many other new languages are coming up, those which offer
easier syntax than C, and less restrictions on data processing than
Java.

At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

It's possible. They may have changed their algorithm or language
inclusion search criteria in recent years.

Post by Ian Collins

Post by Rick C. Hodgin
There is too much computing power available to make C worth coding
for in most cases anymore.  If it wants to survive, it needs to
get with the times and implement some compiler features that may
take longer to compile, but provide developer with time-saving
additions.

One quote of note on that page is "Applications that are written in a
single programming language are getting rarer nowadays." which is very
true.  Each language has it's niche on a big project, so there's no need
for any one language to provide the kitchen sink.

I think there are purposes for various types of software development.
One of the things I've tried to bring into CAlive is the ability to
do many types of low-level data processing.

Post by Ian Collins
Contemporary software
projects are more akin to UNIX, with many small parts making up the
whole, than the monolithic Windows world view!

I agree. It's one reason I made the decision to create RDC, and to
incorporate the basic _language_name { .. } block to include source
code from multiple different languages in a singe source file. At
their fundamental level the data gets processed similarly, but there
are different ways to get to those low-level portions.

With RDC and the planned many languages it will support, we will be
able to code several different ways in a single source file, with
each obeying its own language rules. That's the plan at least (James
4:15 "Lord willing").

Thank you,
Rick C. Hodgin

[James R. Kuyper]

...

Post by Ian Collins

Post by Rick C. Hodgin
https://www.tiobe.com/tiobe-index/

...

Post by Ian Collins
At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for
the validity of their algorithms - those are highly debatable issues.
But you seem to be objecting based upon some internal inconsistency in
those numbers, and I don't see that they provide enough information to
perform such a consistency check.
For instance, they show the ratings for Sep 2017, and the change since
Sep 2016, but they don't say what the ratings in Sep 2016 were, so you
can't validate the change. Since it only shows the ratings for the top
50 languages, their total shouldn't add up to 100%, and it doesn't.
Since it only shows the changes for the top 20 languages, the total
change doesn't have to add up to 0%, and it doesn't, either.
Are you comparing these numbers with some alternative source of
information? If so, which one?

[Ian Collins]

Post by James R. Kuyper
....

Post by Ian Collins

Post by Rick C. Hodgin
https://www.tiobe.com/tiobe-index/

....

Post by Ian Collins
At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for
the validity of their algorithms - those are highly debatable issues.
But you seem to be objecting based upon some internal inconsistency in
those numbers, and I don't see that they provide enough information to
perform such a consistency check.
For instance, they show the ratings for Sep 2017, and the change since
Sep 2016, but they don't say what the ratings in Sep 2016 were, so you
can't validate the change. Since it only shows the ratings for the top
50 languages, their total shouldn't add up to 100%, and it doesn't.
Since it only shows the changes for the top 20 languages, the total
change doesn't have to add up to 0%, and it doesn't, either.
Are you comparing these numbers with some alternative source of
information? If so, which one?

I'm saying I find it highly unlikely that the top 5 languages can loose
over 12% between them without some other language in the top 20 making a
significant gain. None do.

[Rick C. Hodgin]

Post by Ian Collins

Post by James R. Kuyper
....

Post by Ian Collins

Post by Rick C. Hodgin
https://www.tiobe.com/tiobe-index/

....

Post by Ian Collins
At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for
the validity of their algorithms - those are highly debatable issues.
But you seem to be objecting based upon some internal inconsistency in
those numbers, and I don't see that they provide enough information to
perform such a consistency check.
For instance, they show the ratings for Sep 2017, and the change since
Sep 2016, but they don't say what the ratings in Sep 2016 were, so you
can't validate the change. Since it only shows the ratings for the top
50 languages, their total shouldn't add up to 100%, and it doesn't.
Since it only shows the changes for the top 20 languages, the total
change doesn't have to add up to 0%, and it doesn't, either.
Are you comparing these numbers with some alternative source of
information? If so, which one?

I'm saying I find it highly unlikely that the top 5 languages can loose
over 12% between them without some other language in the top 20 making a
significant gain. None do.

The RedMonk Programming Language Rankings for June 2017 show C at #9
based on references in GitHub and Stack Overflow:

http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/

For IEEE Spectrum readers, C's at #2 behind Python:

https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages

Raw data taken from Google Trends shows C at #7 at 6.1% down 1.1%:

http://pypl.github.io/PYPL.html

GitHut shows the ranking based solely on GitHub software, showing
C 13K repositories behind C++ at 73K active repositories:

http://githut.info

Thank you,
Rick C. Hodgin

[Ian Collins]

Post by Rick C. Hodgin

Post by Ian Collins

Post by James R. Kuyper
....

Post by Ian Collins

Post by Rick C. Hodgin
https://www.tiobe.com/tiobe-index/

....

Post by Ian Collins
At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for
the validity of their algorithms - those are highly debatable issues.
But you seem to be objecting based upon some internal inconsistency in
those numbers, and I don't see that they provide enough information to
perform such a consistency check.
For instance, they show the ratings for Sep 2017, and the change since
Sep 2016, but they don't say what the ratings in Sep 2016 were, so you
can't validate the change. Since it only shows the ratings for the top
50 languages, their total shouldn't add up to 100%, and it doesn't.
Since it only shows the changes for the top 20 languages, the total
change doesn't have to add up to 0%, and it doesn't, either.
Are you comparing these numbers with some alternative source of
information? If so, which one?

I'm saying I find it highly unlikely that the top 5 languages can loose
over 12% between them without some other language in the top 20 making a
significant gain. None do.

The RedMonk Programming Language Rankings for June 2017 show C at #9
http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/
https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages
http://pypl.github.io/PYPL.html
GitHut shows the ranking based solely on GitHub software, showing
http://githut.info

All of the above exclude commercially developed software, which is where
the bulk of C (and C++) development takes place.

[Rick C. Hodgin]

Post by Ian Collins

Post by Rick C. Hodgin
http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/
https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages
http://pypl.github.io/PYPL.html
http://githut.info

All of the above exclude commercially developed software, which is where
the bulk of C (and C++) development takes place.

I'd estimate IEEE Spectrum readers include professionals working on
commercial software.

Additionally, some commercially developed software is open source
and/or free software, and it would show up on GitHub. That includes
the Linux kernel.

It's possible the GitHub metrics include private repositories given
anonymously for this type of reporting. If not, then at least it's
reflective of the things people are doing, not corporations. It
indicates the chosen mindset of individuals and small groups, and
not for-profit endeavors.

Thank you,
Rick C. Hodgin

[Kenny McCormack]

In article <71cfb4e2-bc50-4096-b2d4-***@googlegroups.com>,
Rick C. Hodgin <***@gmail.com> wrote:
...

Post by Rick C. Hodgin
GitHut shows the ranking based solely on GitHub software, showing
http://githut.info

Rick, you should stop reverently quoting these sort of stats as if they had
any meaning or relevance. I say this because, assuming any of your
projects ever see the light of day in any form whatsoever, the # of users
column for, e.g., "CAlive" is going to be, hmmm, now what's that number I
am looking for, oh, yeah, here it is: One.

Not that there is anything per se wrong with that. It could well be the
greatest thing since sliced cheese, but the fact is there isn't any reason
for anyone else to take it up. So, bottom line, you don't want to be seen
as someone who places too much weight on "popularity as the sole
determinant of quality".

Just sayin...

[Rick C. Hodgin]

Post by Kenny McCormack
...

Post by Rick C. Hodgin
GitHut shows the ranking based solely on GitHub software, showing
http://githut.info

Rick, you should stop reverently quoting these sort of stats as if they had
any meaning or relevance. I say this because, assuming any of your
projects ever see the light of day in any form whatsoever, the # of users
column for, e.g., "CAlive" is going to be, hmmm, now what's that number I
am looking for, oh, yeah, here it is: One.
Not that there is anything per se wrong with that. It could well be the
greatest thing since sliced cheese, but the fact is there isn't any reason
for anyone else to take it up. So, bottom line, you don't want to be seen
as someone who places too much weight on "popularity as the sole
determinant of quality".
Just sayin...

Well anyone who knows me knows I'm all about popularity. I don't
make a move unless I'll slide up the social ladder.

Thank you,
Rick C. Hodgin

PS -- K-k-k-kenny (to the tune of "Ch-ch-ch-chia." :-)

[bartc]

Post by Rick C. Hodgin
The RedMonk Programming Language Rankings for June 2017 show C at #9
http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/
https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages
http://pypl.github.io/PYPL.html
GitHut shows the ranking based solely on GitHub software, showing
http://githut.info

I'm not sure what any of these really mean.

The number of searches for tutorials may indicate a language that is
hard to learn, or that is new. An established language will have lots of
existing users who will not be looking up tutorials.

With github, how does it figure out what language a depository uses? The
ones I've seen are usually mixed.

(And with github, when I used that, I chose to put C code on there so
that people could compile my programs, although the true source wasn't
C. But that would be untypical.)

With the popularity of Java, I understand that that is closely
associated with Android, so some people are least might be being pushed
into using certain languages.

I notice also that makefiles are on the list so that counts as a
language! (I suspected that all along. It means most open source C
projects aren't pure C but depend on makefiles as well as configure
scripts (Shell is also on that githut dot info list).)

I don't think many would be disagree that C-like languages are not the
best for writing all those complicated GUIs you see everywhere, so
that's another reason why those softer languages are getting more
popular. If you had to do some /real/ coding however...

[Rick C. Hodgin]

Post by bartc

Post by Rick C. Hodgin
The RedMonk Programming Language Rankings for June 2017 show C at #9
     http://redmonk.com/sogrady/2017/06/08/language-rankings-6-17/
https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages
     http://pypl.github.io/PYPL.html
GitHut shows the ranking based solely on GitHub software, showing
     http://githut.info

I'm not sure what any of these really mean.

Me either. :-)

Post by bartc
The number of searches for tutorials may indicate a language that is
hard to learn, or that is new. An established language will have lots of
existing users who will not be looking up tutorials.

I also think C is so difficult that it will have an exaggerated
number of searches, because one user programming in C might easily
generate 10x the number of searches than if they were coding in
another language. :-)

Post by bartc
With github, how does it figure out what language a depository uses? The
ones I've seen are usually mixed.

I would say the number of new repositories is more telling, as it
would indicate what people are doing today, rather than what they
are forced into doing today from decisions made in yesteryear.

Post by bartc
(And with github, when I used that, I chose to put C code on there so
that people could compile my programs, although the true source wasn't
C. But that would be untypical.)

I think you are impacting the final numbers in a misleading way,
Bart. Shame on you for that deception. :-)

Post by bartc
With the popularity of Java, I understand that that is closely
associated with Android, so some people are least might be being pushed
into using certain languages.

I agree. I was pushed into Java. Resisted it for years, but
now there are some things I like about it. I incorporated it
into my "C Coder In Paradise" variant:

https://groups.google.com/d/msg/comp.lang.c/_oR7CPYpugM/8sKqjdOxBwAJ

Tried to amend my low-level code habits
Started learning Java last Fall.
Losing code running speed just to meet a dev need
Thinking in try..catch's now for when it goes wrong

But at night I'd have these wonderful dreams
Coding back at Low Level Street
Not in Integers or imports or Strings with ease
but in the trenches with void pointers and binary trees!

I also plan a JAlive language, which is a variant of Java that
introduces some low-level features Java is missing.

Post by bartc
I notice also that makefiles are on the list so that counts as a
language! (I suspected that all along. It means most open source C
projects aren't pure C but depend on makefiles as well as configure
scripts (Shell is also on that githut dot info list).)
I don't think many would be disagree that C-like languages are not the
best for writing all those complicated GUIs you see everywhere, so
that's another reason why those softer languages are getting more
popular. If you had to do some /real/ coding however...

I think C is a wonderful language. It needs some minor tweaking
to make it more usable for developers, to shift some of the burden
of syntax and declaration from the human being into the machine,
but on the whole it's wonderful, which is why I still code in it
even moving forward with CAlive.

Thank you,
Rick C. Hodgin

[James Kuyper]

Post by Ian Collins

Post by James R. Kuyper
....

Post by Ian Collins

Post by Rick C. Hodgin
https://www.tiobe.com/tiobe-index/

....

Post by Ian Collins
At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

I wouldn't argue for the absolute accuracy of Tiobe's numbers, nor for
the validity of their algorithms - those are highly debatable issues.
But you seem to be objecting based upon some internal inconsistency in
those numbers, and I don't see that they provide enough information to
perform such a consistency check.
For instance, they show the ratings for Sep 2017, and the change since
Sep 2016, but they don't say what the ratings in Sep 2016 were, so you
can't validate the change. Since it only shows the ratings for the top
50 languages, their total shouldn't add up to 100%, and it doesn't.
Since it only shows the changes for the top 20 languages, the total
change doesn't have to add up to 0%, and it doesn't, either.
Are you comparing these numbers with some alternative source of
information? If so, which one?

I'm saying I find it highly unlikely that the top 5 languages can loose
over 12% between them without some other language in the top 20 making a
significant gain. None do.

I don't find that as unlikely as you do. It seems plausible to me that
there might be a broad diversification of languages going on - with
people switching over from doing almost all of their work in a small
number of very popular languages to doing most of it in a much larger
number of substantially less popular languages.
I've no idea why such a change would be occurring, but I could certainly
imagine something like that occurring. I think it's premature to assume
that Tiobe's ratings are incorrect just because they show such a
pattern. If you've got any more specific, data-driven reason for
thinking they might be incorrect, that would be a different matter.

[Ian Collins]

Post by James Kuyper

Post by Ian Collins
I'm saying I find it highly unlikely that the top 5 languages can loose
over 12% between them without some other language in the top 20 making a
significant gain. None do.

I don't find that as unlikely as you do. It seems plausible to me that
there might be a broad diversification of languages going on - with
people switching over from doing almost all of their work in a small
number of very popular languages to doing most of it in a much larger
number of substantially less popular languages.
I've no idea why such a change would be occurring, but I could certainly
imagine something like that occurring. I think it's premature to assume
that Tiobe's ratings are incorrect just because they show such a
pattern. If you've got any more specific, data-driven reason for
thinking they might be incorrect, that would be a different matter.

While not data-driven as such, I do know my local market well and here
most work in product development is still C and C++ for "embedded"
devices, Java (Android) and JavaScript for UI. Desktop type application
are predominantly C#. Java is still strong in back end systems and
Python dominates test automation. There is very little work that I know
of in other languages (except Jade, which is developed here).

So the TIOBE top 5 are the top 5 and the situation hasn't changed for
several years.

[Jerry Stuckle]

Post by Ian Collins

Post by Rick C. Hodgin

Post by Rick C. Hodgin
You are exerting efforts toward ruining the advancement of this
dying language, and I find it absolutely deplorable behavior, Ben,
both then in 2014-2016 and now.

Which dying language would that be?  I can see an elderly but healthy
one and a pipe dream....

I think you use Solaris, so you might not be able to see graphics in
      https://www.tiobe.com/tiobe-index/
....you'll see C and Java both descending rapidly from 2014 at around
18% or so, through until the present time, dropping down to about 8%
or so as many other new languages are coming up, those which offer
easier syntax than C, and less restrictions on data processing than
Java.

At first glance, the maths in those tables doesn't add up with a 15% net
drop in the top 20 languages..

Post by Rick C. Hodgin
There is too much computing power available to make C worth coding
for in most cases anymore.  If it wants to survive, it needs to
get with the times and implement some compiler features that may
take longer to compile, but provide developer with time-saving
additions.

One quote of note on that page is "Applications that are written in a
single programming language are getting rarer nowadays." which is very
true.  Each language has it's niche on a big project, so there's no need
for any one language to provide the kitchen sink.  Contemporary software
projects are more akin to UNIX, with many small parts making up the
whole, than the monolithic Windows world view!

tiobe is known for not being very accurate. Not that they purposely
fudge the numbers - they don't. But their sources aren't representative
of the market. They cater to short term assignments and jobs with high
turnover rates, at the expense of stable, long-term jobs with low turnover.

[j***@itu.edu]

Post by Rick C. Hodgin
There is too much computing power available to make C worth coding
for in most cases anymore.

Embedded computers will take you back! I work with a system-on-a-chip which includes a 32MHz ARM Cortex-M4 CPU, 64K of SRAM, and 512K of flash.

If we don't write code for such a tiny computer in C (or assembly), the language that we use instead will still have to be similarly "close to the metal" and efficient with resources.

[Rick C. Hodgin]

Post by j***@itu.edu

Post by Rick C. Hodgin
There is too much computing power available to make C worth coding
for in most cases anymore.

Embedded computers will take you back! I work with a system-on-a-chip which includes a 32MHz ARM Cortex-M4 CPU, 64K of SRAM, and 512K of flash.
If we don't write code for such a tiny computer in C (or assembly), the language that we use instead will still have to be similarly "close to the metal" and efficient with resources.

In those processors, there are C compilers which already exist? Is
the ISA changing over time? Is it not possible to incorporate the
new changes to the existing code base?

There's no reason why the extensions added to C couldn't be added
for a particular release, and then they could be included or not
included by real-world implementations.

I have done some programming for embedded systems. Most of the
algorithms I've developed have been written and debugged in Visual
Studio or some other implementation. I've found the ability to
debug data-processing algorithms this way the fastest way I've
found.

Thank you,
Rick C. Hodgin

[Ben Bacarisse]

Post by Rick C. Hodgin

Post by Ben Bacarisse
<snip>

CAlive handles this ...

Please stop plugging your personal language.

As I've told you repeatedly, these ideas I have for enhancements
to C are encapsulated in CAlive. They are NOT exclusive to it.
They will work for C were it to be augmented.

So will my Fortran extensions to C... and my SQL extesions... Let's
talk about those! No, let's not.

In fact I don't mind talking about individual features (though I prefer
them to be properly defined), it's the plugging of your personal
language that I object to.

Post by Rick C. Hodgin
... But I
will not listen to your attempts to silence me simply because you
are willing only to look as far as your myopic vision of C extends.

You are not talking about C. But I accept that you won't comply with
this group's topicality standard. I did not really expect anything
else.

<snip>

[bartc]

Post by Rick C. Hodgin

Post by David Kleinecke
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.

CAlive handles this by automatically up-sizing the operands in
expressions to their larger form,

Which form is that? If adding 8-bit and 16-bit, what is the possible
result type? (Note those could require 32 bits to represent a result.
But this is already how C works when int is 32 bits.)

Post by Rick C. Hodgin
In addition, CAlive introduces explicitly sized variables as
s8,u8 -- signed and unsigned 8-bit quantities
s16,u16 -- Signed and unsigned 16-bit quantities
s32,u32 -- Signed and unsigned 32-bit quantities
s64,u64 -- Signed and unsigned 64-bit quantities
f32,f64 -- 32-bit and 64-bit floating point

OK, but you should stop there (unless you want s128 and u128).

Post by Rick C. Hodgin
bi,bfp -- Big integer, big floating point

These may not be a good fit to such a language, assuming they are
auto-sizing and automatically get bigger and smaller. They are more
suited to a 'softer' language. But if you intend this to be the only
language, and you need big integers, then you may have to shoehorn them in.

(IME big integers are infrequently used anyway.)

Post by Rick C. Hodgin
And I also introduce variable sizes for storing in memory to a
particular bit size that are auto-upsized to the next largest
size in computation. These are also signed saturating in the
as8,au8 -- Auto-upsizing 8-bit to 32-bit quantities
as16,au16 -- Auto-upsizing 16-bit to 32-bit quantities
as24,au24 -- Auto-upsizing 24-bit to 32-bit quantities
xs8,xu8 -- Auto-upsizing 8-bit to 64-bit quantities
xs16,xu16 -- Auto-upsizing 16-bit to 64-bit quantities
xs24,xu24 -- Auto-upsizing 24-bit to 64-bit quantities
xs32,xu32 -- Auto-upsizing 32-bit to 64-bit quantities
xs40,xu40 -- Auto-upsizing 40-bit to 64-bit quantities
xs48,xu48 -- Auto-upsizing 48-bit to 64-bit quantities
xs56,xu56 -- Auto-upsizing 56-bit to 64-bit quantities

And this is definitely off the wall. I've no idea what these are meant
to be used for.

The 8 and 16 primitives introduced above should already be storage
types, chosen to either reduce memory usage, or to match some foreign
struct layout. They will already be expanded to int size (usually 32
bits) when used in expressions.

If you want a storage type of non-standard size, ie. 24, 40, 48 and 56
bits, then fine. But it will be a variation of the one of the primitive
types.

Post by Rick C. Hodgin
Note: These are used primarily for data translation from
other systems,

Which other systems? All now use 8,16,32,64.

Post by Rick C. Hodgin
CAlive looks to be incredible. The more I throw stuff at it
to try and break it, the more I see it being solid. I cannot
wait until it's completed.
I could use help in its development.

But no help with its design I guess?

[s***@casperkitty.com]

Post by bartc

Post by Rick C. Hodgin
CAlive handles this by automatically up-sizing the operands in
expressions to their larger form,

Which form is that? If adding 8-bit and 16-bit, what is the possible
result type? (Note those could require 32 bits to represent a result.
But this is already how C works when int is 32 bits.)

Having numeric expressions behave as though they promote to the largest
available numeric type shouldn't be particularly difficult or expensive
in most cases. On a silent-wraparound implementation, something like
`int x=(long long)y+z;` would yield the same code as `int x=y+z;`, so
"promoting" to the longer type would cost nothing. Such promotion would
add to the cost of "int x=a*b/c;", but it's unlikely that a programmer
would particularly want any behavior other than that yielded by
"int x=(long long)a*b/c;". A programmer may want the faster performance
that might be achieved using int-sized operations, but if the language
includes syntax to truncate to "int" always, or to truncate to "int" when
convenient, having the default behavior promote to the longer type may
be the safest course of action.

In addition to "number" types, C-like languages should also include types
for modular arithmetic. While C applies modular-arithmetic semantics to
full-sized unsigned types, and numeric semantics to other types, it would
be helpful to have types which were specified as using modular arithmetic
regardless of the target platform, and others which were specified as
using numeric arithmetic, again regardless of the target platform.

[Rick C. Hodgin]

Post by bartc

Post by Rick C. Hodgin

Post by David Kleinecke
But these ideal ints fail when we multiple. The
product of two ints is - conceptually - twice the
size of an int. Hence we need "long". But C, as
it stands, does not implement that situation.

CAlive handles this by automatically up-sizing the operands in
expressions to their larger form,

Which form is that? If adding 8-bit and 16-bit, what is the possible
result type? (Note those could require 32 bits to represent a result.
But this is already how C works when int is 32 bits.)

There are factors which weigh in to this calculation, but as a
general rule whatever bit size you're at it goes up to the next
highest, so 16-bit goes to 32-bit. However, definition casks in
CAlive allow a person to specify that a particular value will
never exceed a range. When those casks are provided, CAlive
will analyze the range of possible results and upsize accordingly.

Post by bartc

Post by Rick C. Hodgin
In addition, CAlive introduces explicitly sized variables as
     s8,u8      -- signed and unsigned 8-bit quantities
     s16,u16    -- Signed and unsigned 16-bit quantities
     s32,u32    -- Signed and unsigned 32-bit quantities
     s64,u64    -- Signed and unsigned 64-bit quantities
     f32,f64    -- 32-bit and 64-bit floating point

OK, but you should stop there (unless you want s128 and u128).

I do not support s128 and u128 apart from bi.

Post by bartc

Post by Rick C. Hodgin
     bi,bfp     -- Big integer, big floating point

These may not be a good fit to such a language, assuming they are
auto-sizing and automatically get bigger and smaller. They are more
suited to a 'softer' language. But if you intend this to be the only
language, and you need big integers, then you may have to shoehorn them in.
(IME big integers are infrequently used anyway.)

The bfp type allow for f128 and f256 natively, using the double-
double and quad-double libraries I've posted on this forum before:

See the "QD" section:
http://crd-legacy.lbl.gov/~dhbailey/mpdist/

For anything larger than that another algorithm is used, which
is very slow, but compared to not having the ability it's okay.

It does not automatically upsize, but computes to the specified
bfp size.

Post by bartc

Post by Rick C. Hodgin
And I also introduce variable sizes for storing in memory to a
particular bit size that are auto-upsized to the next largest
size in computation.  These are also signed saturating in the
     as8,au8    -- Auto-upsizing 8-bit to 32-bit quantities
     as16,au16  -- Auto-upsizing 16-bit to 32-bit quantities
     as24,au24  -- Auto-upsizing 24-bit to 32-bit quantities
     xs8,xu8    -- Auto-upsizing 8-bit to 64-bit quantities
     xs16,xu16  -- Auto-upsizing 16-bit to 64-bit quantities
     xs24,xu24  -- Auto-upsizing 24-bit to 64-bit quantities
     xs32,xu32  -- Auto-upsizing 32-bit to 64-bit quantities
     xs40,xu40  -- Auto-upsizing 40-bit to 64-bit quantities
     xs48,xu48  -- Auto-upsizing 48-bit to 64-bit quantities
     xs56,xu56  -- Auto-upsizing 56-bit to 64-bit quantities

And this is definitely off the wall. I've no idea what these are meant
to be used for.
The 8 and 16 primitives introduced above should already be storage
types, chosen to either reduce memory usage, or to match some foreign
struct layout. They will already be expanded to int size (usually 32
bits) when used in expressions.
If you want a storage type of non-standard size, ie. 24, 40, 48 and 56
bits, then fine. But it will be a variation of the one of the primitive
types.

The idea is storage for signed saturation. Those have traditional
value in various operations.

For the rest, they don't generally exist today so people don't use
them, but why store everything in 16-bit or 32-bit or 64-bit chunks?
Suppose I'm writing data to disk, or memory. Why waste memory that
is always going to only be filled with 0s in the most significant
bits? If I only need 40-bits, why not store 40-bits?

It wasn't a great extension to add this ability, so I added it.

Post by bartc

Post by Rick C. Hodgin
     Note:  These are used primarily for data translation from
            other systems,

Which other systems? All now use 8,16,32,64.

Have you ever used bit-packed structs? This ability is really
just an extension of that logic, with some extra load and store
logic.

Post by bartc

Post by Rick C. Hodgin
CAlive looks to be incredible.  The more I throw stuff at it
to try and break it, the more I see it being solid.  I cannot
wait until it's completed.
I could use help in its development.

But no help with its design I guess?

Absolutely with design. But, as Captain Queeg said in the Cain
Mutiny, you'd better have half a dozen good reasons, and you'll
still get an argument from me. :-)

Thank you,
Rick C. Hodgin

[s***@casperkitty.com]

Post by David Kleinecke
What we seem to need is operators, call them
a := b
means a is an int, b is a long int and the
execution is to assign the value in the
upper half of b to a. Conversely
b =: a
assigns the value in a to the upper half of b.

What I'd like to see would be a more general way of specifying that an
object must behave as though it is stored in a specified format, with
a compiler either generating the code to accomplish that or refusing to
do so (as opposed from generating code that behaves in some other fashion).
What sorts of format a compiler supports would be a quality-of-implementation
issue.

If code specifies a 32-bit value must be stored as two "unsigned short"
values in big-endian order, and retrievable from any 16-bit-aligned address,
a platform where "char" is 8 bits would store the value as 4 bytes, while
one where "char" is 64 bits would store it as two 64-bit words. In either
case, the effect of overlaying such an object on an "unsigned short[]" would
be well-defined, at least if the array contained no values outside the range
0-65535.