From: bc@freeuk.com   
      
   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).   
      
   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.   
      
   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)