c++.dos.32-bits - inpw/outpw read/write 4 bytes in DOSX
- Roland (8/8) Oct 24 2001 since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4 and outpw
- Roland (5/13) Oct 24 2001 hum..i mean
- Walter (2/17) Oct 24 2001
- John Culver (16/39) Oct 25 2001 Hi,
- Walter (8/50) Oct 25 2001 The -C switch is for inline functions, not compiler recognized ones. The
- John Culver (10/69) Oct 26 2001 Yes,
- Walter (10/82) Oct 26 2001 and the fact
- John Culver (21/22) Oct 27 2001 Hi,
- Jan Knepper (7/96) Oct 27 2001 I seem to remember that Rolands issue also was speed. He wanted to inlin...
- Roland (24/312) Oct 30 2001 Yes i remember this.
- Roland (9/98) Oct 30 2001 i think it should be inline.
- Roland (12/14) Oct 30 2001 it's a detail but may be i was not clear enough.
- Walter (14/113) Oct 30 2001 Ok, you guys have all convinced me! I'll fix the compiler. -Walter
- Walter (7/127) Oct 31 2001 This is in the 8.23.2 beta test compiler now, posted for
- tjulian (16/17) Oct 30 2001 I have worked with hardware that depends upon the I/O access size, and i...
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/outpwin 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 thatthe -C commandline option did not remove these inlines. Personally I just hacked dos.h toloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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
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 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,and the factthey were being generated inline, and not really thinking that they werenot 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 versionof 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...inpw/outpwThe -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 oftoPORT.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 thatthe -C commandline option did not remove these inlines. Personally I just hacked dos.houtpwloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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 andsomethingwrites 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 fixthat 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
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 factthey were being generated inline, and not really thinking that they werenot 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 versionof 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...inpw/outpwThe -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 oftoPORT.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 thatthe -C commandline option did not remove these inlines. Personally I just hacked dos.houtpwloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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 andsomethingwrites 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 fixthat seems to work. But you should put a warning. Regards Roland
Oct 27 2001
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>...---------------------------------------------------------------- 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:Yes, I was confusing by the _inline_inpw naming style for the inline code,and the factthey were being generated inline, and not really thinking that they werenot 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 versionof 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...inpw/outpwThe -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 oftoPORT.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 thatthe -C commandline option did not remove these inlines. Personally I just hacked dos.houtpwloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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 andsomethingwrites 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 fixthat seems to work. But you should put a warning. Regards RolandHello, 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 :-- ---------------------------------------------------------------- _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 endWalter Bright wrote:this works: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 }--
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,and the factthey were being generated inline, and not really thinking that they werenot 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 versionof 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...inpw/outpwThe -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 oftoPORT.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 thatthe -C commandline option did not remove these inlines. Personally I just hacked dos.houtpwloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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 andsomethingwrites 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 fixthat 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 valueit'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,portaddresse can be immediate value Ciao Roland Walter a écrit :code,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 inlinewereand the factthey were being generated inline, and not really thinking that theyversionnot 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 inlineTheof 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.Butofficial way to avoid the compiler recognized ones is to #undef them.forms ofinpw/outpwI'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, thein thelibrary (port.asm) contain (and generate) the more conventionalthat: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 supriseddos.hthe -C commandline option did not remove these inlines. Personally I just hackedof 2.toloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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 insteadandsorry Rolland Roland a écrit :since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4outpwsomethingwrites 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 fixthat 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...creative.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,portaddresse can be immediate value Ciao Roland Walter a écrit :code,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 inlinewereand the factthey were being generated inline, and not really thinking that theyversionnot 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 inlineof theinpl/outpl code, so my stating that they are 32 bit is ratherones.JohnC "Walter" <walter digitalmars.com> wrote in message news:9r9n8l$242v$2 digitaldaemon.com...The -C switch is for inline functions, not compiler recognizedThethem.official way to avoid the compiler recognized ones is to #undefButforms ofinpw/outpwI'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, thein thelibrary (port.asm) contain (and generate) the more conventionalthat: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 supriseddos.hthe -C commandline option did not remove these inlines. Personally I just hackedof 2.toloose theinline mapping for inpw and outpw to give a reasobale level ofpredictability.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 insteadandsorry Rolland Roland a écrit :since SC 7.01 there is a BUG: inpw read 4 bytes instead of 4outpwsomethingwrites 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 fixthat 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