Yes i remember this.
I'm affraid i never take the time to test the macros.
In fact i was wondering if the rest of the code be aware of the use of
AX and DX, what about 16 bit to 32 bit convertions ?
If the code generation for outpw and inpw stays like it is now, i will
test them.
Just i will change it like this:

#define INPWX(port,x) \
{ \
    asm MOV DX, port \        //    MOV EDX,port    //faster in 32bit
model
    asm IN AX, DX \
    asm MOV x, AX \            //    what happen if x is 32 bit ?
}

#define OUTPWX(port,x) \
{ \
    asm MOV DX, port \      //    MOV EDX,port    //faster in 32bit
model
    asm MOV AX, x \          //    MOV EAX,x
    asm OUT DX, AX \
}

Thanks

Roland


Jan Knepper a écrit :

> I seem to remember that Rolands issue also was speed. He wanted to inline the
> code.
> I looked up an email I sent him some time ago that solved what he wanted to do
> through macro's...
>
> Roland, let us know if this is still correct!
>
>
> Jan
>
>
>
> Walter wrote:
>
> > How do you (and Roland) think they *should* work?
> >
> > John Culver wrote in message <9rcgm7$1qo6$1@digitaldaemon.com>...
> > >Yes,
> > >    I was confusing by the _inline_inpw naming style for the inline code,
> > and the fact
> > >they were being generated inline, and not really thinking that they were
> > not inline
> > >functions as such.
> > >
> > >    I did use #undef to remove inpw/outpw as a fix to dos.h
> > >
> > >    The other noticable error in my note is that there is no inline version
> > of the
> > >inpl/outpl code, so my stating that they are 32 bit is rather creative.
> > >
> > >
> > >JohnC
> > >
> > >"Walter" <walter@digitalmars.com> wrote in message news:9r9n8l$242v$2@digitaldaemon.com...
> > >> The -C switch is for inline functions, not compiler recognized ones. The official way to avoid the compiler recognized ones is to #undef them. But I'll check into the code gen inconsistency. -Walter
> > >>
> > >> John Culver wrote in message <9r9jop$20ac$1@digitaldaemon.com>...
> > >> >Hi,
> > >> >    Actually I think it's only the inline ones that do this, the
> > inpw/outpw
> > >> in the
> > >> >library (port.asm) contain (and generate) the more conventional forms of
> > :
> > >> >
> > >> >PORT.ASM        inp/outp        8 bits
> > >> >        "     w           16 bits
> > >> >        "    l            32 bits
> > >> >
> > >> >whereas INLINE generates :
> > >> >        inp/outp        8 bits
> > >> >        "     w           32 bits
> > >> >        "    l            32 bits
> > >> >
> > >> >   Making the code generated inconsistent. I was a little suprised that
> > >> the -C command
> > >> >line option did not remove these inlines. Personally I just hacked dos.h
> > to
> > >> loose the
> > >> >inline mapping for inpw and outpw to give a reasobale level of
> > >> predictability.
> > >> >
> > >> >
> > >> >
> > >> >John Culver
> > >> >
> > >> >"Walter" <walter@digitalmars.com> wrote in message news:9r81c3$8d7$1@digitaldaemon.com...
> > >> >> Ok, I'll fix the documentation! -Walter
> > >> >>
> > >> >> Roland wrote in message <3BD7029A.2BC5E3DD@ronetech.com>...
> > >> >> >hum..i mean
> > >> >> >
> > >> >> >inpw read 4 bytes instead of 2 and outpw writes 4 bytes instead of 2.
> > >> >> >
> > >> >> >sorry
> > >> >> >
> > >> >> >Rolland
> > >> >> >
> > >> >> >Roland a écrit :
> > >> >> >
> > >> >> >> since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4 and
> > outpw
> > >> >> >> writes 4 bytes instead of 4.
> > >> >> >> A long time ago I had a discussion with Walter about this.
> > >> >> >> Ok you prefer let it like that because you don't want to fix
> > something
> > >> >> >> that seems to work.
> > >> >> >> But you should put a warning.
> > >> >> >>
> > >> >> >> Regards
> > >> >> >>
> > >> >> >> Roland
> > >> >> >
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
>
>    ----------------------------------------------------------------
>
> Objet: outpw, inpw
> Date: Wed, 03 May 2000 18:45:09 -0400
> De: Jan Knepper <jan@smartsoft.cc>
> Société: Smartsoft, LLC
> A: Roland <rv@ronetech.com>, Symantec-C@onelist.com
>
> éférences: <390CABD5.DE4BF96@smartsoft.cc> <3910A37F.C05A3EBA@ronetech.com>
>
> Actually... Walter agrees with the fact that outpw and inpw should both do a 16 bit out/in. However, since both functions have been implemented as 32 bits for such a lot time he is afraid to break code of others that have used the functions as they are with success.
>
> In stead of writing a function I guess I would just write a macro...
>
> #define INPWX(port,x) \
> { \
>     asm MOV DX, port \
>     asm IN AX, DX \
>     asm MOV x, AX \
> }
>
>
>
> #define OUTPWX(port,x) \
> { \
>     asm MOV DX, port \
>     asm MOV AX, x \
>     asm OUT DX, AX \
> }
>
> (Don't do:
> #define OUTPWX(port,x) \
> asm \
> {
>     MOV DX, port \
>     MOV AX, x \
>     OUT DX, AX \
> }
> Since the compiler does not really seem to like that...)
>
> This would 'inline' the ASM. It also would remove the function call since 'inline' functions are still functions, but fairly optimized in calling.
>
> I realize that it would be VERY cool when the compiler did all of this to begin with...
>
> HTH
> Jan
>
>
>
> Roland wrote:
>
>> Hello,
>>
>> I'm affraid I don't agree with Walter Bright.
>>
>> IN EAX,DX is valid but is not 16 bit as inpw instruction should be.
>>
>> with some hardware, you must read only 16 bit.
>>
>> for example, reading a register can reset it.
>>
>> in eax,dx     read four bytes in four successive adresses of the
>> port as
>> in ax,dx       read two bytes in two successive adresses of the port
>>
>> its worse with output:
>>
>> example: programing standard Graphic Controler:
>>
>> port 0x03ce is addresse port
>> port 0x03cf is data port
>>
>> you write both port in one 16 bit instruction: the addresse in AL,
>> the value
>> in AH
>>
>> if you write four byte instead of two, you will write in 0x03d0 and
>> 0x03d1
>> too.
>>
>> port 0x03ce and port 0x03cf are documented
>> port 0x03d0 and 0x03d1 are not.. and i do not recomend to write in
>> it: your
>> sceen will be all black..
>>
>> At least, i actualy use inline assembly to write or read 16 bit ports.
>>
>> I made those function:
>>
>>     #if ((__SC__>=0x702) && (_INTSIZE==4))
>>
>> unsigned OUTPW(const unsigned port, const unsigned data) {
>> //__SC__ 7.2 -> out dx,eax au lieu de out  dx,ax
>>         asm mov eax,data;
>>         asm mov edx,port;
>>         asm out dx,ax;
>>         return _EAX;
>> }
>>
>> unsigned INPW(const unsigned port) {
>> //__SC__ 7.2 -> in eax,dx au lieu de in ax,dx
>>         asm mov edx,port;
>>         asm in ax,dx;
>>         return _AX;
>> }
>>
>>     #endif
>>
>> The problem is that asm statement cannot be inlined.
>> Not good for speed..
>>
>> Ciao
>>
>> Roland
>>
>> Jan Knepper a écrit :
>>
>> > Walter Bright wrote:
>> >
>> > > The code output looks correct to me, as:
>> > >     IN EAX,DX
>> > > is a valid instruction. If he wants IN AX,DX in 32 bit mode,
>> this works:
>> > >
>> > >     asm
>> > >     {
>> > >         MOV DX,0x123
>> > >         IN AX,DX
>> > >         MOV i, AX
>> > >     }
>> > >
>> >
>> > --
>
>
> --
>
>    ----------------------------------------------------------------
> _TEXT   segment dword use32 public 'CODE'       ;size is 88
> _TEXT   ends
> _DATA   segment dword use32 public 'DATA'       ;size is 0
> _DATA   ends
> CONST   segment dword use32 public 'CONST'      ;size is 0
> CONST   ends
> _BSS    segment dword use32 public 'BSS'        ;size is 0
> _BSS    ends
> FLAT    group
> includelib SNN.lib
>         extrn   __acrtused_con
>
>         public  ?OUTPW@@YAIII@Z
>         public  ?INPW@@YAII@Z
>         public  _main
> _TEXT   segment
>         assume  CS:_TEXT
>
> ?OUTPW@@YAIII@Z:
>                 push    EBP
>                 mov     EBP,ESP
>                 mov     EAX,0Ch[EBP]
>                 mov     EDX,8[EBP]
>                 out     DX,AX
>                 pop     EBP
>                 ret
>
> ?INPW@@YAII@Z:
>                 push    EBP
>                 mov     EBP,ESP
>                 mov     EDX,8[EBP]
>                 in      AX,DX
>                 pop     EBP
>                 and     EAX,0FFFFh
>                 ret
> _main:
>                 push    EBP
>                 mov     EBP,ESP
>                 push    EAX
>
> ; INPWX macro expansion
>                 mov     DX,03CEh
>                 in      AX,DX
>                 mov     -4[EBP],AX
>
> ; PUTPWX macro expansion
>                 mov     DX,03CEh
>                 mov     AX,-4[EBP]
>                 out     DX,AX
>
> ; INPW function call
>                 push    03CEh
>                 call    near ptr ?INPW@@YAII@Z
>                 mov     -4[EBP],AX
>
> ; OUTPW function call
>                 movsx   EAX,word ptr -4[EBP]
>                 push    EAX
>                 push    03CEh
>                 call    near ptr ?OUTPW@@YAIII@Z
>                 add     ESP,0Ch
>
>                 mov     ESP,EBP
>                 pop     EBP
>                 ret
> _TEXT   ends
> _DATA   segment
> _DATA   ends
> CONST   segment
> CONST   ends
> _BSS    segment
> _BSS    ends
>         end
>

