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)