Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> I know no implementation of a 64-bit architecture where ALU operations
>>> (except maybe division where present) is slower in 64 bits than in 32
>>> bits. I would have chosen ILP64 at the time, so I can only guess at
>>> their reasons:
>>
>>A guess: people did not want sizeof(float) != sizeof(float).
>
> I assume that you mean that people wanted sizeof(int)==sizeof(float).
> Why would they want that? That certainly did not hold on the PDP-11
> and many other 16-bit systems where sizeof(int)==2 and
> sizeof(float)==4.
>
>>float
>>is cerainly faster than double.
>
> On the 21064 or MIPS R4000 (the first 64-bit systems after those by
> Cray)? I am pretty sure that FP addition, subtraction and
> multiplication have the same speed on these CPUs in binary32 and
> binary64.

Cache size and memory bandwidth also play a role...

When you're doing huge vector-matrix multiplications to solve
large sets of equations, memory bandwidth is usually the bottleneck.

If you can get away with 32-bit reals, you do it - it is a factor of
two, after all.

These days, people are actually trying to do preconditioning with 16-bit
floats go gain another factor of two.

And nowadays, with SIMD, the advantage of shorter data types is even
more pronounced.

>>It would also broken Fortran, where storage aasociation rules mean
>>that both REAL and INTEGER have to have the same size, and DOUBLE
>>PRECISION twice that. Breaking that would have invalidated just
>>about every large scientific program at the time.
>
> C compilers choose their types according to their rules, and Fortran
> chooses its types according to its rules. I don't see what C's int
> type has to do with Fortran's INTEGER type.

C does not exist in a vacuum, especially if it is the systems
programming language for a system that Fortran is supposed to run
on, and run on well.

Two examples: not being able to call BLAS subroutines from C
would have made scientific C people unhappy, and not being able
to call C functions via the de-facto stanard established by Bell's
Fortran 77 compiler and later f2c would have made a lot of Fortran
people unhappy.

>And if the rules you
> specify above mean that Fortran on the PDP-11 has a 4-byte INTEGER
> type, there is already precedent for int having a different size from
> INTEGER.

And that was suboptimal, but it did not make Fortran unusable by
requiring a 128-bit DOUBLE PRECISION like your suggestion would.

On 23/02/2024 20:55, MitchAlsup1 wrote:
> Thomas Koenig wrote:
>
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> I know no implementation of a 64-bit architecture where ALU operations
>>> (except maybe division where present) is slower in 64 bits than in 32
>>> bits.  I would have chosen ILP64 at the time, so I can only guess at
>>> their reasons:
>
>> A guess: people did not want sizeof(float) != sizeof(float). float
>> is cerainly faster than double.
>
> Now, only in cache footprint. All your std operations take the same amount
> of cycles DP vs. SP. Excepting for cache footprint latency:: perf(DP) ==
> perf(SP)
>

That's true - except when it is not.

It is not true when you are using vector instructions, and you can do
twice as many SP instructions as DP instructions in the same register
and instruction.

It is not true when you are using accelerators of various kinds, such as
graphics card processors.

And it is not true on smaller processors, such as in the embedded world.
On microcontrollers with floating point hardware for single and double
precision, SP can be up to twice as fast as DP. And for many of the
more popular microcontrollers, you can have hardware SP but DP is done
in software - the difference there is clearly massive.

But for big processors doing non-vector adds and multiplies, DP and SP
are usually equal in clock cycles (other than memory and cache effects).

On 24/02/2024 11:32, Anton Ertl wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>> The take-home learning should be that in a range-based loop, the range=20
>> endpoints and the loop variable all needs to be of the same type.
>
> The sext/zext examples <2024Feb20.130029@mips.complang.tuwien.ac.at>
> use the same type for the loop variable and the endpoints, and the
> unsigned case is still bigger than the int -fwrapv case, and that is
> bigger than the (u)intptr_t case.
>
> The actual takeaway lesson is to always use a full-width type, which
> avoids the need for extending a sub-width type to full width.
>
> Of course, if you are a compiler supremacist like David Brown, you use
> a type like int (without -fwrapv or the like) that gives few
> guarantees, and hope that the compiler manages to convert the lack of
> guarantees into code that is as efficient as what you get when using
> the full-width type; in the sext example that works, but I would not
> rely on it.

If by "compiler supremacist" you mean "someone who tries their best to
understand the language and the tools", then us "compiler supremacists"
know that you have a great deal of guarantees about "int". We also know
that you have few absolute guarantees about performance and exact code
generation for any types - you only have guarantees about observable
behaviour.

