From: Reinier Zwitserloot
Subject: Re: 3D game engine for PB?
Dave Navarro wrote:
> I'd need more proof than that. Microsoft sales of MASM reached 3 million
> copies about 5 years ago. And its reputed that twice that number of people
> have pirated TASM.
Hee! Using pirated copy counts as indicator of users, tasm would
probably win :-P.
>
> I just went to my favorite computer book store (over 8,000 titles in the
> store) and couldn't find a single book on NASM. I found 31 different books
on
> the shelf for MASM and 9 for TASM.
Agreed! One of the problems with NASM is lack of documentation.
Fortunately NASM and MASM syntax are very much alike, and it's quite
rare to see books cover the MASM 'tricks' early on (such as the red-tape
that can't easily be macroed in NASM. ie: .radix, and the macro
capabilities which are very different from those of NASM). A small
section in the nasm help file does point out the main differences. The
main disadvantage is that one of the best books (available online,
believe it or not) written as study for assembly, Art of Assembly by
Randall Hyde, uses a set of routines that are heavily macro-dependent
and very large, and I doubt people would ever convert all that to NASM.
NASM is quite new though, and unfortunately new assembler books rarely
come out. The last new tutorial (a very small one) did include documents
and footnotes on conversion to both MASM and NASM (It assumed use of
TASM.)
>
> I realize that you *really* like NASM and it does seem to me like a pretty
> good product, but claiming that it's more popular than MASM and TASM is
> stretching things in my opinion.
I don't see as to whether it matters, me stretching NASM above the
popularity of MASM and TASM, simply because NASM is free it's impossible
to measure correctly. However, I would think you agree with me that the
user base of NASM is sufficient enough to address the compatibility
problem. For a fact (Since i'm programming my own linker at this point)
I know it's a very easy change to support both formats. (To outline: If
the fixup thread is a 16-bit offset instead of a 32-bit offset, check if
the next fixup is a 16-bit segment exactly 2 bytes from the first. If
so, eliminate this second fixup thread and assume the first one is a
32-bit offset (the usual). 'cheating' or cause for incompatibility? No,
as 16-bit offset with a 16-bit segment 2 bytes down is the same.
Similarly it should be easy for NASM to add this capability but
according to the author's they'd rather keep it the way it is for some
VMS compilers (gee, very old, but okay) which don't support the 32-bit
form, *AND* it would require 'red-tape', something that NASM tries to
avoid, whereas the linker does not require a user directive to support
both forms.
(Not to mention I paid $150 for PB and downloaded nASM for free :-P)
Thanks for the attention!
--
- Ray Zwitserloot.
R.Zwitserloot@antispam.BTInternet.com
Change the E-mail address to reply!
----------------------------------------------------
*** QwkNews (tm) v2.1
* [TN71] alt.lang.powerbasic POWER_BAS Gateway
--- GEcho 1.20/Pro
---------------
* Origin: Toast House Remote (1:100/560.2)
|