From: bc@freeuk.com   
      
   On 27/11/2025 10:43, David Brown wrote:   
   > On 26/11/2025 23:19, bart wrote:   
      
      
   > What I don't like about your bit extraction operations is that you have   
   > an operator syntax for a fairly obscure and rarely used operation.   
      
   So shift and masking operations in C are obscure?!   
      
      A   
   > "bit_range_extract" standard library function would make more sense to   
   > me, though I think shifting and masking works well enough for the few   
   > situations where you need it.  A syntax that looks very much like array   
   > access is not going to be helpful to people looking at the code - for   
   > general-purpose languages, most programmers will never see or use bit   
   > ranges.   
      
   The syntax actually comes from DEC Algol60 IIRC. It was used to access   
   individual characters of a string, normally an indivisible type in that   
   language, and I applied the same concept to bits of an integer.   
      
   >> How much more fundamental can you get?   
   >   
   > It is not fundamental for a low-level systems language.   
      
   So bits are not fundamental either! But then, it has taken until C23 to   
   standardise binary literals, and there is still no format code for   
   binary output.   
      
   >>>   But the people who write those are few, and they know what they are   
   >>> doing.)   
   >>   
   >> And I don't? I used to write FP emulation routines...   
   >>   
   >   
   > The thing you always seem to forget, is that your languages are written   
   > for /you/ - no one else.  It doesn't make a difference whether something   
   > is added /to/ the language or written in code /for/ the language.  You   
   > think other languages are missing critical features simply because there   
   > is a thing that /you/ want to do that you added to your own language.   
   > And you think other languages are overly complex or bloated because they   
   > have features that you don't want to use.   
      
   They frequently have advanced features while ignoring the basics.   
      
   > Imagine asking the regulars in this group what features or changes they   
   > would like C to have in order to make C "perfect" for their uses,   
   > regardless of everyone else, all existing code, all existing tools.  We   
   > could all fill pages with ideas.  And if those were all added to C, the   
   > result would be a language that made C++ look as easy as Logo, while   
   > being riddled with inconsistencies and contradictions.   
      
   Yes, that's the trick. That's why a lot of features I've played with   
   have disappeared, while some have proved indispensable.   
      
   >> As it is, somebody using C as an intermediate language can have a   
   >> situation where something is well-defined in their source language,   
   >> known to be well-defined on their platforms of interest, but   
   >> inbetween, C says otherwise.)   
   >   
   > You've never really understood how languages are defined, have you? With   
   > your own languages and tools, you don't have to - there is no need for   
   > standards, specifications, or anything like that.  You can just make up   
   > what suits you at the time.  The language is "defined" by what the   
   > implementation does.  That's been very convenient for you, but it has   
   > left you with serious misconceptions about how non-personal languages work.   
      
   Here's a  program in a very simple language, where all variables have   
   i64 type:   
      
      c = a + b   
      
   Here, the author has decreed that any overflow in this addition will   
   wrap (any overflow bits above 64 are lost). If directly compiled to x64   
   code it might use this (here 'a b c' are aliases for the registers where   
   they reside):   
      
        mov c, a   
        add c, b   
      
   Or on ARM64:   
      
        add c, a, b   
      
   Now, the author decides to use intermediate C (for portability, for   
   optimisations etc), and will generate perhaps:   
      
        int64_t a, b, c;   
        ...   
        c = a + b;   
      
   But here, if a + b happens to overflow, it is UB, and for no good   
   reason. You have to fix it. This is where it can be harder to generate   
   HLL code than assembly!   
      
   *Now* do you understand? This is nothing to do with me or my personal   
   languages, it is a problem for every language that transpiles to C,   
   where there is a mismatch between the sets of behaviour considered UB in   
   each.   
      
   >> OK, so how would you do a 'reinterpret' cast in C, of a value like 'x+y'?   
   >   
   > As you know, you use a union.  So just to please you, here is your bit   
   > extraction - written as a one-line function (split over two lines for   
   > Usenet) because you seem to think that kind of thing is important :   
   >   
   > uint64_t get_exponent(double x) {   
   >      return ((union { double d; uint64_t u;}) { x }.u >> 52)   
   >               & ((1ull << (62 - 52 + 1)) - 1);   
   > }   
   >   
   > That compiles (with gcc on x86-64) to :   
   >   
   >      movq rax, xmm0   
   >      shr rax, 52   
   >      and eax, 2047   
   >      ret   
   >   
   > There's nothing in C that suggests this must be put in memory or do   
   > anything more than this.   
      
   (This only seems to work with gcc. Clang and MSVS don't like it.)   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)