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

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

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
>

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
> >
>
>

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
>> >
>>
>>
>
>

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
> >> >
> >>
> >>
> >
> >
>
>

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
>> >> >
>> >>
>> >>
>> >
>> >
>>
>>
>
>

Hi,
    Personally, \Src\Core32\Port.asm does exactly what I would have liked to see :

        inp/outp            8 bit
        inpw/outpw    16 bit    <= Possible compatability issue with the inline variant
, (but it wouldn't affect me)
        inpl/outpl        32 bit

    This would then also mean that generating code for both of the 16 bit and 32 bit
targets generated 8 bit operations for inp/outp, and 16 bit operations for inpw/outpw,
which seems a consistent option, and would match my (shamefully disloyal) experience of
other compilers.

    I know inpl/outpl don't even officially exist (they are not in run time library
manual), but they are very useful. An official 32 bit inline form of inpl/outpl doesn't
seem worth altering the compiler for, the nice modern PCI bus seems to be so amazingly
slow for ins and outs that the time taken by an extra subroutine call is not going to
be noticable on a moderately modern processor.

    Trivia : src\core32\port.asm (File Date : 2nd Jan 1997 on my system) has a comment
on the definition of inpl (line 44) that describes it as 'long inpw( ... )', rather
than the 'long inpl( ... )' that the code actually is.



JohnC

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

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
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >

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
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >