Reg16 or reg32??

[jj2007]

Hi Masm32 crew,

Just opened the Forum, and the four most recent posts are about exciting issues such as
- forest fires
- somebody requesting permission to scare people with CIA badges
- a Cafeteria fight and
- the Late Mr. Frost.

So I hope I won't offend anybody if I open a new thread about, you guessed it, assembler coding:

Val MACRO pStr
  push si
  mov si, pStr
  xor edx, edx
  xor eax, eax
  .While 1
   lodsb
   cmp al, "0"
   .Break .if Sign?
   lea edx, [4*edx+edx]
   lea edx, [2*edx+eax-"0"]
  .Endw
  pop si
  xchg eax, edx
  EXITM <eax>
ENDM

So far, so simple - it works:
  Print Str$(Val(Chr$("12345"))), " is 12345", 13, 10

The question is: Should such macros be limited to 16-bit registers, or is "mixed size" DOS code acceptable? Where would it cause problems?

[Gunther]

Jochen,

The question is: Should such macros be limited to 16-bit registers, or is "mixed size" DOS code acceptable? Where would it cause problems?

I think mixed size is acceptable. The only point is, we've to ensure that at least an 80386 processor is available.

Gunther

[jj2007]

we've to ensure that at least an 80386 processor is available

So it's a hardware, not a software issue? Mixed size would work in DOSBOX and/or "true" DOS?

[nidud]

most programs used in DOS(box) is "32-bit" using DPMI

pure x86 programs are very rare

[FORTRANS]

Hi,

   I would say it is mostly a hardware issue.  If it works, why not
use it?  I don't use 32-bit instructions very often.  But they sure
are useful when you need them.

   There may be issues of addressing limits when using 32-bit
registers in real mode.  And probably some other things, like
confusing myself with differing behavior between 32-bit and
16-bit instructions.

Regards,

Steve N.

[jj2007]

pure x86 programs are very rare

But even a pure x86 program could handle a mov eax, ecx, provided .386 is specified, and the hardware allows it, right?

By the way, debug has serious problems to disassemble mixed size code. For example,
      pushd 10
      pop ecx
produces garbage in the disassembly (the code works fine).

[nidud]

Well, it wouldn't be a pure .8086 program then since this CPU don't have extended registers like EAX.
Hence the reason why this is rare.

[nidud]

By the way, debug has serious problems to disassemble mixed size code. For example,
      pushd 10
      pop ecx
produces garbage in the disassembly (the code works fine).

Programming in real mode is complicated and follows different rules compare to FLAT mode. Using extended registers is not recommended since this will slow down the program, especially using a Intel CPU. The direction flag may not be cleared, so you need to apply the CLD upcode each time you use LODSB. Pointers may be FAR or NEAR depending on models used, same with PROC's. LODSB use DS:SI, and STOSB use ES:DI, so these must be set correctly before usage and so on.

The .model tiny is most like FLAT: pointers and proc's are 16-bit.
There are tiny, small, compact, medium, large, and huge models.

[jj2007]

Well, it wouldn't be a pure .8086 program then since this CPU don't have extended registers like EAX

That makes sense, thanks.

I don't use 32-bit instructions very often.  But they sure are useful when you need them

Indeed. I was playing with the ascii-to-word/word-to-ascii pair when I realised DWORD would be even better ;-)

include DosBasic.inc  ; attached
  Init
  mov eax, Val32(Chr$("-123456789"))
  Print Str$(eax), " is -123456789", 13, 10
  Print Str$(Val32(Chr$("-123456789"))), " is -123456789", 13, 10
  Print Str$(Val(Chr$("12345"))), " is 12345", 13, 10
  Print Str$(Val32(Chr$("123456789"))), " is 123456789", 13, 10
  Print Str$(-123456789), " is -123456789", 13, 10
  Inkey "bye"
  Exit 123
end start

This works fine. In contrast, the attached Fibonacci example has a 16-bit limit in the upper half.

[Antariy]

Just opened the Forum, and the four most recent posts are about exciting issues such as

The question is: Should such macros be limited to 16-bit registers, or is "mixed size" DOS code acceptable? Where would it cause problems?

Yes, it will work. Generally speaking, 32 bit instructions differ from 16 bit instructions in the 16 bit code with prefix 66h added before the opcode. For 32 bit code it all is vice versa - 66h prefix will tell CPU that this instruction is 16 bit, so, for an instance, the data field for the MOV or PUSH etc is "shortened" (16 bit).
Byte sequences:

16 bit code:

68 34 12 (push (word) 1234)

66 68 78 56 34 12 (push (dword) 12345678)

6A 7F (push (word) 007F)

66 6A 7F (push (dword) 0000007F)

50 (push ax)

66 50 (push eax)


32 bit code:

68 78 56 34 12 (push (dword) 12345678)

66 68 34 12 (push (word) 1234 = pushw 1234)

6A 7F (push (dword) 0000007F)

66 6A 7F (push (word) 007F = pushw 7F)

50 (push eax)

66 50 (push ax)

By the way, debug has serious problems to disassemble mixed size code. For example,
      pushd 10
      pop ecx
produces garbage in the disassembly (the code works fine).

DEBUG is aware only about 8086 instruction set. PUSH IMM is 80186 instuction.

BTW, in a DEBUG you can still use 32 bit code, but it is uncomfortable:

-a
1D25:0100 db 66
1D25:0101 mov ax,5678
1D25:0104 dw 1234
1D25:0106 db 66
1D25:0107 push ax
1D25:0108
-r
AX=0000  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=1D25  ES=1D25  SS=1D25  CS=1D25  IP=0100   NV UP EI PL NZ NA PO NC
1D25:0100 66            DB      66
-d ffee
1D25:FFE0                                            00 00                 ..
1D25:FFF0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
-t

AX=5678  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=1D25  ES=1D25  SS=1D25  CS=1D25  IP=0106   NV UP EI PL NZ NA PO NC
1D25:0106 66            DB      66
-t

AX=5678  BX=0000  CX=0000  DX=0000  SP=FFEA  BP=0000  SI=0000  DI=0000
DS=1D25  ES=1D25  SS=1D25  CS=1D25  IP=0108   NV UP EI PL NZ NA PO NC
1D25:0108 7DCC          JGE     00D6
-d ffea
1D25:FFE0                                78 56 34 12 00 00             xV4...
1D25:FFF0  00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
-

[sinsi]

I'm pretty sure you can even use "mov eax,[edx+eax*2]", as long as the effective address doesn't pass 64K.

[Antariy]

I'm pretty sure you can even use "mov eax,[edx+eax*2]", as long as the effective address doesn't pass 64K.

Yes, you're right :t But then the opcode needs one more prefix - 67h

[MichaelW]

DEBUG is aware only about 8086 instruction set.

Which DEBUG?

http://www.japheth.de/debxxf.html

[japheth]

Which DEBUG?

http://www.japheth.de/debxxf.html

There's an even more sophisticated version of DEBUG available: https://sites.google.com/site/pcdosretro/enhdebug

[jj2007]

There's an even more sophisticated version of DEBUG available: https://sites.google.com/site/pcdosretro/enhdebug

Better than the built-in version but

  pushd 10
  pop ecx

still gets disassembled as

 66      DB      66
 6A0A    PUSH    +0A
 6659    POP     ECX

i.e. the size override prefix is not recognised as such.

Sinsi's code gets disassembled correctly, though:
67668B0442        MOV     EAX,[EDX][EAX*2]