bmarsh@cod.NOSC.MIL (William C. Marsh) (06/07/90)
In article <669@digi.lonestar.org> mkallas@digi.UUCP (mark kallas) writes: >Their [Turbo] Assembler is fully MASM compatible and twice as fast. I'm sorry, but I have to say that Turbo Assembler is *not* fully compatible with MASM. I have a rather large graphics library written in assembler, and the code that is generated is not the same between the two assemblers, no matter what options (MASM51 or QUIRKS) are used. Specifically, the automatic stack frame generation and parameter passing generate different code, and also have different requirements. Turbo will always generate the "push bp/mov bp,sp" and "pop bp" around any function, but MASM only generates this code if parameters are passed to the function. Also, in the USES clause of the PROC directive, Turbo doesn't let you list BP as a register. If NEC can get in trouble for claiming the original Multisync was VGA compatible (even though it didn't auto-size), then Borland has no business saying TASM is MASM compatible. Bill -- Bill Marsh, Naval Ocean Systems Center, San Diego, CA {arpa,mil}net: bmarsh@cod.nosc.mil uucp: {ihnp4,akgua,decvax,dcdwest,ucbvax}!sdcsvax!nosc!bmarsh "If everything seems to be coming your way, you're probably in the wrong lane."
david@csource.OZ.AU (david nugent) (06/07/90)
> In article <669@digi.lonestar.org> mkallas@digi.UUCP (mark kallas) writes: > >Their [Turbo] Assembler is fully MASM compatible and twice as fast. > > I'm sorry, but I have to say that Turbo Assembler is *not* fully > compatible with MASM. I have a rather large graphics library written > in assembler, and the code that is generated is not the same between > the two assemblers, no matter what options (MASM51 or QUIRKS) are used. Up to this point, I agree. There are some subtle code generation difference, and even more missing coding features available in MASM 5.1 than in TASM. TASM doesn't support specifically typing a call for HLL support (for example, declaring a function C or Pascal type, or an external function the same way). Whereas MASM doesn't support typed sizing of LOCAL variables on the stack, TASM does. In general, TASM lacks good error reporting. I can't count the endless number of times it passed moving a word into a byte register, or vice versa - completely without comment. Some subtle hard-to-find bugs can arise because of that minor ommission. The macro language in Quirks more is a little more 'quirky' than MASM; now I have it working (for some months now), I'm not willing to touch it, so I can't recall the specifics. ;-) > Specifically, the automatic stack frame generation and parameter passing > generate different code, and also have different requirements. Turbo > will always generate the "push bp/mov bp,sp" and "pop bp" around any > function, but MASM only generates this code if parameters are passed > to the function. There I disagree. I have to specifically FORCE it do it's stack frame setup in one case by declaring a local variable, since I rely on BP in that case to implement a C alloca(). Then again, perhaps it's in switches I use - I do know that TASM is quite capable of leaving out stack setup/breakdown code. > Also, in the USES clause of the PROC directive, Turbo > doesn't let you list BP as a register. Never noticed this one; never had cause to I guess. > If NEC can get in trouble for claiming the original Multisync was VGA > compatible (even though it didn't auto-size), then Borland has no business > saying TASM is MASM compatible. It caused more than a few headaches for me (to find out it wasn't really worth it - if only I hadn't become hooked on Turbo Debugger :-)), and to a seasoned user with buckets of code, that statement is true enough; but to a lot of users, TASM will be compatible enough not to warrant attention. On that basis, they could probably make the claim. david -- Unique Computing Pty Ltd, Melbourne, Aust. david@csource.oz.au 3:632/348@fidonet 28:4100/1@signet