On 30/08/2021 22:09, James Harris wrote:
> On 30/08/2021 12:45, Bart wrote:
>> On 30/08/2021 11:44, James Harris wrote:
>>> On 26/08/2021 11:43, Bart wrote:
>>>
>>> ...
>>>
>>>> C shouldn't come into it at all. A 'C type system' isn't really a
>>>> type system, but just a thin layer over the underlying hardware.
>
> ...
>
>>> You shouldn't have a go at C's type system until you have tried to
>>> adapt yours for different word sizes. Your choice of making
>>> everything 64-bit give you enormous luxuries that were not available
>>> in decades past!
>>>
>>
>>
>> 64-bit is simply using the native word size of the processor.
>
> I'm sure I've seen you espousing it for other things, too. ;-)
>

If you want to limit types to one single size of integer (except perhaps
for FFI or large arrays), then 64-bit is a good choice unless you need
to be as efficient as possible on small embedded systems. All modern
PC's or bigger embedded systems (phones, etc.) handle 64-bit natively,
so smaller sizes are not faster for general use. Outside of mathematics
and applications like cryptography, it is rare for an integer to be
bigger than 2 ^ 31. But it is extremely rare to need values bigger than
2 ^ 63. So for practical purposes, you can usually treat a 64-bit
integer as "unlimited".

On 31/08/2021 00:25, Bart wrote:
> On 30/08/2021 21:09, James Harris wrote:
>> On 30/08/2021 12:45, Bart wrote:
>
>>> You can argue that C was created when there were more diverse
>>> word-sizes and fewer byte-addressed machines, but it should have been
>>> obvious a few years after its creation, which way things were going.
>>> It had plenty of opportunity to get things in order.
>>
>> My point was that even today C can be used to write programs for
>> machines with word sizes you would hate whereas you've been able to
>> avoid the complexity of all those issues by simply avoiding supporting
>> such machines. So don't be too hard on C's type system. Most of it is
>> there for a reason.

Indeed - there are plenty of 8-bit and 16-bit systems in common use.
There are also huge numbers of devices with weirder sizes, such as 18
bit or 24 bit, and often CHAR_BIT is bigger than 8. There are very few
people who /program/ these, but they are found in many appliances and
dedicated chips. (Often the electronics designers using them don't know
they are programmable cores - they buy a chip for driving a screen, or
for re-sampling audio streams, without realising there is a DSP core
inside.)

There is a good argument for saying some support for the most unusual
systems should be dropped from newer C standards. After all, the tools
used on these devices are very specialised and the software on them is
niche - there is no need for portability here. C2x is expected to drop
support for padding bits in integers (except _Bool) and require two's
complement signed integer format (but of course it will not require
wrapping overflow, because that would be silly).

A fair bit of the way C's types work is the result of history - gradual
changes and backwards compatibility. That is a good reason, but it does
mean that the final results are not objectively the "best" choice if you
were to start from scratch, targeting modern systems. (However, while
most C programmers agree that the types, promotion rules, etc., are not
ideal, they will not agree on what they would have liked to be different!)

>
> OK. It all depends on how much you want to emulate C in that regard, and
> so inherit a lot of the same mess in its type system.
>
> I suggested a few years ago that C should be split into two languages,
> one that continues to target all odd-ball systems past, present and
> future, and one that targets the same desktop-class machines that most
> other languages seem to have settled on, including mine.
>
> Namely, ones like D, Java, Julia, Dart, Rust, Odin, C#, Nim, Go ...
>
> But it seems that you are keen to cover everything in one language, from
> the tiniest microcontrollers, through desktop PCs and current
> supercomputers, and up to massively large machines that need 128 bits to
> specify file sizes.
>
> I'd say that's being a little ambitious. (Are you still writing OSes too?)
>

I'd agree - I see no use or benefit of a language covering that range.
And by the time it is ready for use, the targets will have changed.

On 30/08/2021 22:50, James Harris wrote:
> On 30/08/2021 09:03, David Brown wrote:
>> On 29/08/2021 21:32, Dmitry A. Kazakov wrote:
>
> ...
>
>>> Scalar is a type property, opposite to composite type.
>>>
>>
>> I think James is confusing the way parameters are passed, with the
>> property of the type.  In particular, he seems to using "scalar" to mean
>> "passed by value as a single object", and "composite" to mean "passed by
>> reference, using a pointer to the start of the object".  This is, of
>> course, not correct terminology.
>
> No, not at all. First of all, it may have been Dmitry who brought in the
> term "composite". Second, the situation doesn't change according to
> whether an object is passed by value or by reference.
>

It is quite possible that Ada uses the term "composite" in the way
Dmitry used it - but C does not. It's worth being aware of the ambiguity.

>>
>>
>> In a simple low-level non-OO language, a scaler type is a fundamental
>> type of the language that is not built up of other parts.  For C, it is
>> defined as an arithmetic type or a pointer type.  C++ adds enumeration
>> types, pointer to member types, and nullptr_t.
>
> Are you saying the C standards have an official definition of 'scalar'
> (which is along the lines you mention)?
>

Yes. 6.2.5p21 in C17. There are official drafts of the C standards
available freely (the actual published ISO standards cost money, but the
final drafts are free and just as good). Google for C17 draft, document
N2176, for example.

>>
>> Aliases and sub-types or sub-ranges of scalar types will also be scalar.
>>
>> Aggregate types are any type that is not a scalar type.  (These may also
>> be referred to as "composite types" in some languages, but in C that
>> term refers to a type that can be used to refer to two compatible types.)
>>
>>
>> Once you get to higher level languages, it gets more complicated.  In
>> Python, is an arbitrary precision integer a scalar or a composite?  You
>> can't break it down within the language, yet the implementation involves
>> tree data structures, memory management, etc.
>>
>> Even within something like C++ (and presumably Ada, but you know that
>> better than I) you can create a type such as "Int256" that behaves
>> identically to other integer types that are clearly scalar, while it is
>> in fact defined as an aggregate.  It is an aggregate, but is used like a
>> scalar.
>>
>> So perhaps the scalar/aggregate distinction is not particularly useful.
>
> I see scalars as objects which can be passed to a routine, returned from
> a routine and operated on as whole units. At that level they are
> scalars. If they can be subdivided by a routine which chooses to do so
> then they won't be scalars /in such code/.
>