Roland a écrit :

> for port address < 0x100, no need to use dx register for port addresse, port addresse can be immediate value

it's a detail but may be i was not clear enough.

i mean

if port addresse passed to inp/outp is immediate && port addresse is < 0x100 so it
can be passed as immediate value to cpu:
   out <port addresse>,ax
instead of
    mov dx,<port addresse>
    out dx,ax

I agree, it is a detail, if you always use dx for port address it works too.

Salutations

Roland

I have worked with hardware that depends upon the I/O access size, and it is important that inpb/outpb=8bits, inpw/outpw=16bits, and inpl/outpl=32bits in DOS, DOSX, and Win32. After all, I/O accesses are intended to be used with hardware.

For example, reading a card's status register may reset its status bits. If this status register is a 16bit register mapped above some other register, the status register would get cleared when the other register is read via a 32bit I/O access.

Another problem would be writing to a 16bit register. If 32bits are written, the next 16bit register would get written also, even if it is unrelated.

If inpw/outpw and inpl/outpl are both 32bits, how would someone perform an I/O of 16bits?

Lastly, portability is easier if inpw/outpw are consistently the same size.

My 2 cents.
Tim

Walter wrote in message <9rd2sm$2ceu$1@digitaldaemon.com>...
>How do you (and Roland) think they *should* work?
>
>

