home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.lang.c      Meh, in C you gotta define EVERYTHING      243,242 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 242,491 of 243,242   
   David Brown to bart   
   Re: 8 bit cpu   
   19 Dec 25 16:16:44   
   
   From: david.brown@hesbynett.no   
      
   On 19/12/2025 14:43, bart wrote:   
   > On 19/12/2025 08:19, David Brown wrote:   
   >> On 18/12/2025 19:20, Rosario19 wrote:   
   >>> 8 bit cpu for access memory other than 0..255 location has need at   
   >>> last one 16 bit register and 16 bits operations, so i think that even   
   >>> a 8 bit cpu has to have int in C language as 16 bits   
   >>   
   >> No, 8-bit cpus don't need 16-bit registers or 16-bit operations.   
   >> 8-bit cpus typically only have 8-bit general registers (though most   
   >> will have a 16-bit PC register).  Some will allow you to use a couple   
   >> of 8-bit registers in a pair, primarily for memory addressing, but a   
   >> pair of 8- bit registers is not the same as a 16-bit register.   
   >   
   >>   
   >> The C requirement for a minimum size of 16-bit int, together with the   
   >> integer promotion rules, is one of the reasons C was often considered   
   >> inefficient and inappropriate for small 8-bit microcontrollers.   
   >   
   >   
   > I'm targeting Z80 right now from my systems language.   
      
   The Z80 is actually one of those 8-bit cpus that could be called an   
   8/16-bit device - it has a lot of support for using register pairs BC,   
   DE, and HL as 16-bit registers, and IX and IY are already 16-bit.   
   (Ironically, the early versions used a 4-bit ALU with double-pumping.)   
      
   >   
   > As well as making 'int' 16 bits, I've removed the promotion rules. This   
   > means 8-bit quantities needing to be cast to 16 bits as needed.   
   >   
   > So if 'a b c' are 8 bits, and 'x' is 16 bits then the Clang Z80 compiler   
   > generates 8-bit code only for:   
   >   
   >      a = b + c;   
   >   
   > No promotions.   
      
   Technically, there /are/ promotions there - C requires them.  But C   
   compilers optimise with the "as-if" rules, and with the normal choices   
   of implementation-defined integer conversions the result of this kind of   
   operation is always going to be identical to a C-like language without   
   promotions.  (Or C with _BitInt(8) types for a, b, and c.)   
      
   In some C compilers for 8-bit devices, this kind of optimisation is done   
   fairly early in the pipeline, so that the addition here is interpreted   
   as though it were an unpromoted 8-bit operation.  In others, such as   
   avr-gcc, many such operations are given normal integer promotions and   
   then redundant operations and register moves are removed with peephole   
   optimisations at code generation.  That second approach makes the   
   implementation much easier as you don't need special handling at the   
   front-end or in the middle of the compiler, but it has the disadvantage   
   of being less efficient for register allocation and having occasional   
   extra instructions when the peepholes are not perfect.   
      
    >   
   > But here:   
   >   
   >      x = b + c;   
   >   
   > 'b' and 'c' are first widened to 16 bits (using some ugly code when they   
   > are signed).   
      
   Of course.  (8-bit devices are usually designed for primarily unsigned   
   data, and often don't have neat ways of handling or extending signed types.)   
      
   >   
   > This is where my language will differ: b + c produces an 8-bit result,   
   > and it is that that is widened.   
   >   
      
   Okay.  I think that is a better choice for a language for 8-bit devices   
   than the choice C made.  I understand the rules for C integer promotion,   
   but I don't like them.   
      
   > Casts are needed to emulate the behaviour of the auto-widening done in   
   > C. But this means somewhat more efficient code with a simpler compiler.   
      
   Yes.   
      
   Why are you targeting the Z80?  Is it just for fun?  It was a great   
   device in its time, and I learned a lot of assembly with that processor,   
   but has been decades since it was used for anything new.  While the   
   chips are still available, they are for legacy use - no one will be   
   writing new code for them, merely maintaining old code.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca