My CPU and MASM think that when an instruction is preceeded with 66h, it means to switch from the default of 32bit register commands to 16bit register commands.
My Turbo Debug v. 5.0, on the other hand, thinks that when an instruction is preceeded with 66h, it means to switch from the default of 16bit register commands to 32bit register commands. This is a terrible problem, as it results in the reversal of exx and xx in every instruction if i try to debug my programs. Surely someone has used both 32 and 16 bit registers while debugging and knows how to solve this problem. Please help!
Posted on 2001-11-26 20:22:29 by LOLTH
the default mode (32 versus 16 bit) of a code segment is determined by a bit in the CS descriptor. If your debugger cannot interpret this correctly im afraid you will need to switch to another.
Is your prog a protected or real mode app?

japheth
Posted on 2001-11-27 01:10:54 by japheth
Prefix 66h is the operand size overide prefix. All it does is over ride the current segments default size operation.

Intel does this to save having to have a seperate opcode for each 32bit and 16bit instruction.

In a 32Bit segment:


004010F3 8BC2 mov eax,edx
004010F3 668BC2 mov ax,dx


In a 16Bit segment:


004010F3 8BC2 mov ax,dx
004010F3 668BC2 mov eax,edx


And that is the main difference bewteen a 32Bit and 16Bit segment.
Posted on 2001-11-27 01:43:13 by huh
in MASM you can control how its compiled as follows:

.386 ; or what ever you prefer
.model ; you model type

Will be in 32 bit mode by default with 66h as the 16bit overide prefix...


.model
.386

In this order, will be in 16 bit mode with 66h being the 32bit overide...

(( I know because i wrote a midterm on it a month ago ))

You can get more detailled info on how this all comes together from this web page's course notes:

CPU architecture

Or specificaly at NOTES 05

Hope this helps...
NaN
Posted on 2001-11-27 02:56:25 by NaN
LOLTH, perhaps you should switch to another debugger? =). Or at
least get the most recent version, which should handle these things
properly.
Posted on 2001-11-27 10:13:48 by f0dder
Fodder, I tried many other debuggers (debug, ollydbg, symdbg, windbg) and none of them worked. NaN's suggestion fixes the problem perfectly. How do i tell what mode the processor is in? (if a 66h register means override 32 bit mode or override 16bit mode). Since MASM allows you to compile in either mode, and it does not add any code to the program to change the value of the CS register, one config must be right and one wrong. How do i tell which is right for my processor?
Posted on 2001-11-27 15:44:50 by LOLTH
The mode you're in... pretty easy. 16bit .com and .exe and .sys
(etc) is in 16bit realmode. PE executables are in 32bit protected
mode. Simple as that.
Posted on 2001-11-27 16:02:25 by f0dder
ok, thanks.
yet another question (im a newbie):
what is the difference between real and protected mode?
Posted on 2001-11-27 16:47:09 by LOLTH
Difference between real and protected mode is pretty big :).
Real mode gives you access to all the stuff, and has a segmented
memory model. Protected mode differentiates between ring0 (all
access) and ring 3 (not very much acccses). There's a couple more
rings, but those aren't really used. Also, segments can now be of
variable sizes, and segment registers hold selectors that index to
a descriptor table. Usually you use a flat memory model in p-mode
though, since it's so much easier. Oh yes, there's also issues like
paging etc. I recommend you to have a look at the system programmers
guide from the intel processor docs, it explains all this very well :).
Posted on 2001-11-27 17:03:20 by f0dder
Some old debuggers which dont support 32Bit code will just read 32Bit code as 16Bit code. What I dont understand is what you are trying to compile.

Are you trying to run this code under Dos or Windows?

But.. if the defualt is a 32Bit code, then is should be linking into a PE file, which is new enough format so a debugger that is able to read the format should be new enought to know what 32Bit code is.

If you are running under dos, then you should want to do what NaN suggested, and force 16Bit mode by placing the .MODEL directive before the CPU directive. I cannot imagine 32Bit code would link and run sucessfuly in a plain old DOS exe, which you would need a different linker for than the masm32 one anyway.

If you are linking 16Bit code into a PE executable, that is very intresting.
Posted on 2001-11-27 22:36:11 by huh