Ok, you guys have all convinced me! I'll fix the compiler. -Walter

"Roland" <rv@ronetech.com> wrote in message news:3BDE7D31.900FD9A4@ronetech.com...
> i think it should be inline.
>
> inp/outp -> 8 bits (al)
> inpw/outpw -> 16 bits (ax)
> inpl/outpl -> 32 bits (eax), error or emulation on 16 bit cpu
>
> for port address < 0x100, no need to use dx register for port addresse,
port
> addresse can be immediate value
>
> Ciao
>
> Roland
>
> Walter a écrit :
>
> > How do you (and Roland) think they *should* work?
> >
> > John Culver wrote in message <9rcgm7$1qo6$1@digitaldaemon.com>...
> > >Yes,
> > >    I was confusing by the _inline_inpw naming style for the inline
code,
> > and the fact
> > >they were being generated inline, and not really thinking that they
were
> > not inline
> > >functions as such.
> > >
> > >    I did use #undef to remove inpw/outpw as a fix to dos.h
> > >
> > >    The other noticable error in my note is that there is no inline
version
> > of the
> > >inpl/outpl code, so my stating that they are 32 bit is rather creative.
> > >
> > >
> > >JohnC
> > >
> > >"Walter" <walter@digitalmars.com> wrote in message news:9r9n8l$242v$2@digitaldaemon.com...
> > >> The -C switch is for inline functions, not compiler recognized ones.
The
> > >> official way to avoid the compiler recognized ones is to #undef them.
But
> > >> I'll check into the code gen inconsistency. -Walter
> > >>
> > >> John Culver wrote in message <9r9jop$20ac$1@digitaldaemon.com>...
> > >> >Hi,
> > >> >    Actually I think it's only the inline ones that do this, the
> > inpw/outpw
> > >> in the
> > >> >library (port.asm) contain (and generate) the more conventional
forms of
> > :
> > >> >
> > >> >PORT.ASM        inp/outp        8 bits
> > >> >        "     w           16 bits
> > >> >        "    l            32 bits
> > >> >
> > >> >whereas INLINE generates :
> > >> >        inp/outp        8 bits
> > >> >        "     w           32 bits
> > >> >        "    l            32 bits
> > >> >
> > >> >   Making the code generated inconsistent. I was a little suprised
that
> > >> the -C command
> > >> >line option did not remove these inlines. Personally I just hacked
dos.h
> > to
> > >> loose the
> > >> >inline mapping for inpw and outpw to give a reasobale level of
> > >> predictability.
> > >> >
> > >> >
> > >> >
> > >> >John Culver
> > >> >
> > >> >"Walter" <walter@digitalmars.com> wrote in message news:9r81c3$8d7$1@digitaldaemon.com...
> > >> >> Ok, I'll fix the documentation! -Walter
> > >> >>
> > >> >> Roland wrote in message <3BD7029A.2BC5E3DD@ronetech.com>...
> > >> >> >hum..i mean
> > >> >> >
> > >> >> >inpw read 4 bytes instead of 2 and outpw writes 4 bytes instead
of 2.
> > >> >> >
> > >> >> >sorry
> > >> >> >
> > >> >> >Rolland
> > >> >> >
> > >> >> >Roland a écrit :
> > >> >> >
> > >> >> >> since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4
and
> > outpw
> > >> >> >> writes 4 bytes instead of 4.
> > >> >> >> A long time ago I had a discussion with Walter about this.
> > >> >> >> Ok you prefer let it like that because you don't want to fix
> > something
> > >> >> >> that seems to work.
> > >> >> >> But you should put a warning.
> > >> >> >>
> > >> >> >> Regards
> > >> >> >>
> > >> >> >> Roland
> > >> >> >
> > >> >>
> > >> >>
> > >> >
> > >> >
> > >>
> > >>
> > >
> > >
>