That is not an unreasonable definition - but it differs from that used
by C (and I don't know if Ada has a definition).

> At the end of the day, if we are talking about digital computing all
> objects other than a single bit could be treated as aggregates.
>
> So scalar is arguably a semantic concept, reflecting how an object is
> processed.
>
>

On 2021-08-31 09:16, David Brown wrote:

> If you want to limit types to one single size of integer (except perhaps
> for FFI or large arrays), then 64-bit is a good choice unless you need
> to be as efficient as possible on small embedded systems. All modern
> PC's or bigger embedded systems (phones, etc.) handle 64-bit natively,
> so smaller sizes are not faster for general use. Outside of mathematics
> and applications like cryptography, it is rare for an integer to be
> bigger than 2 ^ 31. But it is extremely rare to need values bigger than
> 2 ^ 63. So for practical purposes, you can usually treat a 64-bit
> integer as "unlimited".

128-bit is appears in networking protocols, right, because of
cryptography. There are other formats for which 128-bit is required,
e.g. IEEE decimal numbers have mantissa longer than 64-bit.

I think that the language should allow any range. If the target does not
support the particular range, the compiler should deploy a library
implementation, giving a warning.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 31/08/2021 11:21, Dmitry A. Kazakov wrote:
> On 2021-08-31 09:16, David Brown wrote:
>
>> If you want to limit types to one single size of integer (except perhaps
>> for FFI or large arrays), then 64-bit is a good choice unless you need
>> to be as efficient as possible on small embedded systems.  All modern
>> PC's or bigger embedded systems (phones, etc.) handle 64-bit natively,
>> so smaller sizes are not faster for general use.  Outside of mathematics
>> and applications like cryptography, it is rare for an integer to be
>> bigger than 2 ^ 31.  But it is extremely rare to need values bigger than
>> 2 ^ 63.  So for practical purposes, you can usually treat a 64-bit
>> integer as "unlimited".
>
> 128-bit is appears in networking protocols, right, because of
> cryptography.

No, not really.

As I said, there are bigger integers used in cryptography. But these
are often /much/ bigger - at least 256 bits, and perhaps up to 4096
bits. You don't use a normal plain integer type there.

There are also lots of other uses for bigger types - IPv6 addresses are
128 bits, for example, but again these are not integers.

> There are other formats for which 128-bit is required,
> e.g. IEEE decimal numbers have mantissa longer than 64-bit.

Again, these are not integers.

The point is that when you want a /number/ - an integer - then 64-bit is
more than sufficient for most purposes while also not being too big to
handle efficiently on most modern cpus. You could almost say that about
32-bit, but definitely say it now we have 64-bit. This is why no one
has bothered making a 128-bit processor - there simply isn't any use for
such large numbers as plain integers.

>
> I think that the language should allow any range. If the target does not
> support the particular range, the compiler should deploy a library
> implementation, giving a warning.
>

Don't misunderstand me here - there are use-cases for all kinds of sizes
and types. A language that intends to be efficient is going to have to
be able to handle arrays of smaller types. And there has to be ways to
handle bigger types for their occasional usage. The point is that there
is little need for multiple sizes for "normal" everyday usage - a signed
64-bit type really will work for practically everything.

(I am a big fan of strong types, and sub-range types that have limited
valid ranges - these make it easier to write clear, correct code, much
harder to write incorrect code, and provide scope for static and dynamic
error checking. But whether or not a language should support and
encourage that is a different matter from the sizes you want for common
use.)

On 2021-08-31 12:57, David Brown wrote:
> On 31/08/2021 11:21, Dmitry A. Kazakov wrote:
>> On 2021-08-31 09:16, David Brown wrote:
>>
>>> If you want to limit types to one single size of integer (except perhaps
>>> for FFI or large arrays), then 64-bit is a good choice unless you need
>>> to be as efficient as possible on small embedded systems.  All modern
>>> PC's or bigger embedded systems (phones, etc.) handle 64-bit natively,
>>> so smaller sizes are not faster for general use.  Outside of mathematics
>>> and applications like cryptography, it is rare for an integer to be
>>> bigger than 2 ^ 31.  But it is extremely rare to need values bigger than
>>> 2 ^ 63.  So for practical purposes, you can usually treat a 64-bit
>>> integer as "unlimited".
>>
>> 128-bit is appears in networking protocols, right, because of
>> cryptography.
>
> No, not really.
>
> As I said, there are bigger integers used in cryptography. But these
> are often /much/ bigger - at least 256 bits, and perhaps up to 4096
> bits. You don't use a normal plain integer type there.

You mean computations. In protocols 128-bit is used for keys,
certificate, hashes stuff.

>> There are other formats for which 128-bit is required,
>> e.g. IEEE decimal numbers have mantissa longer than 64-bit.
>
> Again, these are not integers.

It is two integers combined into a floating-point number. 128-bit
integer is needed to encode/decode it into something digestible.

>> I think that the language should allow any range. If the target does not
>> support the particular range, the compiler should deploy a library
>> implementation, giving a warning.
>
> Don't misunderstand me here - there are use-cases for all kinds of sizes
> and types. A language that intends to be efficient is going to have to
> be able to handle arrays of smaller types. And there has to be ways to
> handle bigger types for their occasional usage. The point is that there
> is little need for multiple sizes for "normal" everyday usage - a signed
> 64-bit type really will work for practically everything.

I do not care about sizes, I do about the ranges. I do not want to
consider if the target supports the range I need. I just do not care, I
want the compiler to implement my requirement. If that means emulation,
OK, what is the alternative anyway?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 30/08/2021 21:09, James Harris wrote:
> On 30/08/2021 12:45, Bart wrote:
>> On 30/08/2021 11:44, James Harris wrote:
>>> On 26/08/2021 11:43, Bart wrote:
>>>
>>> ...
>>>
>>>> C shouldn't come into it at all. A 'C type system' isn't really a
>>>> type system, but just a thin layer over the underlying hardware.
>
> ...
>
>>> You shouldn't have a go at C's type system until you have tried to
>>> adapt yours for different word sizes. Your choice of making
>>> everything 64-bit give you enormous luxuries that were not available
>>> in decades past!
>>>
>>
>>
>> 64-bit is simply using the native word size of the processor.
>
> I'm sure I've seen you espousing it for other things, too. ;-)
>
> ...
>
>> You can argue that C was created when there were more diverse
>> word-sizes and fewer byte-addressed machines, but it should have been
>> obvious a few years after its creation, which way things were going.
>> It had plenty of opportunity to get things in order.
>
> My point was that even today C can be used to write programs for
> machines with word sizes you would hate whereas you've been able to
> avoid the complexity of all those issues by simply avoiding supporting
> such machines. So don't be too hard on C's type system. Most of it is
> there for a reason.
>
>

