On 2024-02-24 13:39, Anton Ertl wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> On Wed, 21 Feb 2024 13:49:41 +0100 David Brown
>> <david.brown@hesbynett.no> wrote:
> [...]
>> However I don't think that "bonus" use of flags for bignum and
>> similar is any rarer on 64-bit machines than on 32-bit.
>
> I think Bignums are more common on 64-bit machines.

[...]

> I also think that general-purpose computers do more cryptography
> (and multi-precision arithmetic for that) than embedded computers.

Hm. That may depend on whether you are comnparing absolute numbers or
proportions of work-loads. Cryptography is very important for many
embedded systems (telecom, automatic teller machines, point-of-sale
terminals, etc.) Last I looked (several years ago), there were several
8051-based chips (small 8-bit processors) on the market with dedicated
on-chip HW accelerators for cryptography.

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:
>> I also think that general-purpose computers do more cryptography
>> (and multi-precision arithmetic for that) than embedded computers.
>
>
>Hm. That may depend on whether you are comnparing absolute numbers or
>proportions of work-loads.

I am thinking about the proportions of workloads.

>Cryptography is very important for many
>embedded systems (telecom, automatic teller machines, point-of-sale
>terminals, etc.) Last I looked (several years ago), there were several
>8051-based chips (small 8-bit processors) on the market with dedicated
>on-chip HW accelerators for cryptography.

