Dos tidbit: register-based Watcall parameter order
It has occurred to me that in the course of writing DOS programs (some of which even work!), I spend an awful lot of time searching through documentation. Which is, you know...fine. It's part of the charm of retro coding.
However, this ancient source has an inaccuracy which has bitten me twice (the second time because I forget about 99% of what I read). Not that I bear the author any ill-will - if a document as detailed and comprehensive as that contained no inaccuracies at all, I would be worshiping the author as some kind of god. It might even have been accurate at the time of writing (2010CE). There's plenty more in that site which I intend to dig through and learn from as well.
Anyway. What bit me:
When using register-based watcall* to call an asm procedure from C/C++, 16-bit parameters are passed in this order: AX, DX, BX, CX.
*in OpenWatcom V2 at time of writing.
As I read it, the document says it is in the order AX, BX, CX, DX. This caused me MUCH confusion and my fledgling asm-debugging skills took some hours to dig out the cause of my crashes.
A useful by-product of my toil was that I now have somewhat-tested asm routines which are essentially a debug-print statement. OutputHex writes the ax register value to the DOS screen as hex:
However, this ancient source has an inaccuracy which has bitten me twice (the second time because I forget about 99% of what I read). Not that I bear the author any ill-will - if a document as detailed and comprehensive as that contained no inaccuracies at all, I would be worshiping the author as some kind of god. It might even have been accurate at the time of writing (2010CE). There's plenty more in that site which I intend to dig through and learn from as well.
Anyway. What bit me:
When using register-based watcall* to call an asm procedure from C/C++, 16-bit parameters are passed in this order: AX, DX, BX, CX.
*in OpenWatcom V2 at time of writing.
As I read it, the document says it is in the order AX, BX, CX, DX. This caused me MUCH confusion and my fledgling asm-debugging skills took some hours to dig out the cause of my crashes.
A useful by-product of my toil was that I now have somewhat-tested asm routines which are essentially a debug-print statement. OutputHex writes the ax register value to the DOS screen as hex:
OutputHexDigit PROC WATCOM_C public
and ax,0xf
cmp ax, 0xa
jb normalDigit
add ax, 0x37
jmp outputDigit
normalDigit:
add ax, 0x30
outputDigit:
mov ah, 0Eh
int 10h
ret
OutputHexDigit ENDP
OutputHex PROC WATCOM_C public
push ax
shr ax,12
and ax,0xf
call OutputHexDigit
pop ax
push ax
shr ax,8
and ax,0xf
call OutputHexDigit
pop ax
push ax
shr ax,4
and ax,0xf
call OutputHexDigit
pop ax
and ax,0xf
call OutputHexDigit
mov al,13
int 10h
mov al,10
int 10h
ret
OutputHex ENDP
Comments
Post a Comment