HLA History
From: Randall Hyde (randyhyde_at_earthlink.net)
Date: 02/05/05
- Previous message: Evenbit: "Re: Movies for Computer Geeks"
- Next in thread: Betov: "Re: HLA History"
- Reply: Betov: "Re: HLA History"
- Maybe reply: Annie: "Re: HLA History"
- Maybe reply: Randall Hyde: "Re: HLA History"
- Maybe reply: NoDot: "Re: HLA History"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 05 Feb 2005 20:56:45 GMT
The Self-proclaimed "assembly language historian"
(Rene, Tournois, AKA "Betov") is at it again,
making up stories about the history of the
High-Level Assembler. Obviously to anyone who has
been on this board for any amount of time, this
crap is all propaganda that Rene spreads in order
to further his own concept of the "Assembly
Rebirth" (based on his own product, RosAsm, of
course).
Quite honestly, Rene's concept of the "assembly
rebirth" is a non-starter and the popularity
(i.e., complete lack thereof) of RosAsm pretty
much proves that his outdated concepts aren't ever
going to succeed.
However, HLA *has* been around long enough now
that many people frequenting this newsgroup have
come along well after HLA's creation and rise in
popularirty. Such people may be completely unaware
of HLA's history and allowing Rene's biased
remarks to go unchallenged does a disservice to
assembly language in general. Therefore, I feel
it's important to write a short essay that
describes HLA's conception, design, and history.
Mind you, this is from the person who *invented*
the language and has supported it for almost eight
years now. Other people can make all the claims
they want about HLA's intentions and what-not; but
they weren't the ones who created, designed, and
implemented the language. THEY WEREN'T THERE. As
such, they aren't in as good a position to make
claims about the intent of the language or report
on its history.
I will also take this opportunity to dispell a
couple of myths about HLA and its design.
----------------
In the Beginning
----------------
Between the years of 1989 and 2000 I taught
assembly language programming at two separate
universities: Cal Poly Pomona and UC Riverside
(myth #1: I still teach assembly language; I do
not). For the first couple of quarters at Cal Poly
Pomona, I attempted to use some existing 8088
assembly language textbooks, but I was not happy
with them. To improve the courses I was teaching,
I started working on my own set of notes for the
classes and I had the school's reprographics
department copy them for my students. I entitled
this pile of notes "Programming the IBM PC using
8088 Assembly Language." Over the next 4-5 years,
I expanded and refined these notes. Eventually,
these notes grew to nearly 1,500 pages in length
(though I generally used an abridged version in my
courses).
These notes taught 16-bit 8088 assembly language
programming under MS-DOS. During the time from
1989 to 1995 I learned quite a bit about teaching
assembly language programming to students. I
discovered what worked well and what did not. I
also learned which areas the students had problems
with, and which areas most of them could breeze
through. I tried lots of different ways of
presenting the material -- some worked really
well, some were asbysmal failures. The bottom
line, however, is that during this time I learned,
quite well, what works and (just as importantly),
what doesn't work when teaching students assembly
language programming. This experience cannot be
underestimated. All too often you'll find people
making claims like "this is how assembly ought to
be taught" or "no one can learn assembly that
way." I have to laugh. Most of these people have
only taught a single person assembly language --
themselves -- and they are in no position to make
claims about how assembly should and shouldn't be
taught. Assuming that a pedagogical (educational)
scheme that works for *you* will work for everyone
else is a very dangerous thing to do. A perfect
example of this would be *me*. When I first
started teaching assembly language programming, I
shared many of the mistaken beliefs about teaching
assembly that many people state around here.
There's nothing like working with several
classrooms full of students to quickly discover
that the way you *felt* assembly language should
be taught just doesn't cut it in the real world.
Oh, no question you can find at least a *few*
other people who work well with the schemes you've
come up with, but if you're interested in teaching
typical programmers (or, at least, typical
students) assembly language programming, you
quickly discover that you need to adjust your
ideas to best serve your clients (students).
This is what I largely did over the 1989-1995 time
frame.
Though I probably had far more mistakes than
successes during this time, one *huge* success I
had was the "UCR Standard Library for 80x86
Assembly Language Programmers." This was a library
package I provided with my notes "...Using
8088..." to help remove a huge roadblock to
learning assembly language programming: the lack
of I/O capabilities, numeric conversions, and
other common programming tasks that are taken for
granted in HLLs but missing in assembly. Students
were easily 3-4 times more productive in the
assembly courses once I started introducing the
"UCR Stdlib" into my courses. Without hesitation,
you can automatically assume that anyone who
claims "libraries have no place in assembly
language programming" just doesn't have a clue
whatsoever at all.
------------------
Motivation for HLA
------------------
Until 1995, working under DOS using 16-bit
assembly language statements was quite reasonable.
Windows, such that it existed at the time, was
still a 16-bit platform and DOS still ruled.
However, with the impending release of Windows 95,
it was clear to me that DOS' days were numbered
and it was time to update my notes to support
Windows and 32-bit programming.
(side note: earlier in the decade, around
1992-1994, I'd actually shopped my notes, "How to
Program the IBM PC Using 8088 Assembly Language",
around to several textbook publishers. This time
frame was probably the height of the "assembly is
dead" era. Comments on the book ranged from "no
one uses this anymore and schools aren't going to
be teaching it anymore" to "The Intel x86 is dead,
if you're going to publish an assembly book it
needs to cover the RISC chips that are replacing
the 80x86". Given the lack of interest in the
textbook, I renamed those notes "The Art of
Assembly Language Programming", published them
on Webster in HTML format, and the rest is
history.)
To create a new version of my notes, the first
thing I decided to do was base the new book around
a powerful set of library routines. As I've
already mentioned, "The UCR Standard Library for
80x86 Assembly Language Programmers" was easily
one of the most powerful pedagogical tools I'd
discovered while teaching assembly language at the
university level. So in early 1995 I began work on
Version 2.0 of "The UCR Standard Library for..."
I intended this library package to be very
powerful, very complete, very easy to use, and
very robust. So I (and several students working in
independent project courses) began writing the
code for this package. To this day, I'm quite
amazed at what we were producing way back in 1995
using MASM 6.1. Here is my favorite example of
what you could achieve in MASM using this library
package:
var
enum colors,<red,green,blue>
colors c1, c2
endvar
Main proc
mov ax, dseg
mov ds, ax
mov es, ax
MemInit
InitExcept
EnableExcept
finit
try
cout "Enter two colors:"
cin c1, c2
cout "You entered ",c1," and ",c2,nl
.if c1 == red
cout "c1 was red"
.endif
except $Conversion
cout "Conversion error occured",nl
except $Overflow
cout "Overflow error occured",nl
endtry
CleanUpEx
ExitPgm
Main endp
Unfortunately, the UCR stdlib v2.0 project failed.
First of all, MASM v6.1 had several defects, and
minor version changes (e.g., v6.11a to v6.11d)
were creating problems that broke the existing
macros in the UCR stdlib. While that problem
could have been gotten around, there was a more
fundamental problem -- the result wasn't very
robust. If you had a syntax error when using one
of the macros in the library, the error messages
that MASM produced during assembly were completely
incomprehensible, especially to students who
wouldn't know assembly langauge, much less the
intricasies of the MASM/UCR stdlib macro package.
As much as I hated throwing away about 4-6 months'
of work, I made the hard decision to do exactly
that. MASM just didn't have the power I needed to
pull off the task I wanted to do.
(sidenote: Steve Hutchessen is following a very
similar path these days in his MASM32 package --
creating a set of macros that help you emulate
HLL-like statements in assembly language. No doubt
Steve will be far more successful than I was for a
couple of very important reasons: (1) MASM is far
more stable these days, (2) his package is
intended for more-or-less experienced assembly
programmers rather than students).
In addition to the improved standard library
package, another facility of MASM v6 I wanted to
take advantage of in my assembly courses was the
new "high-level assembly" statements found in
MASM.
(sidenote: Rene Tournois likes to claim that the
32-bit edition of "The Art of Assembly" was
written to support HLA. This is complete B.S. The
Art of Assembly existed long before HLA was even a
dream of mine. The decision to move to 32-bits
with AoA was made because it was obvious, in 1995,
that 32-bit Windows programming was the wave of
the future. Originally, the 32-bit edition of "Art
of Assembly" was going to use MASM. However,
MASM's limitations prevented this; so I created
HLA in order to support the "Art of Assembly", not
the other way around as Rene likes to claim.)
About this time, I was talking with my Department
Chair about the assembly language course. We were
identifying some of the problems that students had
learning assembly language. One problem, of
course, was the paradigm shift- learning to solve
problems using machine language rather than a high
level language. The second problem we identified
is that students get to apply very little of what
they've learned from other courses to the assembly
language class. A third problem was the primitive
tools available to assembly language programmers.
Energized by this discussion, I decided to see how
I could solve these problems and improve the
educational process.
Problem one, the paradigm shift, had to be handled
carefully. After all, the whole purpose of having
students take an assembly language programming
course in the first place is to acquaint them with
the low-level operation of the machine. However, I
felt it was certainly possible to redefine parts
of assembly language so that would be more
familiar to students. For example, one might test
the carry flag after an addition to determine if
an unsigned overflow has occurred using code like
the following:
add eax, 5
jnc NoOverflow
<< code to execute if overflow occurs >>
NoOverflow:
Although this code is fairly straight-forward, you
would be surprised how many students cannot
visualize this code on their own. On the other
hand, if you feed them some pseudo code like:
add eax, 5
if( the carry flag is set ) then
<< code to execute if overflow occurs >>
endif
Those same students won't have any problems
understanding this code. To take advantage of this
difference in perspective, I decided to explore
changing the definition of assembly language to
allow the use of the "if condition then do
something" paradigm rather than the "if a
condition is false them skip over something"
paradigm. Fundamentally, this does not change the
material the student has to learn; it just
presents it from a different point of view to
which they're already accustomed. This certainly
wasn't a gigantic leap away from assembly language
as it existed in 1996. After all, MASM and other
assemblers were already allowing statements like
".if" and ".endif" in the code. So I tried these
statements out on a few of my students. What I
discovered is that the students picked up the
basic "high level" syntax very rapidly. Once they
mastered the high level syntax, they were able to
learn the low-level syntax (i.e., using
conditional jumps) faster than ever before. What I
discovered is something that Nicoderm CQ is
pushing for their smoking cessation program:
"learning assembly language in graduated steps
(from high level to low level) is easier than
going about it `cold turkey.'"
The second problem, students not being able to
leverage their programming skills from other
classes, is largely linked to the syntax of Intel
x86 assembly language. Many skills students pick
up, such as programming style, indentation,
appropriate programming construct selection, etc.,
are useless in a typically assembly language
class. Even skills like commenting and choosing
good variable names are slightly different in
assembly language programs. As a result, students
spend considerable (unproductive) time learning
the new "rules of the game" when writing assembly
language programs. This directly equates to less
progress over the ten week quarter. Ideally,
students should be able to applying knowledge like
program style, commenting style, algorithm
organization, and control construct selection they
learned in a C/C++ or Pascal course to their
assembly language programs. If they could, they'd
be "up and writing" in assembly language much
faster than before.
The third problem with teaching assembly language
is the primitive state of the tools. While MASM
provides a wonderful set of high level language
control constructs, very little else about MASM
supports this "brave new world" of assembly
language I want to teach. For example, MASM's
variable declarations leave a lot to be desired
(the syntax is straight out of the 1960's). As I
noted earlier, as powerful as MASM's macro
facilities are, they weren't sufficient to develop
a robust library package for my students. I
briefly looked at TASM, but it's "ideal" mode
fared little better than MASM. Likewise, while
development environments for high level languages
have been improving by leaps and bounds (e.g.,
Delphi and C++ Builder), assembly language
programmers are still using the same crude command
line tools popularized in the early 1970's.
Codeview, which is practically useless under
Windows, is the most advanced tool Microsoft
provides specifically for assembly language
programmers.
It was fairly clear to me that teaching assembly
language this new way was going to require a
brand-new set of tools. Trying to graft these new
features onto MASM (or any other assembler) via
macros just wasn't going to work. I decided the
first order of business was to create a new x86
assembly language and write a compiler for it. I
decided to give this language the somewhat
less-than-original name of "the High Level
Assembler," or HLA (IBM and Motorola both already
have assemblers that use a variant of this name).
-------------------------------------------------
Design of the HLA Syntax and HLA's Implementation
-------------------------------------------------
So what should this new assembly language look
like? My first thought was to make it look as
much like MASM as possible. But after a few
minute's thought, I realized that the MASM
language (based on the earlier Intel ASM86
language/syntax) was over 15 years old and was
carrying around a lot of confusing and unnecessary
baggage. Rather than continue with the grand
kludge I originally had in mind, I decided to
create a new assembly language expressly for
teaching assembly language programming.
Now keep in mind that my decision to do this was
in late 1995 (shortly after Windows 95 first
appeared). This was well before *most* of the
assemblers in common use today (e.g., FASM, NASM,
GoAsm, and so on) were even dreamt up (not that
any of these would have worked for me, but just to
put things in historical perspective). At the
time, there was just MASM, TASM (which hadn't
caught up to MASM in terms of HLL-like features
yet), Gas (unfit for human consumption), and a few
other minor products.
My original plan was to create a "preprocessor"
for MASM that would recognize certain keywords in
the assembly file and pass everything else
straight through. Unfortunately, the desire to
create a *robust* system eliminated the
preprocessor approach -- I needed to write a full
compiler for this new assembly language.
(sidenote: for those who don't understand the
difference between a preprocessor and a compiler,
here's the main difference - a compiler translates
one source language into a completely different
language. A preprocessor, OTOH, processes language
statements that are embedded in another language
[e.g., much like C-preprocessor statements are
embedded in C source files] while passing
statements it doesn't recognize on through to the
final language. If you hear anyone calling HLA a
"preprocessor" [or "pre-parser", whatever that
means] or a "text processor", it's pretty clear
they haven't got a clue what they are talking
about -- just ignore them, their ignorance is
coming through loud and clear.)
For the prototype, I originally decided on a
"compiler" implementation for HLA that generated
assembly language source code as output (requiring
further processing by MASM) rather than
assembling directly to machine code as is common
for an assembler. This decision was made in order
to simplify the implementation of HLA. The fact
that it produced human-readable output made it
much easier to verify the code generation from the
compiler than had I emitted object code directly.
Though this was the original reason for choosing
to emit MASM code, it turns out that there were
other benefits as well. In particular, portability
to Linux was easily achieved because of this
approach.
I originally choose to use MASM because HLA was
intended for use at Universities and
just about every university teaching assembly was
using MASM at the time. In particular, MASM was
the assembler in use at UC Riverside where I was
teaching at the time. Of course, the fact that I
had written *two* books on MASM at that point (The
Art of Assembly and the MASM Bible) probably
factored into this, as well. At the time, MASM
was still a commercial product that you could
purchase from Microsoft and was, by far, the most
popular assembler out there (TASM was a distant
second). Using MASM was a no-brainer.
Once HLA was available in late 1999 and early
2000, a few problems with MASM output surfaced.
First, MASM modules wouldn't link with Borland's
Delphi very well. So I put in some changes that
would allow HLA to emit TASM compatible code (TASM
and MASM are very close, but not identical by any
means). In 2001, requests for a Linux version
started getting louder and louder. Given HLA's
internal structure, there was no way I could
coerce the MASM output into Gas form (e.g., the
HLA code generator wouldn't allow the output of
operands in the "src, dest" form, even if this was
the native format in the HLA source language
itself). However, with the ".intel_syntax"
directive found in Gas 2.10 and later, it became
possible to create Gas output from HLA that could
be processed under Linux. This lead to the
development of a Linux version of HLA.
Though I personally have no problems with
Microsoft products and the use of MASM to process
HLA output, by 2002 it was quite clear that a
small group of individuals would not consider
using HLA (under Windows) as long as it required
the use of MASM as the native code generator. So I
studied the possibility of creating a NASM output
module. Alas, NASM's syntax and lack of
optimization features made it difficult, if not
downright impossible, to convince HLA to produce
NASM output. Fortunately, another free alternative
appeared: FASM. I rewrote the HLA code generator
to include FASM output to create a "free" version
of HLA (HLA itself, of course, is public domain
and is the epitome of freedom, but the requirement
that it use a proprietary product, MASM, was a
problem for some people). At the time, I also put
in some code to support a new version of NASM that
supported displacement optimization, but I
abandoned the project when it became clear it
would be a huge time sink for very little payback.
Today, HLA supports MASM, TASM, Gas, and FASM
output and runs under Windows and Linux.
------------------------------
HLA's Prototype Implementation
------------------------------
Though I had a fairly good idea about the basic
structure of the HLA language I wanted to adopt,
it was clear to me, then, that the language would
definitely evolve over time. So it didn't make a
lot of sense to try and write a "commercial
quality" version of the compiler until I'd played
around with the language definition a bit.
Therefore, I decided to prototype the language
first and then write a "commercial quality"
version of the compiler for HLA v2.0. As I was
teaching compiler construction at UC Riverside at
the time, it made a lot of sense to use the
compiler-construction tools (FLEX & Bison) that I
was using in my compiler courses to write the
prototype for the HLA v1.0 language.
Using Flex/Bison turned out to be a big mistake
for several reasons, alas, It wasn't until I'd
written about 50,000 lines of code that it became
obvious that Flex/Bison was a poor choice. By
then, it was too late to switch. And given that I
was creating a prototype language anyway, I
gritted my teeth and kept at it.
(sidenote: VHLLs, like Flex and Bison, are
supposed to let you create an application with far
less effort than with traditional langauges. While
Flex & Bison are great for student compiler
projects, they are unsuitable for large projects
like the HLA compiler; the biggest reason that
Flex and Bison are unsuitable, however, is due to
Bison's [famous] inability to do decent error
reporting and recovery -- something that's very
important in an educational environment.)
Originally, I figured it would take about a year
to write HLA v1.0, a year of usage to shake out
the language features, and then another year or
two to write HLA v2.0 (the commercial quality
version). Like most decent sized software
projects, the scope of HLA rapidly expanded and
the language grew much larger than I had
originally anticipated. I spent three years (not
full time, mind you) from 1996 to 1999 working on
HLA v1.0. HLA v1.0 made it's first public
appearance in one of my UC Riverside assembly
courses in September, 1999.
-------------
Goals for HLA
-------------
I had two major design goals for the HLA language
itself: (1) To introduce a simplified syntax that
beginning assembly language students could easily
learn; and (2) to provide a *powerful* assembly
language that would let me overcome the
limitations of MASM (that prevented the creation
of the UCR stdlib v2.0). Given that MASM, at the
time, was the most powerful assembler available,
my plan was simply to create the world's most
powerful assembler. Interestingly enough, despite
the plethora of assemblers that have appeared
since my initial design for HLA, MASM is still
more powerful than all the other x86 assemblers
(with the obvious exception of HLA).
Perhaps the most controversial component of HLA's
design has been its novel syntax. Originally, I
(foolishly) assumed that when existing assembly
programmers saw how much more powerful HLA was
than existing assemblers, they'd switch (in
droves) to HLA. It only took about three weeks
after the release of HLA v1.1 on the internet to
convince me that this was never going to happen.
HLA was a radical departure (syntax-wise) from the
existing Intel syntax (embodied by MASM, TASM, and
the up-and-coming NASM) and people were about as
likely to change to HLA as they were to Gas
(meaning they'd change only if forced to do so).
Rather than fret about this, I simply realized
that HLA was not created as a tool for people who
were already accomplished assembly programmers --
it was intended as a tool for teaching beginners
assembly language programming. So I immediately
gave up on try to convert the existing programmers
over to HLA and concentrated on the much bigger
group of beginners who didn't already know
assembly language.
A reasonable question to ask is "Why (or how) is
HLA's syntax better for beginners than traditional
Intel syntax or similar syntax?" Well, this all
goes back to my experiences teaching assembly
language between the years 1989 and 1999 (when HLA
v1.0 first appeared).
Let's consider what is, unquestionably, the most
controversial aspect of HLA's syntax: the
"src,dest" operand organization. Despite certain
unethical individual's claims that this was done
to "lock people into HLA syntax" or to "swindle"
people, this syntax was chosen for one very good
reason - it is more *natural* to beginners. This
isn't a statement I've picked out of the air. I
came to this conclusion based on the fact that one
of the *most common* mistakes students were making
in the laboratory when using MASM was reversing
their operands. Given the fact that most other
assemblers for other processors (at the time) used
a "src, dest" operand ordering, it made sense to
use this approach. Experiences in the classroom
once I introduced HLA confirmed that this was a
*very* good approach. Believe me, the decision to
swap the operand ordering was not taken lightly; I
knew when I made this design decision early on
that it would not be well-received by the existing
x86 assembly community -- one need look on farther
than the Gas assembler (which also used a
"src,dest" operand ordering at the time), and
listen to the complaints that people had about it,
to realize this. However, as I said, my goal was
not to please the existing crowd of assembly
programmers, but to teach students assembly
language programming as efficiently as possible.
Another complaint people have about HLA is its use
of "functional notation" for instructions (that
is, using parenthesis to surround instruction
operands). At least one individual tries to argue
that HLA is really a "high-level language" on the
basis of these parenthesis! (demonstrating clear
ignorance on the part of that person what
constitutes a high-level versus low-level
language). Unlike the operand ordering, using
functional notation was a no-brainer. It's *much*
better and easier to read than standard assembly
language syntax. Why? Because the syntax *is*
similar to that for HLLs that the student already
knows (like C/C++, Java, or Pascal). This means
that they can employ formatting tricks they've
learned in their HLLs to write readable HLA
programs. This reduces the amount of material the
students have to learn (e.g., they don't have to
learn a new way of writing readable programs when
learning assembly language), thus freeing up time
for them to spend learning assembly language
programming. Some people foolishly believe that
reducing the number of characters one has to type
makes a program more readable. Software
engineering study after software engineering study
tells us this isn't true. Consider the following
kludge in RosAsm that results from its "simplified
syntax":
mov D$EAX 1 // Moves 1 into the dword pointed
// at by EAX
mov D$EAX -1 // Syntax error, thinks there is
// a missing operand
You have to write the second statment thusly:
mov D$EAX (-1)
(or use some other syntactical trick to convince
RosAsm that there are really two operand here, not
just one).
People complain about parenthesis in HLA, but
swear that adding brackets is a *good* idea. E.g.,
in MASM you can write:
mov eax, SomeVar
But in FASM, NASM, GoAsm, etc., you have to write
something like:
mov eax, [SomeVar]
Would somebody please explain how this makes
things more readable, but adding parentheses does
not?
There are some advanced technical reasons for
HLA's syntactical choices (things like instruction
composition), but the bottom line is that HLA was
created as a tool for teaching assembly language
programming, HLA's syntactical similarities with
HLLs makes it far easier for someone to learn
coming from a HLL background (e.g., most
students), so that's sufficient reason for HLA's
syntactical differences with "traditional"
assemblers.
----------------------------
The Art of Assembly Language
----------------------------
One big problem with HLA v1.0, when it first
appeared, is that "Art of Assembly" (as it existed
at the time) was written for MASM. The whole point
of creating HLA was so that I could write a 32-bit
version of AoA for Windows. AoA/32-bits couldn't
be written before HLA v1.0 was complete
(obviously), but in late 1999 I found myself in
the position of having an assembler to use in my
courses, but no book to use for that course. So in
early 2000, I began working on the 32-bit edition
of AoA, fulfilling the reason I created HLA in the
first place.
The first few chapters of the 32-bit edition of
AoA appeared in the first quarter of 2000, rapidly
followed by the rest of the book. By the end of
2000, the 32-bit edition was pretty much in place
on Webster. Because of AoA's popularity (16-bit
edition), the 32-bit edition rapidly became
successful as well, and the popularity of HLA rose
with it. In the middle of 2001, I was approached
by No Starch Press about getting AoA/32 published
(unlike my previous experience, the publisher
sought me out this time around). When AoA finally
appeared in print about a year and a half later,
the popularity of HLA was pretty much assured.
AoA certainly won't be the last book I write that
teaches assembly language programming using HLA.
Already my book "Write Great Code, Volume I:
Understanding the Machine" has appeared which
uses HLA examples (as will Volumes II, III, and IV
when they appear). "Windows Programming in
Assembly Language" is another project of mine that
uses HLA (and work will continue on it when HLA
v2.0 is a little farther along). The HLA platform
is great for teaching assembly, and I intend to
use it for a wide range of books, articles, and
web pages on the subject.
--------
HLA v2.0
--------
At one time, I had this cute little "road map" to
HLA on Webster. It stated when HLA v2.0 would
appear, when HLA v3.0 would appear, and the
features these versions would have. Needless to
say, the schedules mentioned there were a bit
optimistic (by the original roadmap, we should be
at HLA v4.0 or later by now).
Why the delay?
Well, there are several reasons: producing output
for different assemblers consumed about a year,
porting to Linux took about the same amount of
time, and the HLA language is *much* bigger today
than I envisioned when I first wrote that roadmap.
Oh, and don't forget, I've written about four
books since I published that roadmap.
Though HLA is about three years late at this
point, work *is* proceeding on it. Today
(2/5/2005), for example, I'm working on hundreds
of little test programs that form a regression
test suite on the declaration sections of the HLA
v2.0 compiler. At this time, almost all of the
declaration code has been written and a fair
amount of it has been tested (still a lot of
testing to do, but the only major coding in the
declarations component left to do is to implement
"templates" [a pattern matching facility] in the
compile-time language).
HLA v2.0 addressing many of the problems that
exist with HLA v1.x, including:
1. Far better error detection, reporting, and
recovery.
2. Faster performance, Currently, HLA's compile
speeds when processing declarations range from
250,000 lines/sec to 1,000,000 lines/sec on a 3.06
GHz laptop (depending, of course, on the
complexity of the statements you feed the
compiler). While I expect the compile rate to drop
when the multi-pass optimization phase is added to
the assembler later on, it's pretty clear that the
current result is several orders of magnitude
faster than HLA v1.x.
3. Lots of syntactical kludges have been cleaned
up in the language.
4. HLA v2.0 is written in HLA, allowing anyone who
knows HLA to work on the compiler source files.
5. HLA v2.0 will emit object code directly
(PE/COFF and ELF files). HLA v2.0 will have an
extensible code generator allowing individuals to
add their own code generators for different OSes
and other purposes. HLA v2.0 will provide code
generators that disassemble the internal machine
code into source code for existing assemblers like
MASM and Gas. Unlike HLA v1.x, however, HLA v2.0
will not require the use of some other assembler
to produce object code (except on weird OSes).
HLA v2.0 will probably have a NASM code generator
(finally), as optimization will be handled by HLA
rather than by the final assembler.
6. HLA v2.0 will be ported to several additional
OSes (including BSD and Solaris). Of course, it
will run under Linux and Windows (and Win32
compatible OSes, e.g., ReactOS) as well. Support
for some additional OSes (such as QNX and BeOS)
may be provided via the use of an assembler such
as Gas or NASM to handle conversion to the object
code format required by that particular OS (and
calls to C standard library routines to implement
the HLA stdlib rather than low-level machine
language calls [which aren't even available on
some OSes such as QNX]).
7. Certain language features that couldn't be
implemented in HLA v1.x because of Flex/Bison
limitations (e.g., "templates") will appear in
HLA v2.0
The release of HLA v2.0 certainly isn't imminent,
so don't get your hopes up just yet. As I've
mentioned, the declaration processing code
(probably about half the compiler) is almost
written and tested. Templates are the only major
component left to write in the declaration section
(at which point I'll release the "Assembler
Developer's Kit", ADK v1.0 containing the
declaration code).
The next step will be to compile machine language
statements and translate them into an abstract
syntax tree form. Then an optimizer has to be
written to optimize branch displacements and
operand sizes. Finally, the native code
generators need to be written.
Watch this space for future details.
Cheers,
Randy Hyde
- Previous message: Evenbit: "Re: Movies for Computer Geeks"
- Next in thread: Betov: "Re: HLA History"
- Reply: Betov: "Re: HLA History"
- Maybe reply: Annie: "Re: HLA History"
- Maybe reply: Randall Hyde: "Re: HLA History"
- Maybe reply: NoDot: "Re: HLA History"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
