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,496 of 243,242   
   bart to David Brown   
   Re: 8 bit cpu   
   20 Dec 25 16:19:40   
   
   From: bc@freeuk.com   
      
   On 19/12/2025 17:57, David Brown wrote:   
   > On 19/12/2025 17:05, bart wrote:   
      
   [Default size 'int' being 32 or 64 bits]   
      
   >> 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   
      
   Sure. Then you choose the smallest size that can represent all likely   
   values.   
      
   But if you don't know the range of values, would you just use 'int' and   
   hope nothing is outside the i32 range? Or would you use 64 bits?   
      
   If the latter, then a default i64 size (with a range /4 billion times   
   wider/ than i32) can make more sense.   
      
   > - 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.   
      
   One mild downside on x64 is the need for a 'REX' prefix on some   
   instructions that work on 64-bits (to set the 'W' bit). Unless the   
   instructions already use x64's 8 extra registers so the prefix is needed   
   anyway.   
      
      
      
   > 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.   
      
   Could the same assumptions have been made about 'long'? I guess was   
   'long' was 32 bits when 'int' was 16 bits, then when the latter became   
   32 bits, 'long' stayed the same...   
      
   ...until 64 bit machines came along. Then 'int' stayed the same, but   
   'long' became 64 bits - on some OSes but not others!   
      
   --- 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