Stroustrup's talk on C++0x

[Ingo Oeser]

0ffh wrote:
> Ingo Oeser wrote [about port i/o]:
>> These are of course privileged operations and the compiler
>> doesn't actually know your privilege level. So this kind of intrinsic
>> is just nonsense. It is also non-sense in a standard library, since >99%
>> of all programs out there don't need to do that and the rest codes
>> it either in assembly or uses a special API for that.
> 
> I do not agree. I've been writing system level software on a number of
> architectures since more than 15 years, mostly in C, and of course these
> functions are used.

But they had quite different properties/semantics. You should have noticed,
that some architectures don't even have them and threat all IO as special
memory accesses.

E.g. "There exists no such thing as port-based I/O on AVR32"
and "The ARM doesn't have special IO access instructions".

Or "On MIPS I/O ports are memory mapped, so we access them using normal
load/store instructions"

Just to quote some random comments from include/asm-*/io.h from Linux.
Oh and some port i/o needs to slowed down, byte swapped, include barriers.
How should a intrinsic handle that?

> Also, I never even heard of any "special API" for port i/o, and wonder
> what such a thing might be needed for (unless your compiler is crippled).

I mean special API for ENABLING port i/o for your task. How does the
intrinsic know, whether you can actually DO port i/o in that task?

Inline assembler functions are much more suited to that task.
And how to do that in assembler is usually in the example collection 
of your system manual.

Even better is to threat that stuff as special memory and define
unified i/o memory accessors somehere in a library. That stuff
isn't fast anyway, so the class overhead might not be too significant
here, as long as it is bounded.


Best Regards

Ingo Oeser