So you need to use types (or options) that first and foremost guarantee
the /behaviour/ of your code will be correct according to your needs.
And if you need the best efficiency, you have to look at generated code,
and measure the results, and try out different combinations of source
code and compiler flags. Rough rules can help - such as making sure the
compiler knows you won't have wrapping or overflow (so use "int" or big
types) - but never guarantee performance.

On 24/02/2024 19:48, MitchAlsup1 wrote:
> 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 am not convinced there should be a default type at all.

But like it or not, "int" is the nearest C has to a default type. It is
the type for things like integer constants. That does not mean it's the
type you should choose for everything, but it will turn up very often.

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

I don't like the way C handles this, and choose compiler warnings to
tell me if I am doing it accidentally. If you don't know the C rules
here, or are not careful about your types, then mixing signed and
unsigned types is going to be unsafe no matter what types you pick -
because by definition, if you have mixing, then you have a signed and an
unsigned type involved. The safe thing is to stick to either all
signed, or all unsigned - then there is no mixing.

David Brown <david.brown@hesbynett.no> schrieb:
> On 24/02/2024 19:48, MitchAlsup1 wrote:
>> 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 am not convinced there should be a default type at all.

Fortan has a default integer and a default real, and a default
double precision.

These days (since 1991, so it's been longer than most programming
languages exist) it has a KIND mechanism. For example, if you need
at least 12 significant digits, you can write

integer, parameter :: wp = selected_real_kind(12)

to declare a number wp which you can then use in the declaration
of a real variable, such as

real(wp) :: a, b, c

and can use to suffix to constants:

a = 1.2_wp

Same mechanism for integers.

Later revisions also included a 32-bit and a 64-bit types
from an intrinsic module.

Same as in C with int: INTEGER is what you use if you don't really
care about. There is a restriction that Fortran's default integer
has at least five digits, so 17 bits plus signed. PDP-11 ints would
no longer be conforming, I'm afraid :-)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>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

Calling it a "problem" is overstating the case. It was
straightforward enough, if not completely portable to
use the appropriate number of 'l' modifiers.

>were no corresponding length modifiers for those types in
>printf() format conversions (corrected in C99).

According to Anton Ertl <anton@mips.complang.tuwien.ac.at>:
>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.

These details are better found from the original references. Here's
the S/390 reference: https://publibfp.dhe.ibm.com/epubs/pdf/dz9ar008.pdf

And here's a link to the zSeries reference: https://www.ibm.com/support/pages/zarchitecture-principles-operation
You need an IBM account to download it, but signing up is easy.

What Wikipedia says is right, with the detail that the 390
instructions only exist in 390 mode on a z. Those "G" instructions
have 64 bit operands and make no sense in 390 mode.

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

Not necessarily. From S/360->370->390 most of the new instructions
were to deal with the address expansion kludges, the I/O system, and
IEEE floating point, with only a handful of general instructions like
CHECKSUM to speed up TCP/IP. In z/Series they made a complete u-turn
and added gazillions of new instructions. Some were to add 64 bit
versions of 32 bit instructions, some to fill well known gaps like
relative branches and longer offsets in memory references, but there
is a whole lot of stuff that seems to make some customer's workload a
little faster, such as a gzip accelerator and the fixed point decimal
vector facility.

z/Series uses what they call Millicode, microcode that uses the
hardware implemented part of the same instruction set, so the cost of
adding lots of new instructions is now low. They only backported a few
instructions into S/390 which suggests someone really wanted the carry
stuff.

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

On 24/02/2024 21:57, Anton Ertl wrote:
> 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".

OK. I am not convinced that "char, short, long short, int, long" would
be that much better than "char, short short, short, int, long",
especially when "long long" is added to the end, but either would do.

(There was an April Fool's proposal for the C standards with a method of
mixing "long" and "short" qualifiers to get any size of integer you
like. I haven't been able to find it, but I'd be very grateful if
anyone has a link.)

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

They could have done that, yes.

>
>> I saw benchmarks showing x32 being measurably faster,
>
> Sure, it's measurably faster. That's obviously not sufficient for
> incurring the cost of x32.
>

Agreed.

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

But other caches have got bigger, and buses between the caches have got
wider (have they not?).

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

