Re: ****tability: Harmony between PC and microcontroller

On May 6, 12:33=A0pm, Chris Dollin <chris.dol...@[EMAIL PROTECTED]
> wrote:

> That just means that those microcontrollers aren't a natural fit
> to C, so programmers writing looks-like-C for them need to be
> aware that natural-C idioms might not work as nicely.


This is what I'm against. When I first started programming in C for
embedded systems, I was weary of the compiler's compliance to the
Standard. I was hesitant to rely on rules from the Standard when it
came to things like:
    * Minimum size of integer types
    * Behaviour of overflow
    * Existance and usage of a stack

Having written a fully working program though in C for embedded
systems, and also having looked at the assembler produced to check
what it's actually doing, I've seen that my embedded compile is
extremely compliant. I defined an object as "long unsigned", and lo
and behold the assembler produced used four bytes to store it (even
though it can only do arithmetic on 8-Bit numbers).


> I don't see a problem here.


The problem comes with writing ****table code. For instance, I'm
currently writing code to implement an internet protocol router. The
code show be able to run on both a microcontroller and on a PC.
However, if the code uses "int" then the code will be less efficient
on a microcontroller. And if it uses "char" then the code will be less
efficient on a PC. Usage of uint_fast8_t would produce optimal
assembler for both systems.

There's no reason why there has to be an "embedded version of C"
distinct from "Standard C".