1

I want to confirm a few things. I am making assembly language programs for 8086. I am assembling using masm611 assembler. If i run and debug the 8086 16bit real mode program under command prompt in 32 bit windows, Does it use and modify the actual cpu registers and memory? Does the program run in virtual mode86 under windows 32bit?

Also, if i debug the program using the CodeView debugger in PWB Microsoft Programmers’ Workbench as below:

PWB

8086 assembly language program with debugger running

Please confirm whether the register and memory values in the CodeView debugger are actual values in hardware and are changing. Also when i run the program in PWB it uses the actual hardware under windows 32 bit.

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
user2277648
  • 121
  • 2
  • 7
  • As a side note, if you ever find that you need more control over the environment your code is running in, you might want to consider using a virtual machine. – Harry Johnston Sep 25 '16 at 22:31

1 Answers1

6

When you run an MS-DOS program from the Windows command prompt under a 32-bit version of Windows it's run under NTVDM which uses virtual 8086 mode to emulate real mode. The program, when running, uses the CPU's registers as normal. However, it doesn't use memory in same way that code running in real mode would.

Windows doesn't give NTVDM, and any program running under it, direct access to physical memory, just like it doesn't any other Windows application direct access. Instead accesses by the program to memory are translated from linear addresses to physical addresses through page tables. This means that if your MS-DOS application writes to memory location 074B:0000 the CPU will converts this to a linear address of 000074B0 and then through a page table look up converts it a completely different physical address chosen by Windows. Windows also doesn't allow NTVDM, or the application running under it direct, access to device hardware, so any access to device memory will either be blocked or emulated by NTVDM.

I should also note that since the version of CodeView you're using is also an MS-DOS application its also running as an application in virtual 8086 mode using the same actual CPU registers as the program being debugged. This means that when CodeView displays the registers of the debugged program it's showing the values the were in the registers at the time the program stopped and CodeView took over. CodeView needs the registers for its own use, so the first thing it does when it gets control is to save the debugged programs registers in memory somewhere.

Ross Ridge
  • 38,414
  • 7
  • 81
  • 112
  • I dont have experience working with the debuggers. Please verify the following statments. 1) The instructions are actually executed by the processor in the code view. 2) It is also using the registers for its own use. So, the values of some of the registers shown in the debugger are different than the actual values in the registers. 3) After the execution of mov AX,0, CV can move the value of AX to memory and use AX register for its own purpose. 4) The memory contents shown in the debugger are actually present in the physical memory although at different locations.. – user2277648 Sep 26 '16 at 07:35
  • @user2277648 1) Yes, 2) At the time they're displayed they're different 3) after the MOV instruction is executed, if the CPU enters the debugger (eg. because of a breakpoint, or single stepping), then the debugger will save the contents of the registers in memory 4) The memory contents are probably in physical RAM somewhere. They would've needed to be for the debugger to read the contents and display them, but Windows could've saved the contents to the swap file on disk to make room for something else in RAM since then. When accessed again Windows can transparently copy the memory back into – Ross Ridge Sep 26 '16 at 18:39
  • One last thing, Is the above scenario (the 4 points) also the same for gdb debugger? Does gdb debugger also executes the instructions on the real processor? I was reading that some debuggers examine the code on the Instruction Set Simulator. – user2277648 Sep 27 '16 at 16:30
  • @user2277648 GDB is similar but a bit different because it runs under more sophisticated operating systems than MS-DOS. Since it runs in different process than the program being debugged, it's actually the operating system that saves the registers in memory. GDB doesn't have direct access to them, unlike CodeView running under MS-DOS. GDB also supports remote debugging, where GDB runs on a different computer than the debugged program. This is used for various cases like debugging programs running on smartphones, microcontrollers and virtual machines. – Ross Ridge Sep 27 '16 at 16:44