From: david.brown@hesbynett.no

On 01/12/2025 18:19, bart wrote:
> On 01/12/2025 15:24, David Brown wrote:
>> On 01/12/2025 15:41, bart wrote:
>
>> No, _BitInt's never use integer promotion.  Perhaps you mean that they
>> are included in the rules for "usual arithmetic conversions" ?  These
>> are different from the "integer promotion" rules.  One would think
>> that someone who claims to have implemented a C compiler would be
>> familiar with the types of implicit conversions required by the language.
>
> I implement C via an IL. The IL doesn't use any automatic promotions.
> There is only one instruction WIDEN to zero- or sign-extend any value.
>
> So I think in those terms.
>

It doesn't matter how you think.  What matters if you are making
something you can reasonably call a "C compiler", is that you implement
C as it is defined.  It's fair enough not to be entirely compliant to
the standards, but you need to get the basics right.

If you are implementing only a partial sort-of-C compiler, with a view
to acting as a limited tool for a specific close subset of C, then it's
fine to change or skip rules.  Perhaps your tool is never called upon to
do arithmetic on types that are not of size "int" or above, or perhaps
you actively decide to have different rules.  That's okay - but it would
be misleading to call it a "C compiler".


>
>>> My example was just to highlight the plethora of type denotations
>>> that exist, even for the same machine type. The rules for type-
>>> compatibility and promotions (and the ugly syntax) is just icing on top.
>>>
>>
>> C is not an abstraction for a processor.  It is a programming
>> language. It does not differentiate between types nearly as much as I
>> would like,
>
> It seems to be doing a good job!

Yes, C is a very successful and useful programming language.  Just
because /I/ would prefer a language that made greater distinction
between types, does not mean C would be better at its job if it did so.
Strong typing is not for everyone.

>
>> but it still does so more than an untyped language like assembly.
>
> There is type-specific stuff going on, but it's done via the choices of
> instruction.

We are talking about C, here in a C newsgroup.

>
> My IL supports the usual set of 8/16/32/64-bit-based types, and type-
> info is a separate attribute for each instruction.
>
> There is no direct provision for sub-byte/sub-word types, and the only
> type bigger than a word (putting aside a reserved set of vector types),
> is an anonymous data-block type, specified as so many bytes in size.
>
> So you can see how an arbitrary [unsigned] _BitInt(N) bit-precise type
> would be a poor fit, and a bit of a nightmare to implement on top. It's
> unnatural.
>

The thing you have to remember about implementations, is that nobody
really cares how hard it is to implement a particular C feature.  The C
standards folk care that it is /possible/ to implement it, not if it
happens to be easy or difficult for any particular compiler (especially
an obscure private sort-of-C compiler that is only used by one person).
They do provide some escape hatches for implementers who feel a
particular feature is too difficult to make for the amount of use it
would get from their users - a number of C features are optional, and
for _BitInt, you can limit the size to just 64 bits.

> The IL is designed to be one abstraction level higher than typical
> machine architectures, and you don't really want HLL-specific features
> in it.
>
> This is related to my remark about LLVM and its building-in of such
> types. But LLVM is some 3-4 magnitudes bigger in scale than what I do,
> and famously slow and cumbersome in operation.
>

The _BitInt feature is not designed arount LLVM.  You are mistaken in
believing so.  It took inspiration from clang's _ExtInt feature and how
it could be used, not how it was implemented.

>>> This ungainly way to evolve a language is how C works (just look at
>>> all the things wrong with how stdint.h types were handled).
>>>
>>> The following table for example shows the rules for mixed sign
>>> arithmetic: S means the result (32 or 64 bits) has signed type, and u
>>> means it is unsigned:
>>>
>>>         u8  u16 u32 u64  i8  i16 i32 i64
>
>> C programmers know that C does not have types of these names.
>
> Unforunately, if I'd used 'unsigned long long int' and so on, the chart
> becomes impossibly large.

The chart was pointless in the first place.

But if you want to have types like that in C, they are called "uint8_t",
etc.  You know this.  You only use these silly abbreviations for
provocation, so that you can yet again blather on about how some other
irrelevant language uses them and somehow feel smug about it all.

>
> While with 'uint64_t' etc, such types don't exist at all in C, unless a
> particular header is used (and they might still result in line-wrapping).

They exist in the C standard regardless of any headers, because the C
standard - the definition of the C language - is independent of any program.

>
> Fortunately I'm 100% certain that no one reading this is scratching
> their heads about what those types could possible mean.
>
>>   And I expect most C programmers figure things out using the very
>> simple and consistent rules of the language.
>
> The chart demonstratates a number of inconsistencies.
>

No, it does not - at least, not inconsistencies in C.  It may
demonstrate inconsistencies in your understanding and misunderstanding
of the language.

>>> Here, i8 + u8 gives a signed result; but 'unsigned _BitInt(8 ) +
>>> _Bitint(8)' apparently gives an unsigned result (tested using _Generic).
>>>
>>
>> Or you could learn the very simple rules, and then you would know
>> without testing.
>
> So you're not commenting on the fact that mixed 8-bit arithmetic has
> opposite signedness between existing types and _BitInt types.
>

No.  As I said, the rules are clear and simple.  Anyone so incapable of
learning that they have trouble with them, is likely to have a great
deal of difficulty doing much programming.

(And again, I point out that I do not think the C rules here are the
best options for a programming language.  But that is my personal
opinion, and it does not affect my ability to understand the rules and
write correct C code using them.)

> (My language also has rules, but the equivalent chart is simpler: every
> entry has 'S' except for u64/u64 (and I'm working on that!).
>

That would be an alternative set of rules that would also be easy to
learn.  And it would be, IMHO, at least as bad as C's choices.  There is

[continued in next message]

--- SoupGate-Win32 v1.05
 * Origin: you cannot sedate... all the things you hate (1:229/2)