From: david.brown@hesbynett.no   
      
   On 01/12/2025 12:37, bart wrote:   
   > On 01/12/2025 07:36, David Brown wrote:   
   >> On 01/12/2025 02:32, Keith Thompson wrote:   
   >>> Michael S  writes:   
   >>> [...]   
   >>>> Now, if you ask me, I don't understand why Waldek Hebisch considers   
   >>>> difference between 8-bit and [byte-addressable] 16-bit targets   
   >>>> important. As far as size of relevant C types goes, they look the same:   
   >>>> char - 8 bits   
   >>>> int - 16 bit   
   >>>> long - 32 bits   
   >>>> There is possibly difference in the size of 'short', but I don't   
   >>>> understand why it matters.   
   >>>   
   >>> Given 16-bit int, short is almost certain to be 16 bits as well.   
   >>>   
   >>> char is requires to be at least 8 bits, short and int at least 16, and   
   >>> long at least 32 (and long long at least 64).   
   >>>   
   >>> Or is 8-bit short used in some non-conforming mode?   
   >>>   
   >>   
   >> Some C compilers for 8-bit devices have non-conforming modes with   
   >> 8-bit int.  (I've seen one that, by default, had 16-bit int but did   
   >> not promote 8-bit types to int for arithmetic.  That caused some   
   >> subtle problems for us.)  I don't know if SDCC has such a mode   
   >> (avr-gcc does).   
   >   
   > That sounds sensible to me. It's how my language for Z80 worked (and   
   > that carried on into x86 until I introduced promotions).   
      
   It is entirely sensible that a language designed for 8-bit devices   
   should have 8-bit types for key arithmetic use.  But we are not talking   
   about a language designed for 8-bit devices, or any other language, we   
   are talking about C.   
      
   C has its language rules for how arithmetical operators work.  You can   
   question the wisdom of the integer promotions rules in C - I know that   
   /I/ dislike some aspects of them.  But like them or not, that is how C   
   is defined.  And a compiler that calls itself a C compiler but does not   
   follow those rules is a broken tool that will cause unexpected problems   
   with perfectly good C code.  That is what I experienced with a   
   particular so-called C compiler for an 8051 - it was expensive and   
   pointlessly and dangerously non-conforming.   
      
   I'd be happy if C did not have integer promotions.  I'd be happy if it   
   did not have implicit conversions between signed and unsigned types (as   
   long as writing literals was still convenient) - or if conversions were   
   always value preserving.  But given the rules C has, I write my C code   
   to be correct according to those rules - and I expect C compilers to   
   implement according to those rules.   
      
   I'm also happy with extra flags to change the behaviour (though I would   
   often prefer pragmas, since those are tied tighter to the source code in   
   question).  If a compiler provides a "--ints-are-8-bit" or   
   "--no-integer-promotions" flag, that's fair enough.  But it should   
   follow the standard rules unless told otherwise.  (And yes, I /know/   
   that gcc does not follow all the rules of C by default and requires   
   explicit flags to be conforming - that's a mistake on gcc's part IMHO.)   
      
   >   
   > If performing arithmetic on two 8-bit variables, on a machine with poor   
   > 16-bit support, you don't want the inefficiency of promoting both to   
   > 16-bit (needing extra instructions), doing the operation at 16 bits   
   > (which may need extra instructions), and then probably discarding the   
   > high byte anyway.   
      
   I might not have been doing arithmetic on 8-bit systems /quite/ as long   
   as you have, but this is not news to me.   
      
   >   
   > There were some issues with that, that you had to be aware of:   
   >   
   >      byte a := 255   
   >      print a + 1   
   >   
   > This would show 0 not 256.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)