Lpc2000

--- In lpc2000@yahoogroups.com, "Bruce Paterson" 
<bruce.paterson@b...> wrote:
>
> > Texas Instruments 320C40 compiler had a 32-bit char, short, 
> > int, and long.  Yes, it was not a byte-oriented machine and 
> > much trouble with byte-oriented protocols ensued.
> 
> Or even less obvious the 24bit gnu based C compiler for the 
Motorola
> series of DSP's (5600x), char, short, int and long were all 24 
bits. To
> make things work properly using the same code on a test PC we had 
to
> ensure int-like variables were forced to be 32bits (rather than 
16bits),
> so it was lucky it could be all done in one file where my generic 
types
> were defined. 
> A situation like this does mean you should allow for a type that 
is the
> natural int of the machine as well as the specific types like 
int32_t.
> In most cases you probably don't want a 32bit counter on the PC to 
be
> forced into a double word 48bit on the DSP; for most purposes a 
24bit
> counter will do. I tend towards some global use types 
like "COUNTER" and
> "INDEX" that I set appropriately in the global types file, as well 
as
> min_no_of_bits types like INT32_T where you really do mean you need
> 32bits (or more).
> 
> Cheers,
> Bruce
>

Yes, as I get further into stdint.h I think is will clear up.  And, 
what about portability?  On these embedded things portability of the 
hardware specific code is not going to happen anyway.

It's just that my experience has been limited to 8 bit micros for 
far too long.

Richard