inp/outp (was: Stroustrup's talk on C++0x)

[Ingo Oeser]

0ffh wrote:

> Ingo Oeser wrote:
>> Oh and some port i/o needs to slowed down, byte swapped, include
>> barriers. How should a intrinsic handle that?
> You normally use them as primitives and build more complex funs around.

My problem is, that this behavior isn't defined.

>> 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?
> 
> It can't and why should it?
> BTW not all architectures (and all modes) need any special enabling.

I know. I'm a system programmer, too :-)

>> Inline assembler functions are much more suited to that task.
> 
> I have to use inline asm every time?
> IIRC DMD doesn't inline funs with inline asm, so no good.

GDC does, so DMD might get it one day.
 
> Why throw it out just because "99% don't need it anyway"?
> It's there already, and some people are quite happy about it!
> 
> It does not in any way make DMD less usable for the "99%",
> so why do you insist on treading on the "1%" minority?

Because every D compiler HAS to implement it for every architecture.
And it has to fake it somehow on architectures, which don't have
port i/o. How to fake that correctly, is simply not defined 
(in contrast to IEEE FP math).

Making inline assembly better (e.g. giving the compiler more knowledge
about the instructions and their constraints, make it inlineable)
is the more useful goal. These compiler refinements then work for ALL 
instructions on EVERY architectures and may someday even be more powerful
than GCCs inline assembler syntax.

This will reduce X86ism in D. DMD can learn A LOT from GCC in that area.


Best Regards

Ingo Oeser