And AMD64 and ARM A64 have acceleration instructions for symmetric
cryptographe (such as AES), too. Symmetric cryptography (with secret
keys only) does not use multi-precision arithmetic, but asymetric
cryptography (with public and private keys) does. I guess that there
is no special hardware for that because hardware that does it faster
than software would be very expensive, and because the asymmetric part
is only used at the start of a connection and when renewing the secret
key for the symmetric stuff.

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

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>Michael S <already5chosen@yahoo.com> writes:
>
>>
>>On ARM cores the number of physical flags registers is roughly 1/3 of
>>the nymber of physical integer registers (46 vs. 147 on A710, 39
>>vs. 120 on Neoverse N1/A76
>><https://chipsandcheese.com/2023/08/11/arms-cortex-a710-winning-by-default/>,
>>but I guess that this is due to being able to suppress flags updates
>>rather than ignoring those that are overwritten without being read.
>>
>>That assumes that all of A32, T32, and A64 have the ability to
>>suppress flags updates. Do they?
>
>A32, T32 and A64 have an bit in the instruction word that
>specifies whether the flags should be updated. T16
>only updates flags when the instruction is in an if-then (IT)
>block.

What is T16? Google does not give me anything appropriate for "ARM
T16"? Do you mean the 16-bit-encoded instructions in T32?

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

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> MitchAlsup1 wrote:
[...]
>> The semantics of unsigned are better when you are twiddling bits than
>> when signed. My programming practice is to use unsigned everywhere that
>> a negative number is unexpected.
>
> Ditto.

10-4.

It always surprises me to encounter people who think signed types
should be the default, with almost no exceptions. It's one thing
to be somewhat cavalier about shooting yourself in the foot, it's
quite another to deliberately choose a large caliber weapon ahead
of time.

scott@slp53.sl.home (Scott Lurndal) writes:
>David Brown <david.brown@hesbynett.no> writes:
>>On 20/02/2024 18:47, Anton Ertl wrote:
>
>>And support for 32-bit has /not/ been "eliminated from ARM cores". It
>>may have been eliminated from the latest AArch64 cores
>
>The ARMv8 architecture fully supports the A32 and T32 instruction sets.

There is no ARMv8 architecture. ARMv8-M does not support A64.
ARMv8-A and ARMv8-R do. They may also support A32 and T32, but then
the A cores released since 2021 (X2 and following, A710 and following,
A510 and following) are ARMv9-A, not ARMv8-A; and several of them do
not support A32 nor T32.

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

David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 19:42, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 20/02/2024 16:17, Terje Mathisen wrote:
>>>> x86 has had an 'O' (Overflow) flags bit since the very beginning, along
>>>> with JO and JNO for Jump on Overflow and Jump if Not Overflow.
>>>>
>>>
>>> Many processors had something similar. But I think they fell out of
>>> fashion for 64-bit RISC,
>>
>> No, it didn't. All the RISCs that had flags registers for their
>> 32-bit architectures still have it for their 64-bit architectures.
>>
>
>I was thinking more in terms of /using/ these flags, rather than ISA
>support for them. ISAs would clearly have to keep the flag registers
>and the instructions that used them if they wanted to keep compatibility
>with 32-bit code.

64-bit architectures of this century have separate 64-bit instruction
sets on which you cannot run 32-bit code. The idea of having a 32-bit
instruction set that's a subset of the 64-bit instruction set, and
supporting both 32-bit programs and 64-bit programs without mode
switch seems to have gone out of fashion; it used to be in fashion in
the 1990s when MIPS, SPARC, and PowerPC introduced 64-bit extensions
by just adding instructions to their 32-bit instruction set (and
defining what the 32-bit instructions do with the additional bits in
the GPRs). So if AMD and ARM had thought that they would be better
off in the long term without flags, they could have designed AMD64 and
A64 to work without flags.

>But I think it was fairly rare to use the "add 32-bit and update flags"
>instruction in 32-bit RSIC systems (except for 64-bit arithmetic), and
>much rarer to use the "add 64-bit and update flags" version in 64-bit
>versions.

On ARM A64's glibc-2.31:

[a76:/usr/lib/aarch64-linux-gnu:99372] objdump -d libc-2.31.so |grep '\<add\>'|wc -l
19330
[a76:/usr/lib/aarch64-linux-gnu:99373] objdump -d libc-2.31.so |grep '\<adds\>'|wc -l
277

However, glibc is written in C. If you look at code for a language
with Bignums, I expect that things look quite differently.

>> No, it isn't, as demonstrated by the fact that architectures with
>> flags registers (AMD64, ARM A64) handily outperform architectures
>> without (but probably not because they have a flags register).
>
>I think it would mainly be /despite/ having a flag register, rather than
>/because/ of it?

There is no evidence for "despite".

>Sometimes having flags for overflows, carries, etc., can be very handy.
>So having it in the ISA is useful. But I think you would normally want
>your code to avoid setting or reading flags.

If each instruction can specify whether it sets flags or not, that
costs one bit per instruction, which is also a cost.

AMD64 does not spend that bit, and I see no evidence that its
performance suffers from setting flags too often.

>It would, I think, be particularly cumbersome to track several parallel
>actions that all act on the flag register, as it is logically a shared
>resource.

Not particularly. The renamer ensures that the instructions write to
different physical flags registers, and that instructions that read
flags read the right physical register.

>Do you think it is an advantage for a RISC architecture to have a flags
>register compared to alternatives?

I think my alternative of putting carry and overflow in the result
register has certain advantages.

If you compare a RISC with a flags register (such as A64) to RV64GC,
certainly the add-with-carry-in-carry-out is 1 instruction (with
typically 1 cycle latency) in A64 and 5 (with typically 3 cycles
latency) in RV64GC; and the overflow check in the fast path for a
Bignum addition is 2 instructions longer than on A64.

>> That's nonsense. People use carry for implementing multi-precision
>> arithmetic (e.g., for cryptography) and for Bignums, and they use
>> overflow for implementing Bignums. And the significance of these
>> features has increased over time.
>>
>
>Fair enough, you do want carry (or an equivalent) for big number work.
>But I would still contend that the vast majority of integers and integer
>arithmetic used in code will fit within 32 bits, and the vast majority
>of those that don't, will fit within 64 bits.

Sure. But with Bignums, you have to check for overflow after every
addition, subtraction, or multiplication. Actually, you need a check
even with division: The result of dividing the smallest small Bignum
by -1 does not fit in a small Bignum.

>Once you go beyond that,
>you will need lots of bits (such as, as you say, cryptography).

Yes, so you need multi-precision arithmetic on 64-bit systems just as
on 32-bit systems.

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

On Sat, 24 Feb 2024 17:21:25 GMT
anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> scott@slp53.sl.home (Scott Lurndal) writes:
> >anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
> >>Michael S <already5chosen@yahoo.com> writes:
> >
> >>
> >>On ARM cores the number of physical flags registers is roughly 1/3
> >>of the nymber of physical integer registers (46 vs. 147 on A710, 39
> >>vs. 120 on Neoverse N1/A76
> >><https://chipsandcheese.com/2023/08/11/arms-cortex-a710-winning-by-default/>,
> >>but I guess that this is due to being able to suppress flags updates
> >>rather than ignoring those that are overwritten without being read.
> >>
> >>That assumes that all of A32, T32, and A64 have the ability to
> >>suppress flags updates. Do they?
> >
> >A32, T32 and A64 have an bit in the instruction word that
> >specifies whether the flags should be updated. T16
> >only updates flags when the instruction is in an if-then (IT)
> >block.
>
> What is T16? Google does not give me anything appropriate for "ARM
> T16"? Do you mean the 16-bit-encoded instructions in T32?
>
> - anton

Scott probably uses a name T16 for pre-ARMv7 variant of Thumb.

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> David Brown wrote:
>
>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>
>>> Anton Ertl wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> On the third (i.e gripping) hand you could have a language like
>>>>> Java where it would be illegal to transform a temporarily
>>>>> trapping loop into one that would not trap and give the
>>>>> mathematically correct answer.
>>>>
>>>> What "temporarily trapping loop" and "mathematically correct
>>>> answer"?
>>>>
>>>> If you are talking about integer arithmetic, the limited integers
>>>> in Java have modulo semantics, i.e., they don't trap, and
>>>> BigIntegers certainly don't trap.
>>>>
>>>> If you are talking about FP (like I did), by default FP addition
>>>> does not trap in Java, and any mention of "mathematically
>>>> correct" in connection with FP needs a lot of further
>>>> elaboration.
>>>
>>> Sorry to be unclear:
>>
>> I haven't really been following this thread, but there's a few
>> things here that stand out to me - at least as long as we are
>> talking about C.
>
> I realized a bunch of messages ago that it was a bad idea to write
> (pseudo-)C to illustrate a general problem. :-(
>
> If we have a platform where the default integer size is 32 bits
> and long is 64 bits, then afaik the C promotion rules will use int
> as the accumulator size, right?

For a signed type T, a C implementation is free to hold values of
type T in any memory cell that is at least as wide as T, and in
particular can hold a 32-bit int in a 64-bit register, if it so
chooses. More specifically, an implementation may translate a
statement like (assume x and y are 32-bit ints)

x = x + y;

using a 64-bit add, and store the full 64-bit result into a
64-bit register that corresponds to x. Note that what causes the
problem is not the store of a large result but the addition that
overflows the nominal 32-bit type. As long as the results of the
addition are in range, everything is fine; but once any of the
additions overflows the nominal 32-bit range, all bets are off.

> What I was trying to illustrate was the principle that by having a
> wider accumulator you could aggregate a series of numbers, both
> positive and negative, and get the correct (in-range) result, even
> if the input happened to be arranged in such a way that it would
> temporarily overflow the target int type.
>
> I think it is much better to do it this way and then get a
> conversion size trap at the very end when/if the final sum is in
> fact too large for the result type.

Absolutely, and for the accumulator choose the widest signed type
available. At the tail end of the loop, the final value can (and
should?) be ranged checked, because storing an out-of-range value
into a smaller type is a "safe" operation in that what happens is
implementation-defined behavior, so it's very likely nothing very
bad will happen (at least not right away ;).

mitchalsup@aol.com (MitchAlsup1) writes:

> Terje Mathisen wrote:
>
>> If we have a platform where the default integer size is 32 bits
>> and long is 64 bits, then afaik the C promotion rules will use
>> int as the accumulator size, right?
>
> Not necessarily:: accumulation rules allow the promotion of
> int->long inside a loop

Yes.

> if the long is smashed back to int immediately after the loop
> terminates.

Doing this may be a good idea, but the C standard doesn't require
it. Once the horse is out of the barn, as far as the standard is
concerned there nothing that forces an implementation to evidence
any concern about getting the horse back inside.

In particular, an implementation may continue holding a 32-bit int
in a 64-bit memory for the rest of the program's execution, making
use of all 64 bits in any subsequent operations, and not run afoul
of what the standard requires.

Tim Rentsch wrote:

> 10-4.

> It always surprises me to encounter people who think signed types
> should be the default, with almost no exceptions. It's one thing
> to be somewhat cavalier about shooting yourself in the foot, it's
> quite another to deliberately choose a large caliber weapon ahead
> of time.

I am of the opinion that the proper default type is unsigned--the
only reason to use a singed type is if at some point in it life it
needs to hold a negative number.

With C-promotions, unsigned is safer when mixing signed and unsigned.

David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 18:47, Anton Ertl wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 20/02/2024 13:00, Anton Ertl wrote:
>>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>>> mitchalsup@aol.com (MitchAlsup1) writes:
>Another possible reason is that it is very useful to have integer types
>with sizes 1, 2, 4 and 8 bytes. C doesn't have many standard integer
>types, so if "int" is 64-bit, you have "short" as either 16-bit and have
>no 32-bit type, or "short" is 32-bit and you have no 16-bit type. With
>32-bit "int", it's easy to have each size without having to add extended
>integer types or add new standard integer types (like "short short int"
>for 16-bit and "short int" for 32-bit).

short had been 16-bit on 16-bit machines and on 32-bit machines, so
the right choice for 64-bit machines is to make it 16-bit, too. As
for a 32-bit type, that would then obviously be "long short". The C
compiler people had no qualms at adding "long long" when they wanted
something bigger then 32 bits on 32-bit systems, so what should keep
them from adding "long short"?

>I saw benchmarks showing x32 being measurably faster,

Sure, it's measurably faster. That's obviously not sufficient for
incurring the cost of x32.

>but it's not
>unlikely that the differences got less with more modern x86-64
>processors (with bigger caches)

Doubtful. The L1 caches have not become bigger since the days of the
K7 (1999) with its 64KB D and I caches (and the K7 actually did not
support AMD64). There has been some growth in L2+L3 combined in
recent years, but x32 already flopped earlier.

>and it's simply not worth the effort
>having another set of libraries and compiler targets just to make some
>kinds of code marginally faster.

Exactly.

>And support for 32-bit has /not/ been "eliminated from ARM cores".

Of course it has. E.g., the Cortex-X1 supports A32/T32, and its
descendants Cortex-X2, X3, X4 don't. The Cortex-A710 supports
A32/T32, it's successors A715 and A720 do not. Cortex-A510 supports
A32/T32, A520 doesn't.

>It
>may have been eliminated from the latest AArch64 cores - I don't keep
>good track of these. But for every such core sold, there will be
>hundreds (my guestimate) of 32-bit ARM cores sold in microcontrollers
>and embedded systems.

Irrelevant for the question at hand: Are the performance benefits of
32-bit applications sufficient to pay for the cost of maintaining a
32-bit software infrastructure on an otherwise 64-bit system? The
answer is no.

>>> I would suggest C "fast" types like int_fast32_t (or other "fast" sizes,
>>> picked to fit the range you need).
>>
>> Sure, and then the program might break when an array has more the 2^31
>> elements; or it might work on one platform and break on another one.
>>
>
>You need to pick the appropriate size for your data, as I said.

In general-purpose computing, you usually don't know that size. E.g.,
for a sort routine, do you use int_fast32_t, int_fast8_t,
int_fast16_t, or int_fast64_t for the array size?

>> By contrast, with (u)intptr_t, on modern architectures you use the
>> type that's as wide as the GPRs. And I don't see a reason why to use
>> something else for a loop counter.
>
>I like my types to say what they mean. "uintptr_t" says "this object
>holds addresses for converting pointer values back and forth with an
>integer type".

Exactly. It's the unnamed type of BCPL and B, and the int of Unix C
before the I32LP64 mistake.

>Nonetheless, it is good design to use appropriate type names for
>appropriate usage. This makes the code clearer, and increases portability.

On the contrary, in the Gforth project we have had many more
portability problems with C code with its integer type zoo than in the
Forth code which just has single-cell (a machine word), double cell,
and char as integer types. Likewise, Forth code from others tends to
be pretty portable between 32-bit and 64-bit systems, even if the code
has only been tested on one kind of system.

>> As for int64_t, that tends to be
>> slow (if supported at all) on 32-bit platforms, and it is more than
>> what is necessary for indexing arrays and for loop counters that are
>> used for indexing into arrays.
>>
>
>And that is why it makes sense to use the "fast" types. If you need a
>16-bit range, use "int_fast16_t". It will be 64-bit on 64-bit systems,
>32-bit on 32-bit systems, and 16-bit on 16-bit and 8-bit systems -
>always supporting the range you need, as fast as possible.

That makes no sense. E.g., an in-memory sorting routine might well
have to sort 100G elements or more on a suitably large (64-bit)
machine. So according you one should use int_fast64_t. But that
would be slow and unnecessarily large on a 32-bit system where you
cannot hold and sort that many items anyway.

>>> Don't use "-fwrapv" unless you actually need it - in most
>>> code, if your arithmetic overflows, you have a mistake in your code, so
>>> letting the compiler assume that will not happen is a good thing.
>>
>> Thank you for giving a demonstration for Scott Lurndal. I assume that
>> you claim to be a programmer.
>>
>
>Sorry, that comment went over my head - I don't know what
>"demonstration" you are referring to.

I wrote in <2024Feb20.091522@mips.complang.tuwien.ac.at>:
|Those ideas are that integer overflows do not happen and that a
|competent programmer proactively prevents them from happening, by
|sizing the types accordingly, and checking the inputs.

Scott Lurndal replied <SW2BN.153110$taff.74839@fx41.iad>:
|Can't say that I've known a programmer who thought that way.

>For comparison to C, look at the Zig language. (It's not a language I
>have used or know in detail, but I know a little about it.) Unsigned
>integer arithmetic overflow is UB in Zig, just like signed integer
>arithmetic overflow. There are standard options and block settings
>(roughly equivalent to pragmas) to control whether these give a run-time
>error, or are assumed never to happen (for optimisation purposes). And
>if you want to add "x" and "y" with wrapping, you use "x +% y" as an
>explicit choice of operator.
>
>That seems to me to be the right approach for an efficient high-level
>language.

I don't know about Zig, but for a language like C, I would prefer
types that ask for trap-on-overflow arithmetic, or for modulo
arithmetic instead of introducing an additional operator.

The undefined option is just a bad idea: Wang et al
<https://people.eecs.berkeley.edu/~akcheung/papers/apsys12.pdf> found
that it gave a measurable speedup over -fwrapv in only one loop in
SPECint2006, and that speedup is only due to the I32LP64 mistake.
I.e., a competently designed dialect would not have that mistake, and
there would be no measurable speedup from the undefined option, just
the possibility of the compiler doing something unexpected.

>If you want "int z = x + y;" with wrapping, write :
>
> int z = (unsigned) x + (unsigned) y;

I'll leave that to you, not just for the following reason:

Once upon a time someone like you suggested using some casting
approach for getting x-1>=x (with signed x) to work as intended. I
tried it, and the result was that gcc-3.something still "optimized" it
to false.

>And even then, I always put it in a
>pragma so that the code works even if someone uses different compiler flags.

Yes, announcing such things in the source code is a good idea in
principle. In practice newer versions of gcc tend to need more sanity
flags (the default of newer gccs is more insanity), and the older
versions do not understand the new flags and fail if you pass them.
So we check every sanity flag in autoconf and use those that the gcc
version used accepts. Doing that through pragmas filled in by
configure does not seem to be any better than using flags through the
Makefile.

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

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>The Unix code ported relatively easily to I32LP64 because uintptr_t
>>>had been used extensively rather than assumptions about
>>>sizeof(int) == sizeof(int *).
....
>Sorry, I meant ptrdiff_t, which was used for pointer math.

I have seen little code that uses ptrdiff_t; quite a bit that used
size_t (the unsigned brother of ptrdiff_t). But my memory tells me
that even size_t was not very widespread in 1995.

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

John Levine <johnl@taugh.com> writes:
>There weren't instructions to do add or subtract with
>carry but it was pretty easy to fake by doing a branch on no carry
>around an instruction to add or subtract 1.

That is sufficient for double-word arithmetic, but not for multi-word
arithmetic. ESA/390 adds addition-with-carry-in.

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

mitchalsup@aol.com (MitchAlsup1) writes:

> Tim Rentsch wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> [...]
>>>>>
>>>>> int8_t sum(int len, int8_t data[])
>>>>> {
>>>>> int s = 0;
>>>>> for (unsigned i = 0 i < len; i++) {
>>>>> s += data[i];
>>>>> }
>>>>> return (int8_t) s;
>>>>> }
>>>>
>>>> The cast in the return statement is superfluous.
>>>
>>> But the return statement is where overflow (if any) is detected.
>>
>> The cast is superfluous because a conversion to int8_t will be
>> done in any case, since the return type of the function is
>> int8_t.
>
> Missing my point:: which was::
>
> The summation loop will not overflow, and overflow is detected at
> the smash from int to int8_t.

So you wanted to make a point that's completely unrelated to what I
was saying?

In any case the conversion from type int to type int8_t that is
done after loop is finished is not going to detect any overflow,
regardless of whether it is done by an explicit cast or implicitly
by the return statement. Converting an out-of-range value to a
signed integer type is merely implementation-defined behavior. As
of C99 the C standard allows a signal to be raised in such cases,
but TTBOMK no implementations actually do that (and AFAICT neither
clang nor gcc even have an option to do so).

Terje Mathisen <terje.mathisen@tmsw.no> writes:

> Tim Rentsch wrote:
>
>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>
>>> [...]
>>>
>>> int8_t sum(int len, int8_t data[])
>>> {
>>> int s = 0;
>>> for (unsigned i = 0 i < len; i++) {
>>> s += data[i];
>>> }
>>> return (int8_t) s;
>>> }
>>
>> The cast in the return statement is superfluous.
>
> I am normally writing Rust these days, where UB is far less common,
> but casts like this are mandatory.

Oh. I didn't know that about Rust. Interesting.

I'm always somewhat surprised when someone advocates using a cast
for such things, and now more surprised to learn that Rust has
chosen to impose using a cast as part of its language rules. I
understand that it has the support of community sentiment, but
even so it seems like a poor choice here. I'm not a big fan of
the new attribute syntax, but a form like

return [[narrow]] s;

looks to be a better way of asking Rust to allow what is a
normally disallowed conversion. By contrast, using a cast is
overkill. There is unnecessary redundancy, by specifying a type
in two places, and the risk that they might get out of sync. And
on general principles requiring a cast violates good security
principles. If someone needs access to a particular room in a
building, we don't hand over a master key that opens every room
in the building. If someone needs to read some documents that
have classified materials, we don't give them an access code that
lets them read any sensitive material regardless of whether it's
relevant. Maybe Rust is different, but in C a cast allows any
conversion that is possible in the language, even the unsafe
ones. It just seems wrong to use the nuclear option of casting
for every minor infringement.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>Michael S <already5chosen@yahoo.com> writes:
>>
>>>
>>>On ARM cores the number of physical flags registers is roughly 1/3 of
>>>the nymber of physical integer registers (46 vs. 147 on A710, 39
>>>vs. 120 on Neoverse N1/A76
>>><https://chipsandcheese.com/2023/08/11/arms-cortex-a710-winning-by-default/>,
>>>but I guess that this is due to being able to suppress flags updates
>>>rather than ignoring those that are overwritten without being read.
>>>
>>>That assumes that all of A32, T32, and A64 have the ability to
>>>suppress flags updates. Do they?
>>
>>A32, T32 and A64 have an bit in the instruction word that
>>specifies whether the flags should be updated. T16
>>only updates flags when the instruction is in an if-then (IT)
>>block.
>
>What is T16? Google does not give me anything appropriate for "ARM
>T16"? Do you mean the 16-bit-encoded instructions in T32?

The 16-bit subset of T32, yes.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>The Unix code ported relatively easily to I32LP64 because uintptr_t
>>>>had been used extensively rather than assumptions about
>>>>sizeof(int) == sizeof(int *).
>...
>>Sorry, I meant ptrdiff_t, which was used for pointer math.
>
>I have seen little code that uses ptrdiff_t; quite a bit that used
>size_t (the unsigned brother of ptrdiff_t). But my memory tells me
>that even size_t was not very widespread in 1995.

Unixware, early 90's:

$ find . -name '*.[ch]' -print | xargs grep size_t | wc -l
3435
$ find . -name '*.[ch]' -print | xargs grep ptrdiff_t | wc -l
86

memcpy was defined using size_t in the 1989 SVID Third Edition, Volume 1.

It appears that Anton Ertl <anton@mips.complang.tuwien.ac.at> said:
>John Levine <johnl@taugh.com> writes:
>>There weren't instructions to do add or subtract with
>>carry but it was pretty easy to fake by doing a branch on no carry
>>around an instruction to add or subtract 1.
>
>That is sufficient for double-word arithmetic, but not for multi-word
>arithmetic. ESA/390 adds addition-with-carry-in.

You could do it but you're right, it was a little trickier than that since
you had to check for the carry both on the addition and on the optional
second one. The add with carry instructions made it a lot simpler.

According to the IBM manuals, add with carry was added in z/Series but
you could use it in S/390 mode on a z machine, so I guess someone
really wanted it for some existing code.

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

Opus <ifonly@youknew.org> writes:

> On 18/02/2024 05:01, Tim Rentsch wrote:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> [...]
>>>>>
>>>>> int8_t sum(int len, int8_t data[])
>>>>> {
>>>>> int s = 0;
>>>>> for (unsigned i = 0 i < len; i++) {
>>>>> s += data[i];
>>>>> }
>>>>> return (int8_t) s;
>>>>> }
>>>>
>>>> The cast in the return statement is superfluous.
>>>
>>> But the return statement is where overflow (if any) is detected.
>>
>> The cast is superfluous because a conversion to int8_t will be
>> done in any case, since the return type of the function is
>> int8_t.
>
> Of course the conversion will be done implicitly. C converts almost
> anything implicitly. Not that this is its greatest feature.
>
> The explicit cast is still useful: 1/ to express intent (it shows that
> the potential loss of data is intentional) and then 2/ to avoid
> compiler warnings (if you enable -Wconversion, which I usually
> recommend) or warning from any serious static analyzer too (which I
> highly recommend using too).

Using a cast is a poor way to express intent:

return s; // narrow accumulated value on return

is better.

Using a cast to prevent a compiler warning is an awful
convention. See also my reply to Terje's message about
Rust. Compiler writers should be ashamed for promulgating
such a moronic idea.

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>
>>> Tim Rentsch wrote:
>>>
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>
>>>>> [...]
>>>>>
>>>>> int8_t sum(int len, int8_t data[])
>>>>> {
>>>>> int s = 0;
>>>>> for (unsigned i = 0 i < len; i++) {
>>>>> s += data[i];
>>>>> }
>>>>> return (int8_t) s;
>>>>> }
>>>>
>>>> The cast in the return statement is superfluous.
>>>
>>> But the return statement is where overflow (if any) is detected.
>>
>> The cast is superfluous because a conversion to int8_t will be
>> done in any case, since the return type of the function is
>> int8_t.
>
> I suspect most experienced C programs know that.

I expect most C programmers, even most experienced C programmers,
do not know the rules for conversions of return values. How many
readers here in comp.arch do you think know those rules? How
confident are you that you can state them, without having to look
them up? I know I was surprised when I first discovered that
return statements do not convert values the way I expected.

> Yet, the 'superfluous' cast is also documentation that the
> programmer _intended_ that the return value would be narrowed.

Using a cast is a poor way to express such an intent, as I have
explained in other postings.

mitchalsup@aol.com (MitchAlsup1) writes:

> Tim Rentsch wrote:
>
>> 10-4.
>>
>> It always surprises me to encounter people who think signed types
>> should be the default, with almost no exceptions. It's one thing
>> to be somewhat cavalier about shooting yourself in the foot, it's
>> quite another to deliberately choose a large caliber weapon ahead
>> of time.
>
> I am of the opinion that the proper default type is unsigned--the
> only reason to use a singed type is if at some point in it life it
> needs to hold a negative number.

I expect you mean that the proper default choice for signedness
is unsigned -- unsigned int rather than int, unsigned long rather
than long, etc. I agree with that view. Whether unsigned int is
a better default than unsigned long, or vice versa, is another
discussion.

> With C-promotions, unsigned is safer when mixing signed and unsigned.

Here too I expect you mean when the respective types have the
same width. Mixing a signed long and an unsigned int, for
example, is a red flag in my book.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

> scott@slp53.sl.home (Scott Lurndal) writes:
>
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>
>>>> The Unix code ported relatively easily to I32LP64 because uintptr_t
>>>> had been used extensively rather than assumptions about
>>>> sizeof(int) == sizeof(int *).
>
> ...
>
>> Sorry, I meant ptrdiff_t, which was used for pointer math.
>
> I have seen little code that uses ptrdiff_t; quite a bit that used
> size_t (the unsigned brother of ptrdiff_t). But my memory tells me
> that even size_t was not very widespread in 1995.

In 1995 a problem with both size_t and ptrdiff_t is that there
were no corresponding length modifiers for those types in
printf() format conversions (corrected in C99).

Thomas Koenig <tkoenig@netcologne.de> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:
>
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>
>>> Signed integer overflow is undefined behavior in C and prohibited
>>> in Fortran. Yet, there is no straightforward, standard-compliant
>>> way to check for signed overflow (and handle this appropriately)
>>> in either language. [...]
>>
>> It isn't hard to write standard C code to determine whether a
>> proposed addition or subtraction would overflow, and does so
>> safely and reliably.
>
> Also efficiently and without resorting to implementation-
> defined or undefined behavior (and without needing a bigger
> type)?

Heavens to Betsy! Are you impugning the quality and excellence
of my code? Of *my* code? I can only hope that you are suitably
chagrined and contrite. ;)

>> It's a little bit tedious perhaps but not
>> difficult. Checking code can be wrapped in an inline function
>> and invoke whatever handling is desired, within reason.
>
> Maybe you could share such code?

Rather that do that I will explain.

An addition overflows if the two operands have the same sign and
the sign of an operand is the opposite of the sign of the sum
(taken mod the width of the operands). Convert the signed
operands to their unsigned counterparts, and form the sum of the
unsigned values. The sign is just the high-order bit in each
case. Thus the overflow condition can be detected with a few
bitwise xors and ands.

Subtraction is similar except now overflow can occur only when
the operands have different signs and the sign of the sum is
the opposite of the sign of the first operand.

The above description works for two's complement hardware where
unsigned types have the same width as their corresponding signed
types. I think for most people that's all they need. The three
other possibilities are all doable with minor adjustments, and
code appropriate to each particular implementation can be
selected using C preprocessor conditional, as for example

#if UINT_MAX > INT_MAX && INT_MIN == -INT_MAX - 1
// this case is the one outlined above

#elif UINT_MAX > INT_MAX && INT_MIN == -INT_MAX

#elif UINT_MAX == INT_MAX && INT_MIN == -INT_MAX - 1

#elif UINT_MAX == INT_MAX && INT_MIN == -INT_MAX

Does that all make sense?

> The next question would be how to do the same for multiplication....

Multiplication is a whole other ball game. First we need to
consider only the widest types, because narrower types can be
carried out in a wider type and the resulting product value
checked. Off the top of my head, for the widest types I would
try converting to float or double, do a floating-point multiply,
and do some trivial accepts and trivial rejects based on the
exponent of the result. Any remaining cases would need more
care, but probably (we hope!) there aren't many of those and they
don't happen very often. So for what it's worth there is my
first idea. Second idea is to compute a double-width product,
or at least part of one, using standard multiple-precision
arithmetic, and speed compare against the floating-point method.
I better stop now or the ideas will probably get worse rather
than better. :/

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>Second idea is to compute a double-width product,
>or at least part of one, using standard multiple-precision
>arithmetic, and speed compare against the floating-point method.

What "standard multiple-precision arithmetic" is there in C? I am not
aware of any.

If you have widening multiplication in the language, things are
trivial. I'll use Forth because it has widening multiplication:

For the unsigned case:

( u1 u2 ) um* if ... ( handle the overflow case ) ... then

For the signed case:

( n1 n2 ) m* >r s>d r> <> if ... ( handle the overflow case ) ... then

S>D ( n -- d ) sign-extends a single-cell to a double-cell.

For those of you who are Forth-illiterate, here's how it might look in
C, with (U)Word and (U)Doubleword integer types and some assumptions
about things that the standardized subset of C does not define:

For the unsigned case:

UDoubleword ud = u1 * (UDoubleword)u2;
if ((ud>>(8*sizeof(UWord))) != 0) {
... /* handle the overflow case */ ...
}

For the signed case:

Doubleword d = n1 * (Doubleword)n2;
Word dlo = d; /* dlo contains the low-order bits of d */
if (d != (Doubleword)dlo) {
.... /* handle the overflow case */ ...
}

I'll leave it to the advocates of the standardized subset of C to
rewrite this in a way that can be executed in a strictly conforming
program.

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

John Levine <johnl@taugh.com> writes:
>According to the IBM manuals, add with carry was added in z/Series but
>you could use it in S/390 mode on a z machine, so I guess someone
>really wanted it for some existing code.

Interestingly,
<https://en.wikibooks.org/wiki/360_Assembly/360_Instructions> lists
ALC, ALCR, SLB and SLBR as belonging to the 390 instructions, and only
ALCG, ALCGR, SLBG and SLBGR (the 64-bit variants) as Z instructions.

If they added ALC, ALCR, SLB and SLBR only in Z (but in the S/390
mode), that is counterevidence for the claim that add-with-carry is
less important for 64-bit systems than for 32-bit systems.

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