Have a look at this benchmark:

https://github.com/sal55/langs/blob/master/bench.c

(Notice the comment that the code was modified for 64 bits.)

If I try and run this on 64-bit Windows, it crashes. gcc will kindly
point out the reason: it uses both 'int' and 'long', and here assumes
that long is wide enough (presumably wider than int) to store a pointer
value.

I can fix it by changing 'long' to 'long long'. (Although for the
purpose here, probably intptr_t would be more apt.)

You might argue that it is Windows' or MS' fault for not using a more
sensible width of 'long', but the fact is that C ALLOWS all these
disparate versions of types such as 'long'.

It might be the same width as 'int'; it might be double the width; it
might be anything so long as it's not smaller than 'int'.

So there is a clear advantage these days in an 'int' type that grows
with the word size and is the same size as an address. Although this
benchmark might have then gone wrong in assuming that 'int' was 32 bits.

Yes, it was probably poorly written too. But the language doesn't help.

On 31/08/2021 10:21, Dmitry A. Kazakov wrote:
> On 2021-08-31 09:16, David Brown wrote:
>
>> If you want to limit types to one single size of integer (except perhaps
>> for FFI or large arrays), then 64-bit is a good choice unless you need
>> to be as efficient as possible on small embedded systems.  All modern
>> PC's or bigger embedded systems (phones, etc.) handle 64-bit natively,
>> so smaller sizes are not faster for general use.  Outside of mathematics
>> and applications like cryptography, it is rare for an integer to be
>> bigger than 2 ^ 31.  But it is extremely rare to need values bigger than
>> 2 ^ 63.  So for practical purposes, you can usually treat a 64-bit
>> integer as "unlimited".
>
> 128-bit is appears in networking protocols, right, because of
> cryptography. There are other formats for which 128-bit is required,
> e.g. IEEE decimal numbers have mantissa longer than 64-bit.
>
> I think that the language should allow any range. If the target does not
> support the particular range, the compiler should deploy a library
> implementation, giving a warning.
>

Using a 64-bit default integer type does not preclude having a 128-bit
type too (which is exactly what I have).

Some uses for 128-bit are not necessarily about representing numbers
that range from 0 to 2**127-1 or 2**128-1; they just need that number of
bits, perhaps as a descriptor, but one where it is convenient to be able
to apply bitwise operations to.

Then specifying that type as a range of values is not really appropriate.

(I would also dispute the claim that integers needing more than 32 bits
are rare enough that the default - on 64-BIT MACHINES - should be 32 bits.

Probably the stats would show that most 32-bit integer values would fit
into 16 bits or even 8 (there are a lot of 0s around!), but you don't
really want a default 16-bit integer and have to constantly keep in mind
whether you values will be below 16 bits or above. Same with int32.)

On 31/08/2021 13:24, Bart wrote:
> On 30/08/2021 21:09, James Harris wrote:
>> On 30/08/2021 12:45, Bart wrote:
>>> On 30/08/2021 11:44, James Harris wrote:
>>>> On 26/08/2021 11:43, Bart wrote:
>>>>
>>>> ...
>>>>
>>>>> C shouldn't come into it at all. A 'C type system' isn't really a
>>>>> type system, but just a thin layer over the underlying hardware.
>>
>> ...
>>
>>>> You shouldn't have a go at C's type system until you have tried to
>>>> adapt yours for different word sizes. Your choice of making
>>>> everything 64-bit give you enormous luxuries that were not available
>>>> in decades past!
>>>>
>>>
>>>
>>> 64-bit is simply using the native word size of the processor.
>>
>> I'm sure I've seen you espousing it for other things, too. ;-)
>>
>> ...
>>
>>> You can argue that C was created when there were more diverse
>>> word-sizes and fewer byte-addressed machines, but it should have been
>>> obvious a few years after its creation, which way things were going.
>>> It had plenty of opportunity to get things in order.
>>
>> My point was that even today C can be used to write programs for
>> machines with word sizes you would hate whereas you've been able to
>> avoid the complexity of all those issues by simply avoiding supporting
>> such machines. So don't be too hard on C's type system. Most of it is
>> there for a reason.
>>
>>
>
> Have a look at this benchmark:
>
>   https://github.com/sal55/langs/blob/master/bench.c
>
> (Notice the comment that the code was modified for 64 bits.)
>
> If I try and run this on 64-bit Windows, it crashes. gcc will kindly
> point out the reason: it uses both 'int' and 'long', and here assumes
> that long is wide enough (presumably wider than int) to store a pointer
> value.

If you cast a pointer to a "long", you deserve all the problems you get.
Why on earth would you thing that is a good idea?

>
> I can fix it by changing 'long' to 'long long'. (Although for the
> purpose here, probably intptr_t would be more apt.)

Fix it by using pointers as pointers, and don't faff around with casting
them into random integer types! If you desperately need to hold
different types of pointers in the same variable (though it is often an
indication of poor program structure), use "void *".

But you've got code there that casts pointers into longs, and then
compares them to an int...

>
> You might argue that it is Windows' or MS' fault for not using a more
> sensible width of 'long', but the fact is that C ALLOWS all these
> disparate versions of types such as 'long'.
>

No, the fault here is the programmer's alone.

There /are/ cases where it makes sense to turn pointers into integers,
because you want to do weird things such as compact storage in large
arrays, or low-level stuff like checking alignments. The type
"uintptr_t" has existed for that purpose for 20 years. The C
preprocessor to check type sizes and make your own local equivalent to
"uintptr_t" has existed for 50 years. There has /never/ been an excuse
to cast a pointer to an int, or a long, or other guessed type and think
it is a good idea.

You are not alone in writing bad code like this, but that does not
excuse you.

> It might be the same width as 'int'; it might be double the width; it
> might be anything so long as it's not smaller than 'int'.
>
> So there is a clear advantage these days in an 'int' type that grows
> with the word size and is the same size as an address. Although this
> benchmark might have then gone wrong in assuming that 'int' was 32 bits.
>

No, there is no sense in having the size of "int" related to the size of
a pointer, because the two have totally different purposes and should
not be mixed.