This is in the 8.23.2 beta test compiler now, posted for downloading. -Walter

"Walter" <walter@digitalmars.com> wrote in message news:9ro4du$183v$1@digitaldaemon.com...
> Ok, you guys have all convinced me! I'll fix the compiler. -Walter
>
> "Roland" <rv@ronetech.com> wrote in message news:3BDE7D31.900FD9A4@ronetech.com...
> > i think it should be inline.
> >
> > inp/outp -> 8 bits (al)
> > inpw/outpw -> 16 bits (ax)
> > inpl/outpl -> 32 bits (eax), error or emulation on 16 bit cpu
> >
> > for port address < 0x100, no need to use dx register for port addresse,
> port
> > addresse can be immediate value
> >
> > Ciao
> >
> > Roland
> >
> > Walter a écrit :
> >
> > > How do you (and Roland) think they *should* work?
> > >
> > > John Culver wrote in message <9rcgm7$1qo6$1@digitaldaemon.com>...
> > > >Yes,
> > > >    I was confusing by the _inline_inpw naming style for the inline
> code,
> > > and the fact
> > > >they were being generated inline, and not really thinking that they
> were
> > > not inline
> > > >functions as such.
> > > >
> > > >    I did use #undef to remove inpw/outpw as a fix to dos.h
> > > >
> > > >    The other noticable error in my note is that there is no inline
> version
> > > of the
> > > >inpl/outpl code, so my stating that they are 32 bit is rather
creative.
> > > >
> > > >
> > > >JohnC
> > > >
> > > >"Walter" <walter@digitalmars.com> wrote in message news:9r9n8l$242v$2@digitaldaemon.com...
> > > >> The -C switch is for inline functions, not compiler recognized
ones.
> The
> > > >> official way to avoid the compiler recognized ones is to #undef
them.
> But
> > > >> I'll check into the code gen inconsistency. -Walter
> > > >>
> > > >> John Culver wrote in message <9r9jop$20ac$1@digitaldaemon.com>...
> > > >> >Hi,
> > > >> >    Actually I think it's only the inline ones that do this, the
> > > inpw/outpw
> > > >> in the
> > > >> >library (port.asm) contain (and generate) the more conventional
> forms of
> > > :
> > > >> >
> > > >> >PORT.ASM        inp/outp        8 bits
> > > >> >        "     w           16 bits
> > > >> >        "    l            32 bits
> > > >> >
> > > >> >whereas INLINE generates :
> > > >> >        inp/outp        8 bits
> > > >> >        "     w           32 bits
> > > >> >        "    l            32 bits
> > > >> >
> > > >> >   Making the code generated inconsistent. I was a little suprised
> that
> > > >> the -C command
> > > >> >line option did not remove these inlines. Personally I just hacked
> dos.h
> > > to
> > > >> loose the
> > > >> >inline mapping for inpw and outpw to give a reasobale level of
> > > >> predictability.
> > > >> >
> > > >> >
> > > >> >
> > > >> >John Culver
> > > >> >
> > > >> >"Walter" <walter@digitalmars.com> wrote in message news:9r81c3$8d7$1@digitaldaemon.com...
> > > >> >> Ok, I'll fix the documentation! -Walter
> > > >> >>
> > > >> >> Roland wrote in message <3BD7029A.2BC5E3DD@ronetech.com>...
> > > >> >> >hum..i mean
> > > >> >> >
> > > >> >> >inpw read 4 bytes instead of 2 and outpw writes 4 bytes instead
> of 2.
> > > >> >> >
> > > >> >> >sorry
> > > >> >> >
> > > >> >> >Rolland
> > > >> >> >
> > > >> >> >Roland a écrit :
> > > >> >> >
> > > >> >> >> since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4
> and
> > > outpw
> > > >> >> >> writes 4 bytes instead of 4.
> > > >> >> >> A long time ago I had a discussion with Walter about this.
> > > >> >> >> Ok you prefer let it like that because you don't want to fix
> > > something
> > > >> >> >> that seems to work.
> > > >> >> >> But you should put a warning.
> > > >> >> >>
> > > >> >> >> Regards
> > > >> >> >>
> > > >> >> >> Roland
> > > >> >> >
> > > >> >>
> > > >> >>
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >
> > > >
> >
>
>