🚀 go-pugleaf

> 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