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,252 of 243,242   
   Michael S to Waldek Hebisch   
   Re: _BitInt(N)   
   30 Nov 25 11:22:08   
   
   From: already5chosen@yahoo.com   
      
   On Sun, 30 Nov 2025 01:51:47 -0000 (UTC)   
   antispam@fricas.org (Waldek Hebisch) wrote:   
      
   > Philipp Klaus Krause  wrote:   
   > > Am 24.11.25 um 15:21 schrieb bart:     
   > >>>> I had been responding to the claim that those smaller types save   
   > >>>> memory, compared to using sizes 8/16/32 bits which are commonly   
   > >>>> available and have better hardware support.     
   > >>>   
   > >>> I don't recall any such claim.  Do you have a citation (other than   
   > >>> the FPGA-specific wording in N2709)?     
   > >>    
   > >> This is where it came up in this thread:   
   > >>    
   > >> On 23/11/2025 11:46, Philipp Klaus Krause wrote:     
   > >>  > Am 22.10.25 um 14:45 schrieb Thiago Adams:     
   > >>  >>   
   > >>  >>   
   > >>  >> Is anyone using or planning to use this new C23 feature?   
   > >>  >> What could be the motivation?   
   > >>  >>   
   > >>  >>     
   > >>  >   
   > >>  > Saving memory by using the smallest multiple-of-8 N that will   
   > >>  > do. Also being able to use bit-fields wider than int.   
   > >>  >   
   > >>  > Saving memory for two reasons:   
   > >>  >   
   > >>  > * On small embedded systems where there is very little memory   
   > >>  > * For code that needs to be very fast on big systems to make   
   > >>  > data structures fit into cache   
   > >>  >     
   > >>    
   > >> Although this doesn't go as far as using odd bit-sizes: it would   
   > >> mean using sizes like 24, 40, 48, and 56 bits instead of 32 or 64   
   > >> bits.   
   > >>    
   > >> The savings would be sparse.   
   > >>    
   > >>      
   > >    
   > > "On small embedded systems" - those tend to be 8-bit systems, so    
   > > compilers targeting them would only round up to multiple of 8, i.e.   
   > > a BitInt(40) is exactly 5 bytes. Also "bit-fields wider than int" -   
   > > for bit-fields it can indeed make sense to have a width that is not   
   > > a multiple of 8, if the remaining bits of the last byte can be used   
   > > for other purposes.     
   >    
   > I think it is better to say "8-bit systems".  People here wrote   
   > that RPi Pico with its 256 kB RAM and megabytes of flash is small.   
   > I have CH32V003, 32-bit MCU which has 2 KB RAM and 16 kB flash,   
   > I would call it small.  MSP430 is 16-bit, and was available with   
   > some tiny RAM and 2 kB flash, I would say that most embedded   
   > systems (counting projects, not number chips/subsystems that were   
   > manufactured) is bigger.  Clearly 8-bit MCU-s are used in some   
   > high-volume projects, but now one can get relatively small   
   > 32-bit MCU-s and various statistics indicate that 32-bit   
   > MCU-s get more use than 8-bit ones.  So, claim that "small   
   > embedded systems tend to be 8-bit systems" is debatable.   
   >    
      
   I agree. What matters is the size of memory. In context of our   
   discussion - the size of writable RAM.    
   32-bit MCU with 16 or less KB of RAM in my book is small, even if it   
   happens to have 2MB of NOR Flash.   
      
   Besides, compactness of data can be important on not so small systems   
   as well. If my MCU have 128 KB of RAM and I want to keep a vectors with   
   40,000 24-bit elements then I certainly don't want each element to   
   occupy 4 bytes.   
      
   --- 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