ACP wrote:

BTW: An interesting detail: I did not remember that TASM is using xchg bx,bx as padding (fasm is using nop).

TASM is adding a single nop (90h) in case of an even number of bytes

I've noticed also other "assembler signatures" of the FASM/TASM. When I get back to them I'll post

Please do!

for example compilation of the instruction "xor ax,ax":
tasm: 33 C0
fasm: 30 C0

Assembler fingerprinting can be interesting. I think that many AV companies use these kinds of details to help determine which compilers and languages are used to create different parts of the code.

Was seeming strange to me that already the first instruction of my program (xor ax,ax) was compiled differently but I was having to debug and didn't take much attention to other ones.
But checking a bit better I was able to find that A LOT of instructions are in reality compiled with different machine codes!
Seems anyway that all are of same length (and that was important to me), but I don't know if a different coding would mean different execution speed (and if vary on different processors)!

Welcome to the great world of x86 instruction set encoding. Actually I wonder if any assembler uses different encoding for the same instruction when different target process has been selected.

There is also a interesting case of A86 assembler: it generated different output files for registers and unregistered versions from the same source.

@revolution
You are right. IDA FLIRT is a great example of another usage of fingerprinting compilers but it rather targets high level language compilers. I haven't seen a good analysis of fingerprinting assemblers on x86. It would be interested to see one eventually.

PS: my "little" program...
http://sourceforge.net/projects/smmax/files/smex%20583%20fide.zip/download
(reference compilation with fasm! )

And also the smaller 455 bytes version!

https://sourceforge.net/projects/smmax/files/smem%20455.zip/download

Okay, I'm late to respond, but here's a few ideas:

Don't bother with TASM, it's of questionable legality (unless you already have an old copy).

EDIT: For completeness, there is a partial TASM ("Ideal") clone called Lazy Assembler (LZASM) circa 2007 that is freeware (Win32 or DOS) and supports debug info as well.

At the basic level, it's easiest to just insert "int3" as breakpoint where you want the debugger to stop, and go from there.

If your debugger doesn't support your kind of symbolic info, and you're running raw DOS (and not multitasking), you can use something like Dave Dunfield's TFB (TSR file browser).

If you're using an emulator (JPC? Bochs?), chances are that they support their own built-in debugger (although DOSBox may need a third-party build to enable this).

A86/D86 (shareware) supports its own .SYM format.

NASM and YASM support various debug infos, but I have no idea which debuggers work best for them. ("nasm -f obj -y" says "Borland Debug Records". "yasm -g help" says "CodeView/VC8, DWARF2, Stabs".)

DJGPP GAS is supported by their GDB (7.1?), not sure about FSDB or EDEBUG32.

WASM/JWasm are supported by OpenWatcom's WD. This might be your best bet.

Ladsoft's VALX (or MKSYM) can produce symbol files for use with his GRDB.

Ciao rugxulo!

I already managed long time ago with Turbo Debugger and delivered successfully Super Micro Chess!

Your information can be anyway useful for someone else in my situation!

Thank you!
_Stefano