delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/05/23/05:48:16

Date: Sat, 23 May 1998 11:35:11 +0200 (MET DST)
Message-ID: <199805230935.LAA07140@basement.replay.com>
Subject: Re: NASM? Thanks, but no thanks. (Was Re: Execution finished before started!)
From: nobody AT REPLAY DOT COM (Anonymous)
Organization: Replay and Company UnLimited
Mail-To-News-Contact: postmaster AT nym DOT alias DOT net
Newsgroups: comp.os.msdos.djgpp
Lines: 170
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <6k4a4u$5dg$1 AT rosenews DOT rose DOT hp DOT com>,
  "Andrew Crabtree" <andrewc AT rosemail DOT rose DOT hp DOT com> wrote:
> 
> 
> Anonymous wrote in message <199805221253 DOT OAA24000 AT basement DOT replay DOT com>...
> 
> >I just downloaded NASM (v. .97 ?) and read the docs (HTML-formatted) and I
> think
> >I'll pass.
> 
> >(1) It has a "system" for using structures, but the definition and
> instantiation
> >of structures actually appears to be (intentionally made?) more complex
> than
> >what you'd get by sticking with the "workarounds" in GNU as
> You seem to be under the impression that NASM was made as a replacement for
> gas.  This is not true.  But structures in NASM are not the best
> implementation.  Definition is pretty simple (from the docs)
> 
>           struc mytype
> 
> mt_long:  resd 1
> mt_word:  resw 1
> mt_byte:  resb 1
> mt_str:   resb 32
>           endstruc
> 
> But accessing them by manually adding offsets bites.

The authors of NASM themselves compare their assembler to MASM, TASM, gas, and a86
within their documentation.  The implication is that they want NASM to be for 
assembly programmers what usersof those assemblers want in an assembler.
In particular, they would like to attract MASM users, since they address the differences
and similarities between NASM and MASM throughout the documentation.

It is my very humble opinion that the MASM/TASM style of structure declaration and
instantiation is superior to the approach the NASM authors have taken, for if anything,
the former's approach to structure's appears less complicated than the latter's.
I suspect in a future version (0.98?) the authors of NASM may just rectify this
difference in style.  A record/structure for an assembly programmer is useful, if
not outright essential, and the use of an 'istruct/iend' with its confusing
initialization seems altogether unnecessary.

> 
> >(2) It is really its own brand of assembler, using a hybrid of directives
> that the
> >developers apparently thought were useful but requires a "refcard" 5 pages
> long to
> >keep track.
> This was smart to many people (myself included).  Some of the old MASM ways
> of doing these were dumb.  I hated all the borland compatibility stuff.
> Better to start fresh with something that makes sense after you learn it.
> It took a couple of days to learn nasm, but I have found it easy to remember
> because it is somewhat intuitive, especially if you don't have previous
> experience with other x86 assemblers.
> 
> >(3) It might be more useful if it had the ability to accept code in the
> ning that it
> >Bell Lab (AT&T/USL) instruction format.
> Why?!?  That is what gas is for.

Gas is not a full-featured assembler like NASM/TASM/MASM, and
everyone concedes that.  So being able to code in AT&T style--which I am accustomed
to doing, by the way--in a featureless assembler when you long for an assembler
with at least a few features but have to swallow Intel-style coding....well, a
hard decision has to be made.  

Or does a hard decision really have to be made?  Look at what the authors of
NASM give you:  a pre-processor with so many features that even the authors
probably forgot all of them;  options to output assembled code in countless
object file formats;  the necessary number of assembler directives.  I wonder
if NASM can even tell the programmer at some point in time to get up and
stretch or take a toilet break...it does appear that useful.

But then they insist on a single input style, and make a point of not accepting
certain MASM or TASM symbolic conventions/syntax, such as how to symbolize
indirections with segment prefixes, which they apparently see as leading to
careless programming practices or which are otherwise illogical or confusing
(I agree with them here).

