From: bc@freeuk.com   
      
   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.   
      
      
   >> 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!   
      
   > 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.   
      
   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 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.   
      
   >> 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.   
      
   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).   
      
   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.   
      
   >> 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.   
      
   (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!).   
      
   While with my decimal big-number library, all numbers are signed so the   
   issue doesn't come up at all.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)