Trust about D programming.

Freddie Chopin freddie_chopin at op.pl
Tue Jan 22 10:33:16 PST 2013


On Tuesday, 22 January 2013 at 18:14:30 UTC, Paulo Pinto wrote:
> If I am not mistaken, many of the C compilers for such 
> environments are limited on what is actually possible to use 
> from ANSI C.

 From what I've heard D is 32- and 64-bits only, so that actually 
leaves things like ARM, MIPS, AVR32 and such cores, these usually 
have really good GCC support, so I guess there are no "special" 
limits... It also depends on what you mean by "ANSI C" - for 
example for ARM, GCC and newlib's libc you basically have 
everything [; Things that are "OS-dependent" - like malloc(), 
stdio functions (printf(), ...) and stuff like that require you 
to provide "re-targeting syscalls" (like sbrk(), write(), read(), 
...) but that's not a big issue [;

You basically have whole libstdc++ too (from GCC), with all the 
templates, containers, iterators and stuff, plus typical C++ 
stuff - exceptions, RTTI, new, delete etc. - some of these things 
depend on the syscalls I mentioned above, some of these features 
take just too much memory [;

So I guess that 32-bit microcontrollers are really 
standards-compliant! (;

> True, although in my naïve opinion, I would expect such systems 
> to still be developed in Assembly.

Do you mean controllers for 100-tonne crane of maybe just 
"general embedded microcontroller"? I guess that no one would go 
so low for things that can be done in C with a cheap chip like 
Cortex-M0 [;

> Faire enough, I guess even C has issues on those systems right?

If we stick to ARM (like Cortex-M3) there are no issues other 
than memory limitations, and it generally concerns mostly RAM, as 
code memory is usually big enough (hundreds of kB usually, up to 
512kB, sometimes 1MB). That's why you cannot get too fancy with 
your code, and - unfortunately - most of nice programming 
"tricks" are dynamic-memory-only...

On the other hand, maybe I should ask what do you consider "an 
issue"? There's definitely nothing "non-standard" in the C/C++ 
that you use here - there's just no OS (but you can have an RTOS 
- scheduler), no POSIX (but there are POSIX-like RTOSes) and 
not-a-lot of RAM (there's no library for fixing that [; ).

4\/3!!


More information about the Digitalmars-d mailing list