2

I just want to inspect the assembly code of my program to see if he is loading my data in some registers.

I tried with "make" and "build" and selection "disk" as output, but there aren't any new files, besides source and exe file.

fpilee
  • 1,918
  • 2
  • 22
  • 38
  • 1
    So disassemble the binary (.exe) with your favourite disassembler, or run your code in a debugger. It's normal for build tools to only produce object files, unless you use extra options to produce source. (And I don't know what those are for Turbo Pascal). – Peter Cordes Sep 19 '16 at 02:52
  • Hi, I tried with "ndisasm" but the output file was huge. Is that normal? is just a c = a +b pascal program. – fpilee Sep 19 '16 at 02:53
  • Yes, that's normal since the exe includes all the startup boilerplate added by the compiler. Also, NDISASM may not know about the .exe file format, and may disassemble bytes of the PE headers as if they were asm instructions. I'd recommend `objdump -Mintel -mi8086` if you have it (on Linux or as part of a mingw or cygwin install). (`-mi8086` tells it to disassemble 16-bit code). – Peter Cordes Sep 19 '16 at 03:01
  • 2
    @PeterCordes : turbo Pascal that he is running probably predate PE by quite a few years. more like MZ DOS format. – Michael Petch Sep 19 '16 at 03:03
  • is turbo pascal 7.0 on dosbox 0.74 – fpilee Sep 19 '16 at 03:05
  • @MichaelPetch: heh, I've never used DOS or Windows as my main desktop, just Atari ST then x86 Linux. I'm all out of specific advice beyond "use a debugger" :/ – Peter Cordes Sep 19 '16 at 03:06
  • @PeterCordes ,thanks but those args are not for objdump. Ok, michael Petch I will look for that program. Thanks so much guys – fpilee Sep 19 '16 at 03:13
  • I was talking about GNU objdump. I forgot `-d`, but it does work for me on my desktop. `objdump -Mintel -mi8086 -d ./a.out` disassembles assuming 16-bit is the default operand and address size. If it doesn't work for you, maybe you have a different program of the same name installed. I'd recommend trying Michael's suggestion for 16-bit DOS executables, though. IDK if objdump understands that file format. – Peter Cordes Sep 19 '16 at 03:25
  • I may have been wrong about DUMPBIN support DOS MZ programs, although I recall there was a tool from some other companye called DUMPEXE. – Michael Petch Sep 19 '16 at 03:25
  • 1
    @PeterCordes The advantage to programs that understand the DOS MZ format is that they understand the headers and will parse them out. NDISASM blindly dumps everything. And then it won't account for the relocation entries. – Michael Petch Sep 19 '16 at 03:27
  • 2
    For disassembling Turbo Pascal programs I was used to [W32DASM](http://www.angelfire.com/dc/vashala/hacks%20pages/hack_programs/Win32dasm.html). Not sure if the link provided points to a legitimate version (Google showed a few links) but W32DASM worked very well with MZ exes. – Margaret Bloom Sep 19 '16 at 07:24
  • For small checks the easiest is to set a break point and use the TP ide to examine the assembler around it. Watcom also has a 16-bit toolchain. – Marco van de Voort Sep 19 '16 at 09:08
  • "I just want to inspect the assembly code of my program to see if he is loading my data in some registers." - BTW, I can save you some effort. It *does*. How else it would do the addition of values? The x86 usually does not work with two memory operands (I can think of one exception, being MOVS instruction, but as a rule of thumb, if you do operation with two values, then at least one must be in register). – Ped7g Sep 19 '16 at 09:26
  • I used ndisasm again and I searched for the hexadecimal values of my operands and I found the code. http://imgur.com/a/wC5Lr . But, still cannot see the data loaded into AX, only the result. – fpilee Sep 19 '16 at 14:52
  • @MarcovandeVoort: I have never seen a disassembler window in the TP IDE. Does it exist? – Rudy Velthuis Sep 19 '16 at 21:10
  • @FelipeMorales: In the code you show, it stores 45 (0x2d) into [0x50], and 89 (0x59) into [0x52]. Then it loads the first operand (from [0x50]) into AX and adds the second operand (from [0x52]) to it. Then it stores the result -- which is in AX -- in [0x54]. And then, it exits. [0x50] is `a`, [0x52] is `b`, etc. – Rudy Velthuis Sep 19 '16 at 21:15
  • Note that Turbo Pascal did not (or hardly) have any optimizations. It really did what you told it to do, and it didn't take any shortcuts like keeping values in registers, etc. – Rudy Velthuis Sep 19 '16 at 21:18
  • Hi, Yes I see that, but the Turbo Pascal Register Window does not show AX changes, only at the result. – fpilee Sep 19 '16 at 22:31
  • Rudy Velthuis: I wrote it from memory. Maybe it was the standalone TD not the IDE? – Marco van de Voort Sep 20 '16 at 08:34
  • Back when I worked with TP7 alot and I needed to view the assembly code for a section, I would use an inline statement to insert 3-4 NOP commands before the code I wanted to look at and then 3-4 NOP commands to the end of the code I wanted. Then I'd just use an editor to search for the 3 NOP commands in a row and cut out the machine code between the two markers and save them to a file which debug would be able to display nicely. – Troy Mac1ure Nov 07 '16 at 19:17

2 Answers2

2

Turbo Pascal does not generate any intermediate assembler code to inspect. And since you want to interactively examine it you need a debugger anyway.

There is program called Turbo Debugger, also for DOS and with a similar UI as Turbo Pascal, which should suit your needs. If I remember it correctly, at least some version of it has been released as freely.

Fabel
  • 1,711
  • 14
  • 36
1

As an alternative to using Turbo Pascal, you could try Virtual Pascal, which is 99.9% compatible with BP/TP 7. It's 32 bit, so you don't need DOSBox (or, if I may suggest a better alternative, DOSBox-X) and it generates a full assembler listing if you ask it to do so. The IDE also has a CPU window that shows you the generated code and allows you to single-step though it, highlighting the changed registers.

prino
  • 39
  • 3