For ARM, you are more likely to get away with saying "you need to
re-compile your old code to run on this new system". In the x86 world,
especially for Windows, that's a non-starter. An x86-64 processor that
couldn't run x86-32 binaries would not sell well.

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

Oh, I think you often have a good idea about the size. However, I quite
agree that if you don't know, you have to pick the biggest practical size.

(And either way, you will want to do some checking and sanitizing of
your data when it comes in.)

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

This is 2024. No one cares about BCPL or B. No one even cares about
how people wrote C before I32LP64 systems were common. The "int" of C
is "int" - that's what almost all C programmers use when they don't have
a good reason for picking something else, or when they simply don't
think about it. You might not like that (and I would certainly prefer
that more programmers thought more about their types), but that's the
reality.

When I am writing C, if I want a type that represents the size of an
unknown object, I use "size_t" - because that is the type used by the C
standards and by C code. I couldn't care less what types BCPL used. I
couldn't care less what types were used in C programming before the
"sizeof" operator gave a value of type "size_t", or before standard
library functions like "memcpy" used parameters of type "size_t".

If I want an unsigned type that can hold up to 64 bits, I use
"uint64_t". If I want a type that will hold a pointer converted to an
integer type, I use "uintptr_t".

I fully appreciate that you prefer to use unsigned types for
general-purpose variables or loop indexes, and I fully appreciate you
want them to be 64-bit for the systems you target. But I don't
understand why you want to call it "uintptr_t".

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

Forth always uses 16-bit cells, if I remember correctly? (It is a
/very/ long time since I have tried writing anything in Forth, and that
was on 8-bit systems.) If you want fixed size types, why not use them
in C? "int32_t" is the same size in every C implementation.

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

That would be a case where you don't know the range you need in absolute
terms, but you know them in C terms - the type to use is "size_t".

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

David Brown wrote:

> On 24/02/2024 21:57, Anton Ertl wrote:
>>
>> 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"?

> They could have done that, yes.

>>
>>> I saw benchmarks showing x32 being measurably faster,
>>
>> Sure, it's measurably faster. That's obviously not sufficient for
>> incurring the cost of x32.
>>

> Agreed.

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

> But other caches have got bigger, and buses between the caches have got
> wider (have they not?).

Yes, Opteron busses (HT) started out as 64-bits/cycle and many processors
are now spotting busses of ½ cache line width per cycle.

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

> For ARM, you are more likely to get away with saying "you need to
> re-compile your old code to run on this new system". In the x86 world,
> especially for Windows, that's a non-starter. An x86-64 processor that
> couldn't run x86-32 binaries would not sell well.

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

How about size_t ??

> Oh, I think you often have a good idea about the size. However, I quite
> agree that if you don't know, you have to pick the biggest practical size.

We are in the era (now) where the size of individual datums is irrelevant,
only the size of agglomerations of data have relevant sizes (array, struct).
int i; signed long j; are irrelevant in terms of memory bandwidth after
caching.

> (And either way, you will want to do some checking and sanitizing of
> your data when it comes in.)

---------------------

On 25/02/2024 23:32, MitchAlsup1 wrote:
> David Brown wrote:
>
>> On 24/02/2024 21:57, Anton Ertl wrote:

>>>>>> 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?
>
> How about size_t ??

Sure. That's often the appropriate choice when an object represents the
size of something, or the number of elements in an array of completely
unknown size.

>
>> Oh, I think you often have a good idea about the size.  However, I
>> quite agree that if you don't know, you have to pick the biggest
>> practical size.
>
> We are in the era (now) where the size of individual datums is irrelevant,
> only the size of agglomerations of data have relevant sizes (array,
> struct).
> int i; signed long j; are irrelevant in terms of memory bandwidth after
> caching.
>

For individual local variables, you are right (except for
microcontrollers, where it still matters a little - though not nearly as
much as it used to). It's only for storage or calculations with
aggregate data that size matters. And ironically we are now in an era
where small sizes, such as 16-bit floats, are more popular than ever before.

MitchAlsup1 <mitchalsup@aol.com> schrieb:
> Thomas Koenig wrote:
>
>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>> I know no implementation of a 64-bit architecture where ALU operations
>>> (except maybe division where present) is slower in 64 bits than in 32
>>> bits. I would have chosen ILP64 at the time, so I can only guess at
>>> their reasons:
>
>> A guess: people did not want sizeof(float) != sizeof(float). float
>> is cerainly faster than double.
>
> Now, only in cache footprint. All your std operations take the same amount
> of cycles DP vs. SP. Excepting for cache footprint latency::
> perf(DP) == perf(SP)