"long" means "at least 32-bit". Nothing more, nothing less - and if you
use it to mean more, you are using it incorrectly.

> Yes, it was probably poorly written too. But the language doesn't help.

The language lets you write bad code. What language does not?

On 31/08/2021 14:31, David Brown wrote:
> On 31/08/2021 13:24, Bart wrote:

>> Have a look at this benchmark:
>>
>>   https://github.com/sal55/langs/blob/master/bench.c
>>
>> (Notice the comment that the code was modified for 64 bits.)
>>
>> If I try and run this on 64-bit Windows, it crashes. gcc will kindly
>> point out the reason: it uses both 'int' and 'long', and here assumes
>> that long is wide enough (presumably wider than int) to store a pointer
>> value.
>
> If you cast a pointer to a "long", you deserve all the problems you get.
> Why on earth would you thing that is a good idea?

This is not my code. I made the minimum changes needed so that the
benchmark gave meaningful results, since I don't understand how it works.

>>
>> I can fix it by changing 'long' to 'long long'. (Although for the
>> purpose here, probably intptr_t would be more apt.)
>
> Fix it by using pointers as pointers, and don't faff around with casting
> them into random integer types! If you desperately need to hold
> different types of pointers in the same variable (though it is often an
> indication of poor program structure), use "void *".
>
> But you've got code there that casts pointers into longs, and then
> compares them to an int...

I suspect that made more sense in the original BCPL (see below), which I
think only had a single type, a machine word.

That was a very simple model appropriate to the word-addressed machines
at the time, but could now could be once again useful with 64-bit machines.

Look also at Knuth's MMIX assembler for a machine where everything is 64
bits too; registers can hold 64-bit ints or 64-bit floats or 64-bit
addresses.

>> You might argue that it is Windows' or MS' fault for not using a more
>> sensible width of 'long', but the fact is that C ALLOWS all these
>> disparate versions of types such as 'long'.
>>
>
> No, the fault here is the programmer's alone.

This program used both 'int' and 'long' types; why? What assumptions
where there about certain properties of long that weren't present for int?

You can't pin this one on MS, because Linux32 has them the same size
too. (Although if the intention was for long to hold an address, that
would work here.)

> There /are/ cases where it makes sense to turn pointers into integers,
> because you want to do weird things such as compact storage in large
> arrays, or low-level stuff like checking alignments. The type
> "uintptr_t" has existed for that purpose for 20 years. The C
> preprocessor to check type sizes and make your own local equivalent to
> "uintptr_t" has existed for 50 years. There has /never/ been an excuse
> to cast a pointer to an int, or a long, or other guessed type and think
> it is a good idea.
>
> You are not alone in writing bad code like this, but that does not
> excuse you.

(If you think the C is poor, look at the orginal BCPL code, somewhere in
the links here:

https://www.cl.cam.ac.uk/~mr10/Bench.html)

>
>> It might be the same width as 'int'; it might be double the width; it
>> might be anything so long as it's not smaller than 'int'.
>>
>> So there is a clear advantage these days in an 'int' type that grows
>> with the word size and is the same size as an address. Although this
>> benchmark might have then gone wrong in assuming that 'int' was 32 bits.
>>
>
> No, there is no sense in having the size of "int" related to the size of
> a pointer, because the two have totally different purposes and should
> not be mixed.

It makes life simpler in many, many situations where both have to exist
in the same location. This hasn't always been possible (eg. 8086 with
16-bit ints and 32-bit pointers and floats); but it is now.

For example, I use bytecode which is a 64-bit array of values, where any
element can variously be:

* A bytecode index (8 bits) ...
* ... usually fixed up as a pointer to a function handler (64 bits)
* An immediate 64-bit int operand
* An immediate 64-bit float operand
* A label address (64 bits)
* A pointer to a symbol table entry
* The address of a static variable
* The offset of a local variable
* A pointer to a string object

You get the idea.

> "long" means "at least 32-bit". Nothing more, nothing less - and if you
> use it to mean more, you are using it incorrectly.
>
>> Yes, it was probably poorly written too. But the language doesn't help.
>
> The language lets you write bad code. What language does not?

C makes it easier in this case by not being strict with its type system.
This example was from the 1990s, but you can still write such code now.

On 31/08/2021 16:38, Bart wrote:
> On 31/08/2021 14:31, David Brown wrote:
>> On 31/08/2021 13:24, Bart wrote:
>
>>> Have a look at this benchmark:
>>>
>>>    https://github.com/sal55/langs/blob/master/bench.c
>>>
>>> (Notice the comment that the code was modified for 64 bits.)
>>>
>>> If I try and run this on 64-bit Windows, it crashes. gcc will kindly
>>> point out the reason: it uses both 'int' and 'long', and here assumes
>>> that long is wide enough (presumably wider than int) to store a pointer
>>> value.
>>
>> If you cast a pointer to a "long", you deserve all the problems you get.
>>   Why on earth would you thing that is a good idea?
>
> This is not my code. I made the minimum changes needed so that the
> benchmark gave meaningful results, since I don't understand how it works.
>

Fair enough.

>>>
>>> I can fix it by changing 'long' to 'long long'. (Although for the
>>> purpose here, probably intptr_t would be more apt.)
>>
>> Fix it by using pointers as pointers, and don't faff around with casting
>> them into random integer types!  If you desperately need to hold
>> different types of pointers in the same variable (though it is often an
>> indication of poor program structure), use "void *".
>>
>> But you've got code there that casts pointers into longs, and then
>> compares them to an int...
>
> I suspect that made more sense in the original BCPL (see below), which I
> think only had a single type, a machine word.
>

Yes, that would be the case for BCPL.

> That was a very simple model appropriate to the word-addressed machines
> at the time, but could now could be once again useful with 64-bit machines.
>
> Look also at Knuth's MMIX assembler for a machine where everything is 64
> bits too; registers can hold 64-bit ints or 64-bit floats or 64-bit
> addresses.

