From: david.brown@hesbynett.no   
      
   On 19/12/2025 17:05, bart wrote:   
   > On 19/12/2025 15:16, David Brown wrote:   
   >> On 19/12/2025 14:43, bart wrote:   
   >   
   >>> I'm targeting Z80 right now from my systems language.   
   >   
   >>> 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.   
   >   
   > I think it is a better choice for a capable processor, and I actually   
   > adopted C's approach at some point.   
   >   
   > Currently it works very well for my 64-bit product, but here C stops   
   > short at promoting only to 32 bits! (When 'int' is 32 bits.) So you have   
   > a mix of auto-promotion plus explicit casts to 64 bits.   
   >   
      
   I think making "int" 64-bit would have been a bad choice overall for C.   
      
   The key issue is that there is a conflict of uses and efficiency on   
   64-bit processors between "a type that is fast and convenient for local   
   use" and "a type that is big enough to handle most numbers, and fast and   
   efficient for storage".  Data in memory, especially in arrays, is more   
   efficient if it is smaller - 32-bit is still a good size for the   
   majority of numbers stored in memory.  For local variables in registers,   
   or even on the stack, 64-bit is more efficient on x86-64 as it avoids   
   the need of any kind of sign or zero extension or masking.   
      
   So ideally in C programming, you'd use "int_least32_t" for integers in   
   memory (unless you know they are small values in a big array, and pick   
   something smaller), while you'd use "int_fast32_t" (64-bit on x86-64)   
   for integers in local variables in functions.  But of course no one does   
   that for normal code - they use "int".  32-bit "int" is therefore good   
   in some ways and less than ideal in others.  However, given that such a   
   large proportion of code was written with the assumption that "int"   
   always means 32-bit, it made sense to keep it at 32-bit.   
      
      
   There are various ways of handling integer promotion rules - you can   
   have no promotion, use C-style promote-to-int, promote to the natural   
   width of the target, or promote based on what is being done with the   
   result.  Each method has its pros and cons.  The most important thing is   
   that the rules should be clear enough that programmers know what they   
   are getting, and that there are reasonable ways to modify the behaviour   
   as needed.   
      
   (There are other methods that can be used that involve more changes to   
   the structure of the language - Forth, for example, uses different   
   operators for word-sized operations and double-word operations.)   
      
   >>   
   >>> 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?   
   >   
   > Mostly, yes. My Z80 will be emulated, and I hadn't worked on an emulator   
   > before.   
   >   
      
   Fair enough.  That's always a good reason.  Nostalgia works too :-)   
      
   > Currently, emulated Z80 code runs at an equivalent clock-speed of 2-4GHz   
   > (for whole-instruction-based emulation; some emulate clock-by-clock and   
   > do pin-signals too).   
   >   
   > The original Z80s ranged from 2.5 to 8MHz. (Newer Z80-based CPUs take   
   > fewer clocks per instruction, and may use pipelining.)   
   >   
   > The other side of it is in exercising the IL I use for my compilers, and   
   > seeing how well it can cope with a small device. My product will be a   
   > cross-compiler, and it'll be a novelty seeing modern language features   
   > (lots don't depend on target capabilities) be used for such a device.   
   >   
   > (I wrote real Z80 compilers in the past; those actually ran on the Z80!   
   > But were crude.)   
   >   
   >>   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 stopped making Z80 chips in 2024 (you can still get Z180 etc). I've   
   > got one on my shelf somewhere (decades ago my company bought them in   
   > bulk!). I might get around to using it for real.   
   >   
      
   I have a ZX Spectrum in the loft somewhere, but I don't know if it is   
   still working.  It has the keyboard from a dead TI 99/4A transplanted in   
   place of the broken chewing gum original.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)