Latency, I of course belive you.

Throughput... For 32 vs. 64 bit reals, I would assume that the
area for a unit is about twice as big for the 64-bit version.

You can then calculate twice the number of results for a similar effort.

Hm. AVX-512 can do calculations either on 32 16-bit, 16 32-bit or 8
64-bit reals. Does anybody how they implemented their floating point
units - are they separate for each precision, or do they use some clever
(or horrible) way to use a single unit for all three?

Thomas Koenig wrote:

> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>> Thomas Koenig wrote:
>>
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>> I know no implementation of a 64-bit architecture where ALU operations
>>>> (except maybe division where present) is slower in 64 bits than in 32
>>>> bits. I would have chosen ILP64 at the time, so I can only guess at
>>>> their reasons:
>>
>>> A guess: people did not want sizeof(float) != sizeof(float). float
>>> is cerainly faster than double.
>>
>> Now, only in cache footprint. All your std operations take the same amount
>> of cycles DP vs. SP. Excepting for cache footprint latency::
>> perf(DP) == perf(SP)

> Latency, I of course belive you.

> Throughput... For 32 vs. 64 bit reals, I would assume that the
> area for a unit is about twice as big for the 64-bit version.

> You can then calculate twice the number of results for a similar effort.

An FMAC that can do 1×DP or 2×SP is 15%-20% larger than an FMAC that can
only do 1×DP or 1×SP. {For those interested, it if the Augend element
and the long adder (168-bits) that are clever and horrible at the same
time enabling 2×SP.}

> Hm. AVX-512 can do calculations either on 32 16-bit, 16 32-bit or 8
> 64-bit reals. Does anybody how they implemented their floating point
> units - are they separate for each precision, or do they use some clever
> (or horrible) way to use a single unit for all three?

Think:: Clever and horrible at the same time.

Tim Rentsch wrote:
> 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

I am not _sure_ but I believe Rust will in fact verify that all such
casts are in fact legal, i.e. the data will fit in the target container.

This is of course the total opposite of the C "nuclear option", and much
more like other languages that try to be secure by default.

> 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.
>
I agree, it Rust did it like C, then it would be very unsafe indeed.

I have not checked the generated asm, but I believe that if I write code
like this:

// x:u64
x = 0x1234567890abcdef;
let y:u8 = (x & 255) as u8;

the compiler will see the mask and realize that the conversion is safe,
so no need to interpose a

cmp x,256
jae trp_conversion

idiom.

OTOH, I have seen C compilers that insist on such a test at the end of a
fully saturated switch statement, even when the mask in front should
prove that no other values are possible.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Tim Rentsch wrote:
> 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. :/
>
Your floating point method is pretty bad, imho, since it can give you
both false negatives and false positives, with no way to know for sure,
except doing it all over again.

If I really had to write a 64x64->128 MUL, with no widening MUL or MULH
which returns the high half, then I would punt and do it using 32-bit
parts (all variables are u64):

p3 = (a >> 32) * (b >> 32);
p2 = (a & 0xffffffff) * (b >> 32);
p1 = (a >> 32) * (b & 0xffffffff);
p0 = (a & 0xffffffff) * (b & 0xffffffff);

// Middle sum, can give a 1 carry into high half
p12 = (p0 >> 32) + (p1 & 0xffffffff) + (p2 & 0xffffffff);

prod = (p0 & 0xffffffff) + (p12 << 32); // Final low word result

prod_hi = p3 + (p2 >> 32) + (p1 >> 32) + (p01 >> 32);

if (prod_hi != 0) overflow();

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Thomas Koenig wrote:
> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>> Thomas Koenig wrote:
>>
>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>> I know no implementation of a 64-bit architecture where ALU operations
>>>> (except maybe division where present) is slower in 64 bits than in 32
>>>> bits. I would have chosen ILP64 at the time, so I can only guess at
>>>> their reasons:
>>
>>> A guess: people did not want sizeof(float) != sizeof(float). float
>>> is cerainly faster than double.
>>
>> Now, only in cache footprint. All your std operations take the same amount
>> of cycles DP vs. SP. Excepting for cache footprint latency::
>> perf(DP) == perf(SP)