I have great respect for Knuth and his work. But his MMIX is a hideous
design even for that time, and a serious hinder to understanding his
algorithms. (There's nothing wrong with 64-bit registers that can hold
integers, floats or addresses - that bit's fine. IMHO, of course.)

>
>>> You might argue that it is Windows' or MS' fault for not using a more
>>> sensible width of 'long', but the fact is that C ALLOWS all these
>>> disparate versions of types such as 'long'.
>>>
>>
>> No, the fault here is the programmer's alone.
>
> This program used both 'int' and 'long' types; why? What assumptions
> where there about certain properties of long that weren't present for int?
>

The program is assuming that "long" is big enough to hold addresses.
And it also at one point compares an int against a pointer converted to
a long. Something is screwed there. (I haven't tried to follow the
program logic enough to see what.)

> You can't pin this one on MS, because Linux32 has them the same size
> too. (Although if the intention was for long to hold an address, that
> would work here.)
>

No, I pin it on the programmer.

>
>> There /are/ cases where it makes sense to turn pointers into integers,
>> because you want to do weird things such as compact storage in large
>> arrays, or low-level stuff like checking alignments.  The type
>> "uintptr_t" has existed for that purpose for 20 years.  The C
>> preprocessor to check type sizes and make your own local equivalent to
>> "uintptr_t" has existed for 50 years.  There has /never/ been an excuse
>> to cast a pointer to an int, or a long, or other guessed type and think
>> it is a good idea.
>>
>> You are not alone in writing bad code like this, but that does not
>> excuse you.
>
> (If you think the C is poor, look at the orginal BCPL code, somewhere in
> the links here:
>
> https://www.cl.cam.ac.uk/~mr10/Bench.html)
>

Thanks, but no thanks :-) I am happy to have missed out on BCPL.

Usually translating code from one program language into another is as
successful as translating poetry from one human language to another.
Unless you are willing to re-write significant parts in a manner
appropriate to the new language, it is never going to be good.

>
>>
>>> It might be the same width as 'int'; it might be double the width; it
>>> might be anything so long as it's not smaller than 'int'.
>>>
>>> So there is a clear advantage these days in an 'int' type that grows
>>> with the word size and is the same size as an address. Although this
>>> benchmark might have then gone wrong in assuming that 'int' was 32 bits.
>>>
>>
>> No, there is no sense in having the size of "int" related to the size of
>> a pointer, because the two have totally different purposes and should
>> not be mixed.
>
> It makes life simpler in many, many situations where both have to exist
> in the same location.

What situations? When do you need to interpret a pointer as an integer,
or an integer as a pointer? (You can share memory space between them
with a union - that's a different thing.)

> This hasn't always been possible (eg. 8086 with
> 16-bit ints and 32-bit pointers and floats); but it is now.
>
> For example, I use bytecode which is a 64-bit array of values, where any
> element can variously be:
>
>   * A bytecode index (8 bits) ...
>   * ... usually fixed up as a pointer to a function handler (64 bits)
>   * An immediate 64-bit int operand
>   * An immediate 64-bit float operand
>   * A label address (64 bits)
>   * A pointer to a symbol table entry
>   * The address of a static variable
>   * The offset of a local variable
>   * A pointer to a string object
>
> You get the idea.
>

Yes - it's a union.

There is no requirement or even benefit in having pointers and integers
the same size.

>
>> "long" means "at least 32-bit".  Nothing more, nothing less - and if you
>> use it to mean more, you are using it incorrectly.
>>
>>> Yes, it was probably poorly written too. But the language doesn't help.
>>
>> The language lets you write bad code.  What language does not?
>
> C makes it easier in this case by not being strict with its type system.
> This example was from the 1990s, but you can still write such code now.
>

C is a lot stricter with types than many people seem to think. Casting
is a way of writing "I know this is probably a bad idea, and it is
breaking the type system, but do it anyway". C views pointers and
integer types as completely separate, but gives you a way to work around
those rules.

On 31/08/2021 16:32, David Brown wrote:
> On 31/08/2021 16:38, Bart wrote:

>> It makes life simpler in many, many situations where both have to exist
>> in the same location.
>
> What situations? When do you need to interpret a pointer as an integer,
> or an integer as a pointer? (You can share memory space between them
> with a union - that's a different thing.)

A union is a clunkier way of doing the same way. But you can't as easily
access the int/float/pointer representation.

>> For example, I use bytecode which is a 64-bit array of values, where any
>> element can variously be:
>>
>>   * A bytecode index (8 bits) ...
>>   * ... usually fixed up as a pointer to a function handler (64 bits)
>>   * An immediate 64-bit int operand
>>   * An immediate 64-bit float operand
>>   * A label address (64 bits)
>>   * A pointer to a symbol table entry
>>   * The address of a static variable
>>   * The offset of a local variable
>>   * A pointer to a string object
>>
>> You get the idea.
>>
>
> Yes - it's a union.
>
> There is no requirement or even benefit in having pointers and integers
> the same size.

There is a benefit in this case. On a system with 32-bit pointers, if I
still wanted 64-bit immediates, it would be too inefficient to have
64-bit bytecode as vast majority of entries wouldn't need it.

I'd have to use 32-bit bytecode with immediates spanning two operands,
or indexed via indices into a table.

But where everything is the same size anyway, it makes life easier with
simpler decisions.

>> C makes it easier in this case by not being strict with its type system.
>> This example was from the 1990s, but you can still write such code now.
>>
>
> C is a lot stricter with types than many people seem to think.

Not in a useful way. I needed to convert that benchmark to my language,
and spent a lot of time changing all those zeros used for NULL, into nil.

And when it really counts, C lets you down. If I create this data
structure in my language:

ref[]ref int P

(Pointer to array of pointer to int.) Then to access one of those ints,
the full syntax (because the first ^ is optional) is:

P^[i]^

That is, deref, index, deref, exactly following the type, and in the
same left-to-right order. In C, it ought to be something like this:

int *((*P)[]);

int a = *((*P)[i];

That is, deref, index, deref like above. Except you can also do:

int b = ***P; // deref deref deref
int c = P[i][j][k]; // index index index
int d = (*P[i])[j]; // index deref index

What the hell happened to C's type strictness?! Why am I being allowed
to write nonsense?

I can write that access 8 different ways, but only one is correct (2**N
combinations of index/deref ops).

If I try any of those seven wrong ways in my language:

P^^^
P[i,j,k]
p[i]^[j]

it generates a type error each time.

However this is straying into other crazy aspects of C than type
denotations.

On 31/08/2021 19:15, Bart wrote:
> On 31/08/2021 16:32, David Brown wrote:
>> On 31/08/2021 16:38, Bart wrote:
>
>>> It makes life simpler in many, many situations where both have to exist
>>> in the same location.
>>
>> What situations?  When do you need to interpret a pointer as an integer,
>> or an integer as a pointer?  (You can share memory space between them
>> with a union - that's a different thing.)
>
> A union is a clunkier way of doing the same way. But you can't as easily
> access the int/float/pointer representation.

What? A union is a simple, type-safe way of storing different data
types in the same memory slot. And in C (but not C++), you can use it
to view the representation of different types - whereas a cast might
change it. (That can, in theory, happen when casting between pointers
and integers - though it won't do so in practice on mainstream systems.
It definitely happens when casting between floats and integers, however.)

>
>
>>> For example, I use bytecode which is a 64-bit array of values, where any
>>> element can variously be:
>>>
>>>    * A bytecode index (8 bits) ...
>>>    * ... usually fixed up as a pointer to a function handler (64 bits)
>>>    * An immediate 64-bit int operand
>>>    * An immediate 64-bit float operand
>>>    * A label address (64 bits)
>>>    * A pointer to a symbol table entry
>>>    * The address of a static variable
>>>    * The offset of a local variable
>>>    * A pointer to a string object
>>>
>>> You get the idea.
>>>
>>
>> Yes - it's a union.
>>
>> There is no requirement or even benefit in having pointers and integers
>> the same size.
>
> There is a benefit in this case. On a system with 32-bit pointers, if I
> still wanted 64-bit immediates, it would be too inefficient to have
> 64-bit bytecode as vast majority of entries wouldn't need it.
>
> I'd have to use 32-bit bytecode with immediates spanning two operands,
> or indexed via indices into a table.
>

Unions are the appropriate solution here too. (You could also use
memcpy, or copy directly using unsigned char pointers, but that would be
inefficient if you don't have a good enough compiler.) Casting won't
work when there are floats involved.

On 30/08/2021 23:25, Bart wrote:
> On 30/08/2021 21:09, James Harris wrote:
>> On 30/08/2021 12:45, Bart wrote:

....

>> So don't be too hard on C's type system. Most of it is
>> there for a reason.
>
> OK. It all depends on how much you want to emulate C in that regard, and
> so inherit a lot of the same mess in its type system.

....

> But it seems that you are keen to cover everything in one language, from
> the tiniest microcontrollers, through desktop PCs and current
> supercomputers, and up to massively large machines that need 128 bits to
> specify file sizes.

It seems a lot when you put it that way but AISI a program should
express an algorithm and the compiler should action that algorithm on
whatever CPU is the target.

>
> I'd say that's being a little ambitious.

It may be. Though emitting code for different CPUs looks as though it is
going to be one of the less difficult issues!

> (Are you still writing OSes too?)

I have an OS project. It was largely dormant for years but I recently
started to write code for it in my own language now that I have a
primitive form of my language running. It was, in fact, to help with the
OS that I started the language project in the first place - but it
rather developed a life of its own!

....

> > you've been able to
> > avoid the complexity of all those issues by simply avoiding supporting
> > such machines.
>
> It wasn't my job to support every possible machine.

Sure. Not saying you should. It's just that what you see as wrong with
C's type system may be partly due to it having to support so many
diverse CPUs.

> Note that even C compilers for smaller devices such as Z80 can be rather
> specialist products.

Any idea why C for Z80 should be a specialist product?

--
James Harris

On 31/08/2021 18:45, James Harris wrote:
> On 30/08/2021 23:25, Bart wrote:

>
>> Note that even C compilers for smaller devices such as Z80 can be
>> rather specialist products.
>
> Any idea why C for Z80 should be a specialist product?
>

Well it's one of the devices listed here:

http://sdcc.sourceforge.net

Possibly because it also comes in packages with integrated peripherals
that may need language support.

On 31/08/2021 11:57, David Brown wrote:

....

> The point is that when you want a /number/ - an integer - then 64-bit is
> more than sufficient for most purposes while also not being too big to
> handle efficiently on most modern cpus. You could almost say that about
> 32-bit, but definitely say it now we have 64-bit. This is why no one
> has bothered making a 128-bit processor - there simply isn't any use for
> such large numbers as plain integers.

In terms of the main registers 64 bits is fine, especially when they are
used for memory addresses as well as integers. However, that's not the
only option. ICL made a machine with a 128-bit accumulator as far back
as the 1970s!

Today, ZFS works with 128-bit numbers. So does MD5, and probably others.

SHA-2 apparently works with sizes from 224 bits upwards.

https://en.wikipedia.org/wiki/SHA-2

>
>>
>> I think that the language should allow any range. If the target does not
>> support the particular range, the compiler should deploy a library
>> implementation, giving a warning.
>>
>
> Don't misunderstand me here - there are use-cases for all kinds of sizes
> and types. A language that intends to be efficient is going to have to
> be able to handle arrays of smaller types. And there has to be ways to
> handle bigger types for their occasional usage. The point is that there
> is little need for multiple sizes for "normal" everyday usage - a signed
> 64-bit type really will work for practically everything.

These seem OK:

int 64
int 128
uint 224
uint 256
etc

If a language includes code to manipulate 64-bit integers on 16-bit
hardware I cannot see a problem with it manipulating 256-bit integers on
64-bit hardware.

It's also surely better for a programmer to be able to write

a + b

instead of

bignum128_add(a, b)

--
James Harris

On 30/08/2021 19:06, David Brown wrote:

....

> There is also a quotation from Bjarne Stroustrup along the lines of
> every complicated language having a simple language at its core
> struggling to get out.

You could tell him it's called C. :-)

--
James Harris

On 31/08/2021 08:32, David Brown wrote:
> On 30/08/2021 22:50, James Harris wrote:

....

>> Are you saying the C standards have an official definition of 'scalar'
>> (which is along the lines you mention)?
>>
>
> Yes. 6.2.5p21 in C17. There are official drafts of the C standards
> available freely (the actual published ISO standards cost money, but the
> final drafts are free and just as good). Google for C17 draft, document
> N2176, for example.

That's really interesting. I didn't know that C was still under
development.

--
James Harris

On 31/08/2021 19:03, James Harris wrote:
> On 31/08/2021 11:57, David Brown wrote:
>
> ...
>
>> The point is that when you want a /number/ - an integer - then 64-bit is
>> more than sufficient for most purposes while also not being too big to
>> handle efficiently on most modern cpus.  You could almost say that about
>> 32-bit, but definitely say it now we have 64-bit.  This is why no one
>> has bothered making a 128-bit processor - there simply isn't any use for
>> such large numbers as plain integers.
>
> In terms of the main registers 64 bits is fine, especially when they are
> used for memory addresses as well as integers. However, that's not the
> only option. ICL made a machine with a 128-bit accumulator as far back
> as the 1970s!
>
> Today, ZFS works with 128-bit numbers. So does MD5, and probably others.
>
> SHA-2 apparently works with sizes from 224 bits upwards.
>
>   https://en.wikipedia.org/wiki/SHA-2
>
>>
>>>
>>> I think that the language should allow any range. If the target does not
>>> support the particular range, the compiler should deploy a library
>>> implementation, giving a warning.
>>>
>>
>> Don't misunderstand me here - there are use-cases for all kinds of sizes
>> and types.  A language that intends to be efficient is going to have to
>> be able to handle arrays of smaller types.  And there has to be ways to
>> handle bigger types for their occasional usage.  The point is that there
>> is little need for multiple sizes for "normal" everyday usage - a signed
>> 64-bit type really will work for practically everything.
>
> These seem OK:
>
>   int 64
>   int 128
>   uint 224
>   uint 256
>   etc
>
> If a language includes code to manipulate 64-bit integers on 16-bit
> hardware I cannot see a problem with it manipulating 256-bit integers on
> 64-bit hardware.

Have you seen C emulation code for even 128/128, based on 64-bit ops?
It's scary! It might be a bit shorter in ASM, but it can still be a lot
of work.

Below I've listed all the ops in my IL that need to deal with 64-bit
integers (floats excluded), and which, if fully supported, need to also
deal with i128/u128 types.

At the moment, in my regular compiler, 128-bit support has many holes.
Notably for divide; it only has i128/i64, which is needed to be able to
print 128-bit values.

BTW your u224 type is likely to need 64-bit alignment, so will probably
occupy 256 bits anyway. So I can't see the point of that if you've also
already got a 256-bit type.

Remember support will be hard enough without dealing with odd sizes.

--------------------------------
Binary ops:

add
sub
mul
idiv
irem
iand (bitwise)
ior
ixor
shl
shr
min
max
eq
ne
lt
le
ge
gt
andl (logical)
orl
in (a in b..c)

Unary ops:

neg
abs
inot
notl
istruel

sqr (square)
sign
atans
power

Binary inplace ops:

addto (a +:= b)
subto
multo
idivto
iremto
iandto
iorto
ixorto
shlto
shrto
minto
maxto
andlto
orlto

Unary inplace ops:

negto (-:= a, which means a := -a)
absto
inotto
notlto
istruelto

incrto (++a)
decrto
loadincr (a++ and use old value)
loaddecr
incrload (++a and use new value)
decrload

Conversions:

fix (float to int)
float (int to float)
widen (from narrower int)

Bit/Bitfield ops:

getdotindex
putdotindex
getdotslice
putdotslice

Call/Return:

pass by value
return by value
return multple-value

I/O (likely to be external to IL; implemented in user code, not by IL
backend):

print/tostring in various bases
read/fromstring

> If a language includes code to manipulate 64-bit integers on 16-bit
> hardware I cannot see a problem with it manipulating 256-bit integers on
> 64-bit hardware.

There are going to be more reasons to emulate 64 bits than 256 bits:

* To be able to run, even inefficiently, the same algorithms that run on
a native 64-bit machine

* To be able to work with everyday quantities such as file or drive
sizes, or the world population, ....

On 31/08/2021 19:30, James Harris wrote:
> On 31/08/2021 08:32, David Brown wrote:
>> On 30/08/2021 22:50, James Harris wrote:
>
> ...
>
>>> Are you saying the C standards have an official definition of 'scalar'
>>> (which is along the lines you mention)?
>>>
>>
>> Yes.  6.2.5p21 in C17.  There are official drafts of the C standards
>> available freely (the actual published ISO standards cost money, but the
>> final drafts are free and just as good).  Google for C17 draft, document
>> N2176, for example.
>
> That's really interesting. I didn't know that C was still under
> development.

What they're planning to add actually probably isn't very interesting
(it never is).

For example being able to do this in a function definition (in C2x):

void fn(int a, int, int c) {
}

Can you spot what it is?

Yes, you can leave out a parameter name without it being an error. (So
that if you do it inadvertently, you might silently end up using some
global of that name instead!)

On 2021-08-31 20:37, Bart wrote:

> Have you seen C emulation code for even 128/128, based on 64-bit ops?
> It's scary! It might be a bit shorter in ASM, but it can still be a lot
> of work.

It is easier with 32-bit because of handling the carry (since you have
no access to it in a high-level language) and because multiplication is
simpler. But in general nothing scary, all algorithms are well known.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

On 31/08/2021 20:52, Dmitry A. Kazakov wrote:
> On 2021-08-31 20:37, Bart wrote:
>
>> Have you seen C emulation code for even 128/128, based on 64-bit ops?
>> It's scary! It might be a bit shorter in ASM, but it can still be a
>> lot of work.
>
> It is easier with 32-bit because of handling the carry (since you have
> no access to it in a high-level language) and because multiplication is
> simpler. But in general nothing scary, all algorithms are well known.
>

Have a look at divmod128by128() here:

https://github.com/sal55/langs/blob/master/muldiv128.c

That in turn calls divmod128by64, shiftleft128, shiftright128,
div128by64, inc128, dec128, mult128, mult64to128, sub128 [not shown],
nlz128 [not showb] and compare128.

It's not scary at all!

On 31/08/2021 20:41, Bart wrote:
> On 31/08/2021 19:30, James Harris wrote:
>> On 31/08/2021 08:32, David Brown wrote:
>>> On 30/08/2021 22:50, James Harris wrote:
>>
>> ...
>>
>>>> Are you saying the C standards have an official definition of 'scalar'
>>>> (which is along the lines you mention)?
>>>>
>>>
>>> Yes.  6.2.5p21 in C17.  There are official drafts of the C standards
>>> available freely (the actual published ISO standards cost money, but the
>>> final drafts are free and just as good).  Google for C17 draft, document
>>> N2176, for example.
>>
>> That's really interesting. I didn't know that C was still under
>> development.
>
> What they're planning to add actually probably isn't very interesting
> (it never is).

That's intentional. C has been mostly stable since C99 - and stability
and backwards compatibility are two of its most important features as a
language. Changes are only made if they are really important, tried and
tested (in mainstream compilers and/or other languages, primarily C++),
give something that can't easily be achieved in other ways, and are not
going to risk conflicts with existing code.

So C11 added multi-threading semantics and atomics, along with
standardising a few common extensions found on many compilers, and
_Generic (to give a standard way of implementing C99 <tgmath.h> without
compiler-specific extensions). C17 was mostly just bug-fixes and minor
clarifications. C2x is expected to tidy a few obsolescent points such
as removing non-prototype function declarations (and making "int foo();"
the same as "int foo(void);", just like C++). Signed integer format
will be fixed at two's complement (but overflow is still undefined
behaviour, for which I am glad). These are all small things, but nice.

>
> For example being able to do this in a function definition (in C2x):
>
>   void fn(int a, int, int c) {
>   }
>
> Can you spot what it is?
>
> Yes, you can leave out a parameter name without it being an error. (So
> that if you do it inadvertently, you might silently end up using some
> global of that name instead!)
>

Trust you to find potential problems in every feature of C.

For other programmers, this is a good thing that some will choose to
use. It means that if you have a function implementation that does not
use a parameter, you can omit the name. This documents to readers that
the parameter is not used. And it means you can have compiler warnings
for unused parameters - if you have named a parameter and have not used
it in the function, the compiler can warn you that you've probably
forgotten something.

It is a feature that is more useful in C++ than C, since it plays well
with function overloading, and its purpose here is partly motivated by
removing an unnecessary mismatch with C++. But like anonymous unions,
it is just saying that you don't need to name things you won't use.

As for conflicts with global names - design and structure your code
sensibly, use sensible names, and you won't have any problems. If you
have a global variable called "b" and use "b" for parameter names, you
have already screwed up regardless of this new feature.

On 01/09/2021 09:13, David Brown wrote:
> On 31/08/2021 20:41, Bart wrote:
>> On 31/08/2021 19:30, James Harris wrote:
>>> On 31/08/2021 08:32, David Brown wrote:
>>>> On 30/08/2021 22:50, James Harris wrote:
>>>
>>> ...
>>>
>>>>> Are you saying the C standards have an official definition of 'scalar'
>>>>> (which is along the lines you mention)?
>>>>>
>>>>
>>>> Yes.  6.2.5p21 in C17.  There are official drafts of the C standards
>>>> available freely (the actual published ISO standards cost money, but the
>>>> final drafts are free and just as good).  Google for C17 draft, document
>>>> N2176, for example.
>>>
>>> That's really interesting. I didn't know that C was still under
>>> development.
>>
>> What they're planning to add actually probably isn't very interesting
>> (it never is).
>
> That's intentional. C has been mostly stable since C99 - and stability
> and backwards compatibility are two of its most important features as a
> language. Changes are only made if they are really important, tried and
> tested (in mainstream compilers and/or other languages, primarily C++),
> give something that can't easily be achieved in other ways, and are not
> going to risk conflicts with existing code.

That one is pretty easy: if a parameter name isn't used, then don't use
it: nothing else required! If you want to warn user and/or compiler that
it is intentionally not used, then just give it a special name (leading
underscores etc).

Then new code will still be compatible with existing compilers, and
tools that parse source code (bearing in mind it will take 20 years
before the feature will be generally available).

>> For example being able to do this in a function definition (in C2x):
>>
>>   void fn(int a, int, int c) {
>>   }
>>
>> Can you spot what it is?
>>
>> Yes, you can leave out a parameter name without it being an error. (So
>> that if you do it inadvertently, you might silently end up using some
>> global of that name instead!)
>>
>
> Trust you to find potential problems in every feature of C.

Inadvertent clashes with identically-named globals is an issue with a
few languages, including C, and all of mine.

You don't want to exacerbate the problem.

(My new script language is particularly susceptible, since it allows
'open' statements, not enclosed in a function as well as out of order
definitions. That means any variable used there, even 'i' in a loop
statement, are automatically global.

Since functions don't need to declare vaiables, if one uses 'i' too, it
will clash with the global 'i'.

I don't want to introduce new ways of dealing with scope, since my
languages have worked that way for decades. But here I use a guideline
(also enforced in the compiler but currently disabled) of not mixing
open statements with actual functions; I need to put them inside start()
or main() which is automatically called.)

On 31/08/2021 19:37, Bart wrote:
> On 31/08/2021 19:03, James Harris wrote:

....

>> If a language includes code to manipulate 64-bit integers on 16-bit
>> hardware I cannot see a problem with it manipulating 256-bit integers
>> on 64-bit hardware.
>
> Have you seen C emulation code for even 128/128, based on 64-bit ops?
> It's scary! It might be a bit shorter in ASM, but it can still be a lot
> of work.
>
> Below I've listed all the ops in my IL that need to deal with 64-bit
> integers (floats excluded), and which, if fully supported, need to also
> deal with i128/u128 types.

I've got some C for unsigned wide unsigned operations. I think it's my
own code from a number of years ago (2015). Division is a bit hairy -
but none of the code is scary!

It all looks quite logical. It covers

shifts, gets, sets, add, sub, mul, div, rem

The bitwise operations and comparisons you mention would be trivial
because the data structure is just an array

ui16 value[4];

though I wrap it in a struct so the compiler will pass it by value. I
think the code was written to give me 64-bit numbers in a 16-bit
environment. That's why the array length is 4.

And note that it's 4, not 2. Theoretically, the code would work for ANY
size of integer as long as it fits into a whole number of words. Add
some overflow handling and signed integers (which would not be so easy)
and I may have the arbitrary-length arithmetic you keep telling me is so
difficult to do!

>
> At the moment, in my regular compiler, 128-bit support has many holes.
> Notably for divide; it only has i128/i64, which is needed to be able to
> print 128-bit values.
>
> BTW your u224 type is likely to need 64-bit alignment, so will probably
> occupy 256 bits anyway. So I can't see the point of that if you've also
> already got a 256-bit type.

That's OK. I mentioned u224 because SHA-2 uses such a size. IOW there's
a real-world requirement for such a value. Another reason to provide
integers of arbitrary size - especially if it costs almost nothing.

>
> Remember support will be hard enough without dealing with odd sizes.

Why would support be hard?

In terms of storage I expect I'd round up the size at least to a whole
number of words and treat incursion into upper bits in the same way as
overflow.

--
James Harris