portable C, posix C and windows C

[Ian Collins]

How do you mean?

How would you access the peripherals on an MCU without hardware extensions?

If they are mapped into the processor's normal address space, it's a
non-issue. If not then you do have to use extensions, I'm not disputing
that. The issue wasn't the requirement for extensions, but whether they
speed up the code.

My point was hardware extensions tend to be used to enable the code to
do things that aren't part of standard C, like access extra address
spaces or peripheral registers. They tend not to be used for increased
performance.

Most compilers provide compiler options to increase performance on
specified targets (using multi-media instructions or extended registers
for example), but these apply to the compiler, not the source code.

 

[dj3vande]

My point was hardware extensions tend to be used to enable the code to
do things that aren't part of standard C, like access extra address
spaces or peripheral registers. They tend not to be used for increased
performance.

Counterexample: Crypto accelerators.
They work at too high a level to be used automagically by the compiler
at code-generation time (unless compilers are a *lot* smarter than I
think they are), and their entire purpose is to speed up operations
that could easily be done correctly (modulo deadlines) by fully
portable C code.

(I believe the canonical solution is to use a dynamically linked system
library and trust your vendor and/or sysadmin to be competent enough to
install a version of the library that supports any hardware that would
be useful for the purpose; but by relying on a system-provided library,
you've stepped outside the bounds of standard, fully portable C.)


dave

 

[Ian Collins]

Counterexample: Crypto accelerators.
They work at too high a level to be used automagically by the compiler
at code-generation time (unless compilers are a *lot* smarter than I
think they are), and their entire purpose is to speed up operations
that could easily be done correctly (modulo deadlines) by fully
portable C code.

True enough. One could also include packet filtering offload to NICs as
a common hardware extension.

But in both cases, the code using this hardware can be standard C. The
acceleration can be transparent to the client code.

(I believe the canonical solution is to use a dynamically linked system
library and trust your vendor and/or sysadmin to be competent enough to
install a version of the library that supports any hardware that would
be useful for the purpose; but by relying on a system-provided library,
you've stepped outside the bounds of standard, fully portable C.)

That all depends where you draw the "implementation" line. At least on
Solaris, crypto acceleration (if fitted) is provided by the OS environment.