FDIV float vs double is still quite often slightly faster, but not close
to 2 X faster even though the mantissa is only 24/53 as large.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen wrote:
> Tim Rentsch wrote:
>> 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
>
> I am not _sure_ but I believe Rust will in fact verify that all such
> casts are in fact legal, i.e. the data will fit in the target container.
>
> This is of course the total opposite of the C "nuclear option", and much
> more like other languages that try to be secure by default.

Just to make sure I spoke to our resident Rust guru, and he told me I
was wrong:

Rust does have conversion operators/functions for downsizing variables,
and they come with full validity checking, but using "s as u8" as I
suggested will generate exactly the same code as a C "(uint8_t) s"
idiom, i.e. no verification and no safety checks.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On Tue, 27 Feb 2024 13:50:43 +0100
Terje Mathisen <terje.mathisen@tmsw.no> wrote:

> Terje Mathisen wrote:
> > Tim Rentsch wrote:
> >> 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
> >
> > I am not _sure_ but I believe Rust will in fact verify that all
> > such casts are in fact legal, i.e. the data will fit in the target
> > container.
> >
> > This is of course the total opposite of the C "nuclear option", and
> > much more like other languages that try to be secure by default.
>
> Just to make sure I spoke to our resident Rust guru, and he told me I
> was wrong:
>
> Rust does have conversion operators/functions for downsizing
> variables, and they come with full validity checking, but using "s as
> u8" as I suggested will generate exactly the same code as a C
> "(uint8_t) s" idiom, i.e. no verification and no safety checks.
>
> Terje
>

Prettty much in spirit of Ada's Unchecked_Conversion construct, but with
less striking visual hint of doing something unusual and potentially
dangerous.

Terje Mathisen wrote:

> Thomas Koenig wrote:
>> MitchAlsup1 <mitchalsup@aol.com> schrieb:
>>> Thomas Koenig wrote:
>>>
>>>> Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>>>> I know no implementation of a 64-bit architecture where ALU operations
>>>>> (except maybe division where present) is slower in 64 bits than in 32
>>>>> bits. I would have chosen ILP64 at the time, so I can only guess at
>>>>> their reasons:
>>>
>>>> A guess: people did not want sizeof(float) != sizeof(float). float
>>>> is cerainly faster than double.
>>>
>>> Now, only in cache footprint. All your std operations take the same amount
>>> of cycles DP vs. SP. Excepting for cache footprint latency::
>>> perf(DP) == perf(SP)

> FDIV float vs double is still quite often slightly faster, but not close
> to 2 X faster even though the mantissa is only 24/53 as large.

DIV algorithms have the property that they double the number of accurate
bits each iteration. This holds for both Goldschmidt and Newton-Raphson.

So instead of 17 cycles DP FDIV one gets 15 cycle SP FDIV.

SRT based FDIV is a lot more linear in that doubling the bits requires
doubling of the iteration cycles.

> Terje

Michael S wrote:

> On Tue, 27 Feb 2024 13:50:43 +0100
> Terje Mathisen <terje.mathisen@tmsw.no> wrote:

>> Terje Mathisen wrote:
>> > Tim Rentsch wrote:
>> >> 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
>> >
>> > I am not _sure_ but I believe Rust will in fact verify that all
>> > such casts are in fact legal, i.e. the data will fit in the target
>> > container.
>> >
>> > This is of course the total opposite of the C "nuclear option", and
>> > much more like other languages that try to be secure by default.
>>
>> Just to make sure I spoke to our resident Rust guru, and he told me I
>> was wrong:
>>
>> Rust does have conversion operators/functions for downsizing
>> variables, and they come with full validity checking, but using "s as
>> u8" as I suggested will generate exactly the same code as a C
>> "(uint8_t) s" idiom, i.e. no verification and no safety checks.
>>
>> Terje
>>

> Prettty much in spirit of Ada's Unchecked_Conversion construct, but with
> less striking visual hint of doing something unusual and potentially
> dangerous.

No more dangerous than::

if( c >= 'A' and c <= 'Z' ) c -= 'A'-'a';

or

if( table[c] & CAPS ) c -='A'-'a';

