From: bc@freeuk.com   
      
   On 10/10/2025 02:54, Kaz Kylheku wrote:   
   > On 2025-10-10, bart  wrote:   
   >> On 09/10/2025 04:49, BGB wrote:   
   >>> On 10/8/2025 2:04 PM, Janis Papanagnou wrote:   
   >>>> On 08.10.2025 19:29, BGB wrote:   
   >>   
   >>> Though, similar was often a problem in my other language design   
   >>> attempts: The most efficient way to do things was often also the C way.   
   >>>   
   >>>   
   >>>   
   >>> The only real exception I have found to this rule basically being in   
   >>> relation to some features I have borrowed from languages like GLSL and   
   >>> Verilog. But, some of this stuff isn't so much making the language   
   >>> "higher level" as much as "being easier to map to ISA features and   
   >>> optimize".   
   >>>   
   >>> Say:   
   >>>     vd[62:52]=vs[20:10];   
   >>> Being easier to optimize than, say:   
   >>>     vd=(vd&(~(2047ULL<<52)))|(((vs>>10)&2047ULL)<<52);   
   >>   
   >> Using special bit-features makes it easier to generate decent code for a   
   >> simple compiler.   
   >>   
   >> But gcc for example has no trouble optimising that masking/shifting version.   
   >>   
   >> (It can do it in four x64 instructions, whereas I need nine working from   
   >> vd.[62..52] := vs.[20..10]. It could be improved though; I don't need to   
   >> extract the data to bits 10..0 first for example.)   
   >>   
   >> The main advantage is that it is a LOT easier to write, read and   
   >> understand. The C would need macros to make it practical.   
   >   
   > I'm skeptical that the C macro system is powerful enough to actually   
   > create an operand like   
   >   
   >    bits(vd, 52, 62)   
   >   
   > such that this constitutes an lvalue that can be assigned,   
   > such that those range of bits will receive the value.   
      
   > The closest C mechanism to that is the bitfield, which has   
   > compartments decided at compile-time.   
   >   
   > What if 52 and 62 could be variables?   
      
      
   You wouldn't write the macros like that. There'd be Get/Set versions,   
   and probably separate versions for individual bits and bitfields.   
      
   The Set ones wouldn't take a reference either, but lvalues only.   
      
   So the example might become:   
      
       vd = SETBF(vd, 52, 62, GETBF(vs, 10, 20));   
      
   You'd need to decide on which order indices are in. In my version, I can   
   do A.[0..7] or A.[7..0] if the values are constants (the compiler will   
   reorder), or are implemented by function (it will have code to swap if   
   needed).   
      
   But if the choice isn't there, I decided they would be ordered like   
   conventional array indices and range syntax, so increasing LTR. Even   
   though bit indices normally increase RTL.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)