Why there are so many assemblers.


Dean Kent wrote:
> "The_Sage" <The_Sage@xxxxxxx> wrote in message
> news:mhv9o1tsdu969v4pq33ab3jamauuq5spkr@xxxxxxxxxx
> >
> > What that says is that the existence of HLA is in dispute, not that they
> > actually exist. David gives examples of what are considerd by some to be
> HLAs,
> > but offers no proof, as he remains neutral in the matter.
>
> I have absolutely no idea what brought this argument is about, and cannot
> for the life of me figure out why the subject is so important.

The explanation is simple, though lengthy.
Here's the scoop:

in 1978 Intel, along with their brand-new 16-bit chip the 8086,
introduced a new type of assembly language syntax. Part of the syntax
dealt with issues such as the segmentation memory management facilities
found on the processor, but others added a "high-level" flavor to the
assembly language itself, such as a modicum of type checking on
instruction memory operands.

Programmers who'd grown up with simple (i.e., "flat") memory models
found the segmentation model difficult to understand. Furthermore,
programmers who'd gotten used to accessing memory in unstructured ways
decried the "type checking" that took place (even though it was easy
enough to override). Furthermore, implementing all of these features in
an assembler was *considerable* work. Therefore, there was a big cry
(especially from the developers of assembler tools) about how Intel's
syntax had all these "red tape" directives that were unnecessary for
writing "real" assembly language programs. I was there. I too was
annoyed by all the extra stuff I had to learn at the time. Indeed, I
remember avoiding segmentation, "procs", and other stuff in MASM when I
first began learning x86 assembly. After a few programs, however, I
began to see *why* Intel introduced these advanced features; other
programmers never quite made the transition however.

Of course, segmentation isn't really much of an issue anymore, but the
"old school" programmers still chaff at any advanced features in an
assembler, claiming that it's just "not true assembly". There are those
in this very newsgroup, for example, that argue that if an assembler
contains macro facilities, then it is not a "true" assembler. Clearly,
that notion is about 40 years out of date. But some people have a hard
time moving along with the times.

The transition to the Intel Syntax took a while, but by the late 1980's
and early 1990's the Intel syntax had pretty much won out over the
"simplified" syntax of earlier x86 assemblers such as the CP/M
assembler or A86. A few die-hards continued to use those weaker
assemblers, but Intel syntax was the standard and most people came to
deal with it (even with segmentation, which was necessary for writing
decent DOS code).

Then in the early 1990s, Microsoft did something that rocked the boat
-- they introduced "high-level assembly language" to the x86 market
(though "introduced" may be a bit strong, as some might consider
Intel's PL/M-86 to be a high-level assembler, though I don't
particularly agree with that). In addition to advanced data structures
(e.g., structs and unions) found in MASM v5, Microsoft introduced
high-level control structures like IF, WHILE, and INVOKE in MASM v6.
Again, a line was drawn in the sand. Programmers argued that this was
no longer an assembler, but a "high-level language." The *new*
old-timers dealt with the issue by simply choosing not to use those new
language facilities and continued to work in their comfortable MASM v5
programming style. It wasn't until the next generation of programmers
came along, particularly those who started programming in assembly
under Windows, that the MASM "high-level assembly language" syntax
became popular.

As history demonstrates, the new generation of programmers would
eventually have displaced the older generation and the use of
high-level assembly language would have become commonplace (as you've
witnessed on the IBM mainframe), except for two little details: (1)
both Microsoft and Borland (who were selling these high-level
assemblers) pulled out of the assembly language market and began
maintaining their tools for their C/C++ compiler users, (2) the
ascendence of OSes such as Linux for which there were no high-level
assemblers.

In the vacuum created by Microsoft and Borland leaving the commercial
market, several hobbyist assembler projects sprang up. Of course, the
grand-daddy of them all was Gas, but Gas is a special case as it was
written to process the output of GCC, not as a general-purpose assembly
language development tool. In the middle to late 1990s, the NASM
project was initiated to create a portable "Intel-like syntax" ["like"
is my addition, the original claims were "Intel syntax" but the actual
product falls far short of this) that would run under multiple OSes (in
particular, Windows and Linux). In addition to NASM, several other
hobby-level assembler projects have been undertaken, a small sampling
of the products includes FASM, GoAsm, SpAsm/RosAsm, YASM, NBASM,
OSMPLAY, and several others that I've undoubtedly missed.