I don't disagree with setting rigorous standards for following a coding style
like the Intel-style, and the authors are justified in trying to hold to a
standard that everyone accepts, and to "purify" the use of symbolic notation and
syntax.

But there is another well-established and well-used coding style, and that is
in fact the AT&T-style, which everyone in this group is very familiar with.
Let me include an excerpt from the NASM documentation (from section 1.1.1 of
the html-formatted manual):

   gas is free, and ports over DOS and Unix, but it's not very good,
   since it's designed to be a back end to gcc, which always feeds it
   correct code. So its error checking is minimal.
   Also, its syntax is horrible, from the point of view of
   anyone trying to actually write anything in it.
   Plus you can't write 16-bit code in it (properly). 

Here the authors are comparing their NASM to other assemblers.  The
comment "Also, its syntax is horrible" is apparently a clear expression of
the authors' distaste for anything not in the Intel-style.  This prejudicial
remark could actually be offensive to someone who prefers the AT&T-style.
Perhaps the authors are unaware of just why Bell Labs developed a symbolic
notation and syntax years before Intel did specifically for its x86 processors,
and for what purpose it served AT&T to develop such a style, superior to Intel's
in many ways:

1. specification of the size of data operation in the instruction clearly
   makes for tighter code as it doesn't create ambiguities and can catch
   errors that otherwise might appear in assembled code (not caught by
   assembler)
       movl/movw/movb vs mov

2. Use of src,dest rather than dest,src:  complete novices are stupefied by
   this notation (unless they read Hebrew or Chinese or some right->left rather
   than left->right language).  I can understand a right->left process when
   everything in the syntax/symbolic notation is right to left, that is:

          [xbe],xae vom

The fact is, people who may have cut their teeth on AT&T-style dismiss
Intel-style coding as "for the birds."  And the Intel-style coders similarly
look down their noses at the AT&T-style coders.  The developers of NASM
don't have to, and should not, play that game.

Keep in mind that NASM stands for "NetWide Assembler."  I really don't think it
is difficult for the authors to incorporate within the program (as a command 
line option or assembler directive) a parsing module that is told to
assemble this source assuming correct AT&T coding style--and then do just that,
including holding the programmer to absolutely correct AT&T coding style, and
generating errors where things are sloppy or "kludged" or make use of
distasteful and unacceptable practices and conventions.  This assembler
will then truly be net-wide in terms of its use.

> >I have to say one thing:  NASM's developers were right in making it
> available
> >without charge, since I can't imagine anyone buying something that hardly
> makes
> Thanks for sharing.  I'm sure they did it just for people like you who are
> apparantly willing to pirate commercial software as well ...
> >effort to hold an unlicensed (unpurchased) copy of TASM or MASM.  I will
> concede
> 
> >  I will sit down this minute to use NASM if, say,25 people in this
> newsgroup can tell me:
> 
> Use it or don't use it.  It is the only assembler that I use.  All that it
> is really lacking is debug support.
> I had used both tasm and gas previous to picking up nasm.
> 
> Andy

I am coming to the realization that I too will probably be forced to using
NASM and putting up with its foibles.  That implicitly acknowledges that I am
declaring that NASM is the best among the freebies (and probably among the
things that cost an arm and a leg too).  But it will not be something I much
prefer.  If the authors, one of whom I believe follows this group in fact,
do me the kind favor of implementing structures and setting up a parser for
AT&T-coding style in their next version, something I don't imagine is beyond
their talents at all, then I will be a very happy NASM user.  

Andy, don't tell me you have never at any time of your existence found an
unlicensed copy of any software on a computer owned or used by you, and that you
did not even use it?  Andy, you may be the last of a dying breed if that is so.
Have you ever imagined just how rich Bill Gates really would be if everyone had
honestly paid for their copies of Windows?  And do you ever wonder if Bill ever
used an unlicensed bit of software?  Apple wonders, I am sure.

Thanks to John Fine for his opinion too.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019