mitchalsup@aol.com (MitchAlsup1) writes:
>Michael S wrote:
>
>> On Tue, 27 Feb 2024 13:50:43 +0100
>> Terje Mathisen <terje.mathisen@tmsw.no> wrote:
>
>>> Terje Mathisen wrote:
>>> > Tim Rentsch wrote:
>>> >> 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
>>> >
>>> > I am not _sure_ but I believe Rust will in fact verify that all
>>> > such casts are in fact legal, i.e. the data will fit in the target
>>> > container.
>>> >
>>> > This is of course the total opposite of the C "nuclear option", and
>>> > much more like other languages that try to be secure by default.
>>>
>>> Just to make sure I spoke to our resident Rust guru, and he told me I
>>> was wrong:
>>>
>>> Rust does have conversion operators/functions for downsizing
>>> variables, and they come with full validity checking, but using "s as
>>> u8" as I suggested will generate exactly the same code as a C
>>> "(uint8_t) s" idiom, i.e. no verification and no safety checks.
>>>
>>> Terje
>>>
>
>> Prettty much in spirit of Ada's Unchecked_Conversion construct, but with
>> less striking visual hint of doing something unusual and potentially
>> dangerous.
>
>No more dangerous than::
>
> if( c >= 'A' and c <= 'Z' ) c -= 'A'-'a';

If your character set is EBCDIC, this isn't perfect, but since
the gaps are generally unassigned, may not cause problems in
practice.

For EBCDIC, it was sufficent to clear or set bit<6> to change case.

>
>or
>
> if( table[c] & CAPS ) c -='A'-'a';

Safer than the former.

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

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> 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
>
> Calling it a "problem" is overstating the case. It was
> straightforward enough, if not completely portable to
> use the appropriate number of 'l' modifiers.

Whether it is called a problem or not, the lack of support from
printf() was mentioned upthread (by OP?), and that's why I pointed it
out. The point is that not having the appropriate length modifiers
in C90 makes the code clumsy and the coding inconvenient. Focusing
on what word is used is a red herring.

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

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

I didn't say there is. So what else might I have meant by that
phrase?

> If you have widening multiplication in the language, things are
> trivial. [...]

Sure. If things were different they wouldn't be the same.

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

> Tim Rentsch wrote:
>
>> 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
>
> I am not _sure_ but I believe Rust will in fact verify that all such
> casts are in fact legal, i.e. the data will fit in the target
> container.
>
> This is of course the total opposite of the C "nuclear option", and
> much more like other languages that try to be secure by default.
>
>> 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.
>
> I agree, it Rust did it like C, then it would be very unsafe indeed.
>
> I have not checked the generated asm, but I believe that if I write
> code like this:
>
> // x:u64
> x = 0x1234567890abcdef;
> let y:u8 = (x & 255) as u8;
>
> the compiler will see the mask and realize that the conversion is
> safe, so no need to interpose a
>
> cmp x,256
> jae trp_conversion
>
> idiom.

Sounds like you and I are on the same page here.

> OTOH, I have seen C compilers that insist on such a test at the
> end of a fully saturated switch statement, even when the mask in
> front should prove that no other values are possible.

Yeah, what's up with that? Even worse, when each of the branches
has a return statement, sometimes there is a warning saying the
end of the function can be reached without returning a value.
That really annoys me.

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

> Terje Mathisen wrote:
>
>> Tim Rentsch wrote:
>>
>>> 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
>>
>> I am not _sure_ but I believe Rust will in fact verify that all such
>> casts are in fact legal, i.e. the data will fit in the target
>> container.
>>
>> This is of course the total opposite of the C "nuclear option", and
>> much more like other languages that try to be secure by default.
>
> Just to make sure I spoke to our resident Rust guru, and he told me I
> was wrong:
>
> Rust does have conversion operators/functions for downsizing
> variables, and they come with full validity checking, but using "s as
> u8" as I suggested will generate exactly the same code as a C
> "(uint8_t) s" idiom, i.e. no verification and no safety checks.

Perfect. ;)

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

> Tim Rentsch wrote:
>
>> 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. :/
>
> Your floating point method is pretty bad, imho, since it can give
> you both false negatives and false positives, with no way to know
> for sure, except doing it all over again.

I think you misunderstood what I was suggesting. The initial
tests using floating point don't produce any false positives or
false negatives. They may give a lot of "not sure" cases, but
none of the other cases is ever wrong. It is only the "not sure"
cases that need further investigation. If the FP multiplication
is done using long double (10 byte IEEE), I'm pretty sure the
results are essentially perfect with respect to a 64x64 multiply;
that is, there are very few "not sure" cases, perhaps even zero.

> If I really had to write a 64x64->128 MUL, with no widening MUL or
> MULH which returns the high half, then I would punt and do it using
> 32-bit parts (all variables are u64): [...]

I wrote some code along the same lines. A difference is you
are considering unsigned multiplication, and I am considering
signed multiplication.