c++.dos.32-bits - inpw/outpw read/write 4 bytes in DOSX
- Roland <rv ronetech.com> Oct 24 2001
- Roland <rv ronetech.com> Oct 24 2001
- "Walter" <walter digitalmars.com> Oct 24 2001
- "John Culver" <jculver btinternet.com> Oct 25 2001
- "Walter" <walter digitalmars.com> Oct 25 2001
- "John Culver" <jculver btinternet.com> Oct 26 2001
- "Walter" <walter digitalmars.com> Oct 26 2001
- "John Culver" <jculver btinternet.com> Oct 27 2001
- Jan Knepper <jan smartsoft.cc> Oct 27 2001
- Roland <rv ronetech.com> Oct 30 2001
- Roland <rv ronetech.com> Oct 30 2001
- Roland <rv ronetech.com> Oct 30 2001
- "Walter" <walter digitalmars.com> Oct 30 2001
- "Walter" <walter digitalmars.com> Oct 31 2001
- "tjulian" <t t.com> Oct 30 2001
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
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
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
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
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
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
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 thelibrary (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 theinline 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
"John Culver" <jculver btinternet.com>
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
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 thelibrary (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 theinline 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
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
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 thelibrary (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 theinline 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
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
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 factthey were being generated inline, and not really thinking that they
not inlinefunctions 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 theinpl/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 thelibrary (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 commandline option did not remove these inlines. Personally I just hacked
toloose theinline 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
outpwwrites 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
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 factthey were being generated inline, and not really thinking that they
not inlinefunctions 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 theinpl/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
Theofficial way to avoid the compiler recognized ones is to #undef
ButI'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 thelibrary (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 commandline option did not remove these inlines. Personally I just hacked
toloose theinline 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
outpwwrites 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
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