www.digitalmars.com         C & C++   DMDScript  

c++.dos.32-bits - inpw/outpw read/write 4 bytes in DOSX

reply Roland <rv ronetech.com> writes:
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
Oct 24 2001
parent reply Roland <rv ronetech.com> writes:
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

Oct 24 2001
parent reply "Walter" <walter digitalmars.com> writes:
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


Oct 24 2001
parent reply "John Culver" <jculver btinternet.com> writes:
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



Oct 25 2001
parent reply "Walter" <walter digitalmars.com> writes:
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

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

line option did not remove these inlines. Personally I just hacked dos.h to

inline mapping for inpw and outpw to give a reasobale level of

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




Oct 25 2001
parent reply "John Culver" <jculver btinternet.com> writes:
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

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

line option did not remove these inlines. Personally I just hacked dos.h to

inline mapping for inpw and outpw to give a reasobale level of

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





Oct 26 2001
parent reply "Walter" <walter digitalmars.com> writes:
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,

they were being generated inline, and not really thinking that they were

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

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



 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

line option did not remove these inlines. Personally I just hacked dos.h



 loose the
inline mapping for inpw and outpw to give a reasobale level of

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






 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






 that seems to work.
 But you should put a warning.

 Regards

 Roland






Oct 26 2001
next sibling parent "John Culver" <jculver btinternet.com> writes:
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?

Oct 27 2001
prev sibling next sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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,

they were being generated inline, and not really thinking that they were

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

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



 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

line option did not remove these inlines. Personally I just hacked dos.h



 loose the
inline mapping for inpw and outpw to give a reasobale level of

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






 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






 that seems to work.
 But you should put a warning.

 Regards

 Roland







Oct 27 2001
parent Roland <rv ronetech.com> writes:
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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,

they were being generated inline, and not really thinking that they were

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

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



 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

line option did not remove these inlines. Personally I just hacked dos.h



 loose the
inline mapping for inpw and outpw to give a reasobale level of

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






 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






 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,


     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

Oct 30 2001
prev sibling next sibling parent reply Roland <rv ronetech.com> writes:
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,

they were being generated inline, and not really thinking that they were

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

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



 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

line option did not remove these inlines. Personally I just hacked dos.h



 loose the
inline mapping for inpw and outpw to give a reasobale level of

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






 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






 that seems to work.
 But you should put a warning.

 Regards

 Roland







Oct 30 2001
next sibling parent Roland <rv ronetech.com> writes:
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
Oct 30 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
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,

 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



 and the fact
they were being generated inline, and not really thinking that they



 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



 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.




 official way to avoid the compiler recognized ones is to #undef them.




 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



 in the
library (port.asm) contain (and generate) the more conventional





 :
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





 the -C command
line option did not remove these inlines. Personally I just hacked





 to
 loose the
inline mapping for inpw and outpw to give a reasobale level of

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







sorry

Rolland

Roland a écrit :

 since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4








 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






 that seems to work.
 But you should put a warning.

 Regards

 Roland








Oct 30 2001
parent "Walter" <walter digitalmars.com> writes:
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,

 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



 and the fact
they were being generated inline, and not really thinking that they



 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



 of the
inpl/outpl code, so my stating that they are 32 bit is rather




JohnC

"Walter" <walter digitalmars.com> wrote in message
news:9r9n8l$242v$2 digitaldaemon.com...
 The -C switch is for inline functions, not compiler recognized





 The
 official way to avoid the compiler recognized ones is to #undef





 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



 in the
library (port.asm) contain (and generate) the more conventional





 :
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





 the -C command
line option did not remove these inlines. Personally I just hacked





 to
 loose the
inline mapping for inpw and outpw to give a reasobale level of

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







sorry

Rolland

Roland a écrit :

 since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4








 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






 that seems to work.
 But you should put a warning.

 Regards

 Roland









Oct 31 2001
prev sibling parent "tjulian" <t t.com> writes:
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?

Oct 30 2001