From: none@invalid.com   
      
   On 01/09/2024 11:53, Ahem A Rivet's Shot wrote:   
   > On Sun, 1 Sep 2024 11:07:17 +0100   
   > mm0fmf  wrote:   
   >   
   >> On 01/09/2024 08:50, Lawrence D'Oliveiro wrote:   
   >>> On Thu, 29 Aug 2024 21:33:28 +0100, druck wrote:   
   >>>   
   >>>> Yes stdint.h is your friend   
   >>>   
   >>> Unless you have an elderly code base that still hasn’t caught up with   
   >>> C99 ...   
   >>   
   >> Or you were programming in C on an Analog Devices SHARC were char was 32   
   >> bits.   
   >   
   > 	I'll bet that broke a lot of bad code :)   
   >   
   > 	Stll even in that environment a compliant compiler should still   
   > provide int_t types. They'd probably have to have horrendously   
   > inefficient implementations not dissimilar to the bitfields in structs but   
   > they should exist. Woe betide anyone who thought they could put a char into   
   > an int16_t safely though.   
   >   
   ISTR the compiler was a custom version of gcc 1.xx. 26 years ago so the   
   exact version has evaporated from my memory. The compiler did understand   
   the hardware funnies well, floats were 32bits or 40bits, it understood   
   the zero overhead loops and circular buffer support. But all the fixed   
   point multiply and accumulate stuff we did in inline assembler. All the   
   performance stuff was in hand optimised assembler as you could do a DMA   
   in, integer operation, multiply&accumulate, float operation and a DMA   
   out all the in one cycle. There was dual access on chip RAM too, you   
   could read and then write the same location in the same clock cycle.   
      
   Careful programming meant you could get quite amazing levels of DSP   
   processing run on what was only a 66MHz device.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)