Next to FORTH, assemblers are among the simplist compiler products one
can create. Specially, it doesn't take an incredible amount of training
or experience for a hobbyist to crank out an assembler (as it does,
say, for a HLL compiler like a C compiler). But there is one catch to
this statement -- it's really only true for *traditional* style
assemblers. If your assembly language is fairly complex, and the Intel
Syntax assembly language is, or if you've got a high-level assembler
such as MASM or TASM, then it is *no* simple task to create an
assembler for these languages. In some respects, it's just as much work
as a compiler. Certainly, it's an *order of magnitude* more work than
cranking out the code for a simplistic "traditional" assembler.

The truth is, most "hobby-level" assembler projects (not all, but
certainly most) are not written by people who know how to crank out
compilers. NASM is the prototypical case -- an assembler cranked out by
a couple of hobbyists who'd never really done that sort of thing
before. Though it's an extreme example, the SpAsm/RosAsm assembler
demonstrates this in spades -- it was written by a *carpenter* who
hadn't messed with computers in over 30 years when he decided he was
going to write his assembler. It should come as no surprise that
hobbyists writing such assemblers aren't *really* in a great position
to know how to implement all the advanced features found in an
assembler like MASM or TASM. So after they've spent a couple of years
of their life writing their assembler, they introduce it to the
marketplace and more often than not, the response is a big "ho-hum".
After all, who is interested in using a compiler that has a subset of
the features found in the industry standard products? Where these
hobbyist endeavors have succeeded has been by providing features that
are unique and useful. NASM has succeeded, for example, because it is
so portable and is included by just about every Linux distribution out
there. FASM has succeeded because it is very fast, has a syntax that is
similar to NASM's (allowing NASM users to easily switch over), and it's
also quite portable. The HLA (high-level assembler) has succeeded
because of the pedagogical material available for it ("The Art of
Assembly Language").

But "success" is a relative term. The bottom line is that even though
MASM is no longer commercially supported, you *can* download it for
free from the Microsoft Web site and the MASM user base still
constitutes about 80-90% of the active assembly language programmers
out there. And it's not likely that this figure will change radically
in the immediate future.

Now *most* assembler authors don't really care. The NASM authors, for
example, have long since departed and have left their product in the
hands of the community (meaning we've not seen any *unified* builds of
the project in a while); Tomasz, the author of FASM, is happy off doing
his own thing; Jeremey, the author of GoAsm is off doing his own thing,
etc.

The one *big* exception is Rene ("Betov") Tournois, the author of
SpAsm/RosAsm. He is a nutcase that believes that by writing an
assembler he can bring the evil "Microsoft empire" down. He has created
this little fantasy that he calls "the assembly rebirth", which is that
someday soon, all HLL programmers will give up their HLLs and switch
over to doing all their programming in assembly language. Using HIS
assembler, of course. The only problem is that very few people are
buying into his little fantasy. He keeps blaming the lack of progress
on this front on a lot of different things, but the bottom line is that
he has a third-rate tool that any professional programming would
immediately dismiss (for example, it doesn't support separate
compilation and static linking -- it is strictly a "load and go"
assembler, to use IBM terminology). Rene has taken his lack of success
rather hard -- over the past seven years that he has been developing
his product, he's managed to attract about 87 members to his support
forum. This lack of success has left him very bitter, so to compensate
for his failings he has chosen to lash out at other products, their
developers, and their users.

Rene's most basic premise is this: as his product is just a simplistic
assembler, and he doesn't have the experience to develop a complex
product that can compete with "the big boys", he has decided to engage
in a disinformation campaign whereby he claims that any product that
has advanced features isn't a "true" assembler. The idea being that if
people want to learn assembly language, they should use *HIS*
assembler, which is a "true" assembler, rather than use one of the more
advanced products like MASM, TASM, or (especially) HLA.

Now if Rene had been *clever* about his disinformation campaign, he
might actually have been successful. But Rene has a very caustic
personality and he manages to insult just about everyone. Even those
who agree with him often have a hard time supporting his positions. As
a result, Rene's arguments often backfire, and he winds up chasing
people *away* from his product. Worse still, his comments tend to chase
people *completely away from assembly language*. What a great way to
run the "assembly rebirth", eh?

When Rene (and a few of his disciples) aren't around here, you won't
find too many people arguing about what is and what is not an
assembler. It's actually a nice and civil place where people discuss
assembly language programming. But as long as Rene and his crowd are
around, and people attempt to discuss nifty assembly language features
found in products like HLA, MASM, and TASM, you'll continue to hear
these never-ending debates around here.


> However, if
> one wants to point to an 'authority', I would point to IBM. They produce a
> High Level Assembler (HLASM) for their mainframe - which has been around for
> about 15 years, and is based upon an assembler that has likely been around
> longer than many who read this group (as well as the authors of many
> 'definitive' books on the subject). It has high level constructs (IF, DO,
> etc), and yet is an assembler. It also has conditional assembly statements
> that allow one to tell the assembler whether to include instructions in the
> object code or not based upon various criteria, and a macro facility that is
> quite powerful. And, oddly enough, it will assemble without any problems
> source code written for S/360 computers from the '60s, before there was a
> high level assembler.

Don't worry. If Rene were writing an S/3x0 assembler, you'd be hearing
about how HLAsm is not a true assembler, too. Rene constantly reminds
us that professionals and academians don't know anything about what
assembly language is. Only the "hobbyists" such as himself truly
understand the nature of assembly language and what is an assembler.

Heck, the fact that HLAsm supports static linking (forget the HLA
stuff) is enough for Rene to claim it's not a true assembler :-)


>
> The fact that an assembler will accept 'higher level' constructs doesn't
> make it a compiler any more than accepting assembler statements makes a
> complier an assembler, and just like putting inline assembler into a C
> program doesn't make it an assember module, having a high level construct
> (which the assembler breaks down into assembler instructions in any case) in
> an assembler module doesn't make it a 'higher level language'. That is just
> plain ludicrous - and argumentative (purists - bah! A pedant by any other
> name...)

Well, other than the fact that the class "assembler" is a subset of the
class "compiler", you're right on the money.

>
> Sounds like people simply like to dig their heels into the sand and argue
> for the sake of arguing.

It's more basic than that. You've got Rene trying to promote his vision
to the world. And people aren't buying it, so he argues all the louder.


> IBM allowed conditional assembly and macro
> facilities (which allowed you to write higher level constructs) long before
> any of the current ISAs were even pencil scratchings on napkins. Argue
> with them about whether a high level assembler exists or not.
> http://www-306.ibm.com/software/awdtools/hlasm/
>
> Have fun kids...

Trust me, if Microsoft weren't the current "evil empire", I'm sure Rene
would be arguing about bringing down IBM. I seriously doubt he'd give
IBM any more leeway than Microsoft in terms of defining what an
assembler is. Rene is an anarchist and respects no authority other than
his own.

:-)
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Your opinion on the Agner fog manuals.
    ... Perhaps the fact that those "advanced assembly language programmers" ... Boy, you're really stuck on that *one sentence* in the documentation, ... Try searching for information about the LISA assembler sometime. ...
    (alt.lang.asm)
  • Re: Teaching (and Learning) Assembly Language, Part 2
    ... individual's needs when learning assembly language. ... much in the way of software development tools, ... limitations of a "source editor" provided with an assembler that forces ... the "assembly programmers" could get up to speed faster ...
    (alt.lang.asm)
  • Re: the quality of assembly language code
    ... Intel's compiler is supposed to ... I have found that I prefer 'C' and assembler roughly in inverse ... >> code than human beings writing raw assembly language. ... > assembly programmers and compilers. ...
    (comp.lang.asm.x86)
  • comp.lang.asm.x86 - Frequently Asked Questions - general 2
    ... x86 Assembly Language FAQ - General Part 2 of 3 ... Accessing 4 Gigs of Memory in Real Mode ... Changing the value of a segment register results in that segment's entry ... This tutorial is designed specifically for the cheap assembler ...
    (comp.lang.asm.x86)
  • x86 Assembly Language FAQ - General Part II
    ... x86 Assembly Language FAQ - General Part 2 of 3 ... Accessing 4 Gigs of Memory in Real Mode ... Changing the value of a segment register results in that segment's entry ... This tutorial is designed specifically for the cheap assembler ...
    (comp.lang.asm.x86)