At some point I'm going to return to work on the HLA v2.0 system.
But I thought that regular updates on HLA v2.0 (and why it's not
coming along very rapidly) would be in order.

The big block on HLA v2.0 last year was a contract I signed in
May to produce a published version of "The Art of Assembly
Language". Between abridging the work (sorry, 1,500 pages
was a bit too much for the publisher, though the full electronic
version will still appear on the CD-ROM), merging the Windows
and Linux versions into a single edition, *lots and lots* of
proofreading, and other stuff, I was quite busy the remainder
of the year (in fact, I just shipped off approvals on the proofreading
of the appendicies a week ago; all that's left now is the index).
I know a lot of people are going to be excited to have AoA available
in hard copy form, so that's been my priority the past six months.

As I mentioned above, quite a bit of stuff had to be stripped out
of AoA to make it publishable. Using the electronic version as
a guide, the published version contains the material from Volume I,
a sampling of the material from Volume II (machine organization,
important stuff, but not really assembly language *programming*),
and probably about 80% of the material from Volumes III and IV
(reorganized quite a bit). It was a hard decision cutting out a lot of
the material on machine organization, but I had to chop the book
roughly in half (note: in published form, it will probably be longer than
750 pages because they're going to a smaller format than the
8-1/2"x11" pages that I used for the PDF files on Webster). Furthermore,
whenever you hear someone discussing a major benefit of learning
assembly language as being great knowledge to have in order to
write better HLL code, much of what they're talking about is the
machine organzation information you pick up while learning assembly.
To make a long story short, I had several hundred pages of "machine
organization" information laying around that got cut from AoA (actually,
it's on the CD-ROM, it was just cut from the printed edition). So I
convinced the publisher to do a second book entitled "The Things
You Need To Know to Write Great Code". I'm finishing off the very last
section of the very last chapter today and tomorrow (this is the first
draft, so there is still a lot of proofreading, etc., left to do). This book
will consume quite a bit of time over the next couple of months.
That, of course, will also delay serious work on HLA v2.0 for the time
being.

Of interest to this particular news board, I've also pretty much committed
to doing a "Windows Programming in Assembly Language" text. I'm going
to get started on that as soon as I make the first proofreading pass on
"Write Great Code". I'll probably start putting those chapters up on Webster
as I write them so interested indivduals can follow along during the book's
development (not to mention, I'll get lots of free proofreading :-)).

Another book project that *really* needs to get done is a "Universal
Guide to x86 Assembly Language" that provides a parallel reference
guide for several different popular assemblers. This will allow someone
who is reading HLA code, for example, to translate it to MASM, NASM, FASM,
Gas, etc., (or from any of these assemblers to any of the others).
Given the divergence of the x86 assembly language programming community,
this would be a good book to get out the door before the year is over.

I've also been play "rock star" a bit too much recently (I write Christian
Parodies of popular tunes and I've been writing lyrics, recording the songs,
and performing them at local churches; the recordings, especially, take quite
a bit of time; you can check out the parodies on Webster, just visit
http://webster.cs.ucr.edu/Page_Christian/index.html)


So those are the things lined up in front of HLA v2.0 at this point.
Oh, I forgot to mention, I've got a real job, too :-)
Fortunately, I don't have any kids...

Well, I've spent a lot of time discussing why I haven't been working on HLA v2.0
lately (and why I'm not going to get a whole lot done on it in the immediate
future), I guess I should express some optimism here. The AoA publication has
been rather critical, so I've been putting most of my effort into getting that ready.
I will not be devoting as much time to the next few book projects, so I'll be
able to get some "time slicing" in and start progressing on HLA v2.0 again.

Todate, the lexical analyzer is mostly complete and I'm working on the
expression parser (for constants and addresses). Quite frankly, it's been
so long since I've worked on HLA v2.0 that I'll have to spend about a week
refamiliarizing myself with the source code. When I get around to that,
I will start discussing some of the features that will be found in HLA v2.0
and what I hope to achieve. I will also start posting the HLA v2.0 source
code (written in HLA) on Webster so people who are interesting in learning
the source code can follow along from the beginning rather than get hit
with 100,000 lines of source code all at once. Naturally, I'll more than
welcome any help on the project, subject to the requirement that all
participants (who want me to include their code with the HLA release)
release their code to the public domain.

In any case, I've started this thread to begin discussing the available features,
report the status, and solicit suggestions for HLA v2.0
Randy Hyde
Posted on 2003-01-19 17:06:52 by rhyde
Of interest to this particular news board, I've also pretty much committed
to doing a "Windows Programming in Assembly Language" text. I'm going
to get started on that as soon as I make the first proofreading pass on
"Write Great Code". I'll probably start putting those chapters up on Webster
as I write them so interested indivduals can follow along during the book's
development (not to mention, I'll get lots of free proofreading :-)).


Will you use HLA for the examples in the book?
Posted on 2003-01-19 17:33:39 by Hiroshimator
Rock star huh ?

One of the things that gets asked on a regular basis is if there are any good books for people to learn 32 bit windows assembler and currently the answer is no so if your publisher can see a viable demand, a book of this type would be welcome by people who "like" to learn from books rather than picking it out in bits across the internet.

I am sure there are enough people around here who would be more than willing to lead you astray to get 32 bit windows assembler more widely known.

Funny, I have never heard of an assembler programmer who can sing before, must be the Webster influence. :tongue:

Regards,

hutch@movsd.com
Posted on 2003-01-19 18:18:49 by hutch--



Will you use HLA for the examples in the book?



Yes, of course.
Which points out the need for that "Universal Assembly Guide"
I was talking about :-)

The only viable choices for such a book would be MASM32 or
HLA (because of support for include files, high-level API
invocations, stuff like that). Naturally, I feel strongly about
HLA (having designed and implemented it myself) and, in
particular, I wrote HLA in order to provide a vehicle for teaching
assembly language programming (and not just "beginning"
assembly language programming, I'd point out).
Obviously, some might complain "But I don't know HLA and
you'd have a bigger market if you used MASM32."
This is true, but I'm somewhat afraid of supporting MASM
at this time because Microsoft's support for assembly
programming and MASM seems to be waning rapidly.
I know that HLA will be supported as long as I need it to
be supported for a book project like this one :-)
Randy Hyde
Posted on 2003-01-19 18:31:49 by rhyde
and what about making your examples as generic as possible? I know my old books supported masm, tasm and some other assembler (just to be sure I guess :grin: )
Posted on 2003-01-19 18:34:27 by Hiroshimator
All the great programmers are musical, except me,
pipe organs and all.
Posted on 2003-01-19 18:41:43 by Roy Cline

Rock star huh ?

One of the things that gets asked on a regular basis is if there are any good books for people to learn 32 bit windows assembler and currently the answer is no so if your publisher can see a viable demand, a book of this type would be welcome by people who "like" to learn from books rather than picking it out in bits across the internet.

I am sure there are enough people around here who would be more than willing to lead you astray to get 32 bit windows assembler more widely known.


One of the main reasons I'd wanted to get involved with this board
was specifically to learn more about Win32 Asm programming and have
a source of information where I could get help. I've gone through a lot of the
bits and pieces found on the net and I agree 100% that coming up with a
structured, coherent, pedagogical plan is difficult when learning the stuff
from the internet (indeed, once you go through Iczelion's excellent tutorial
series, I've found the best way to learn Win32 Asm programming is by
reading all the C books on the subject).

I've actually got a couple of books on Windows assembly programming,
but they're both Win16 based and spend most of their time discussing
how to write VxDs and Device Drivers in assembly language. While those
may have been interesting subjects seven years ago, the information is
basically useless today. I get a lot more out of Petzold's books than I
do out of those Windows assembly books.



Funny, I have never heard of an assembler programmer who can sing before, must be the Webster influence. :tongue:

Regards,

hutch@movsd.com


You make the assumption that I actually *can* sing :-)
Seriously, though, I started writing the parodies for entertainment
and for my Children's Church program I was working with two years
ago. I discovered real quick that a very large percentage of the
population can't read lyrics and imagine the melody and how the
parody lyrics would be sung. I tried putting up some music recordings
with a melody track for a while; although that was better, a lot of people
still couldn't figure out how the parody lyrics were supposed to be sung.
A little over a year ago, I recorded a CD full of the songs (about 22 of them)
and distributed the CD to several friends. Quite frankly, the vocal
performance was atrocious. But, at least, people could hear how the
songs were intended to be sung. After filling up five CDs with parody
recordings, I finally got sick and tired of embarrasing myself with these
recording attempts and I took a "beginning singing" class at the local
community college (in fact, I just finished the second six weeks of that
course in early December). So volumes six and seven of the series are
markedly improved (I just finished re-recording most of the songs on
Volume I and I've put the MP3s up on Webster). I've still got a *long*
ways to go before I'd ever reach "professional" calibre, but the vocals
are *vastly* improved over what I had before.

As far as HLA v2.0 is concerned, the good news is that I've nearly
recorded all the parodies I've written to date (I've written almost
160 of the parodies, I've probably recorded over 120 of them).
Other than the fact that volumes two through five need to be
re-recorded, I've just about finished that project and it's not going
to consume as much time as it has in the past.
Randy Hyde
Posted on 2003-01-19 18:44:59 by rhyde

and what about making your examples as generic as possible? I know my old books supported masm, tasm and some other assembler (just to be sure I guess :grin: )


Well, that's good advice for lots of reasons.

Obviously, most of the machine instructions will be trivially convertable
to other assemblers. "MOV( 5, EAX);" (and most assembly instructions)
is easy enough to convert to the syntax of your favorite assembler.
In those few instances where the conversion isn't obviously, well, don't
forget that HLA *is* a compiler and emits assembly source code for
further processing by an assembler like Gas, MASM, TASM, or FASM, so
the worst you would have to do is run the HLA examples through HLA
to see the syntax in your favorite assembler (someday, I may even finish
the NASM code generator, if I get the time).

There are only two things I plan on using in the examples that don't
translate directly (manually) to other assemblers.


(1) I will use HLA's HLL-like calling sequence quite a bit. MASM32 users
shouldn't have a problem with this since it's quite similar to INVOKE.
Of course, I will give examples of how to call the APIs manually
(because, quite frankly, the HLL-like calls aren't
always as efficient as they could be and although a slight inefficiency
in a Win32 call isn't going to be a terrible thing, because the calls are
so slow anyway, this *is* going to be an assembly book and not
pointing out the possible inefficiencies of the approach would be
weak).

(2) One advanced HLA feature I do intend to take advantage of
is HLA's "context-free macro" facilities. HLA's macros are great
for various types of calls that must always occur in pairs, like
BeginPaint and EndPaint, e.g.,

w.BeginPaint( hwnd, ps, hdc );

<<calls that reference the paint structure>>

w.EndPaint;

Using this macro facility achieves two things:
a. It saves a bit of typing because you don't have to supply the
device context handle in every painting call.

b. The painting calls (e.g., w.TextOut) are only "callable" between
the w.BeginPaint and w.EndPaint macro invocations (HLA enforces
this; of course, you could always call the Win32 APIs directly, but
it's kinda' nice that these macros do a little bit of error checking for
you).

At one time I was contemplating changing all the (horrible) names
for the Windows API and constants to better suit assembly language
programmers. However, no single text on Windows programming
in assembly language can cover all the information an assembly
programmer is going to need to know, so other than a few minor
differences (like the BeginPaint/EndPaint macros above, that the
text will go into great pains to develop and describe), I'm going to
stick with MS identifiers, regardless of how appropriate they are
(of course, there are a few conflicts with HLA reserved words and
some MS identifiers that need to be dealt with, but that's a different
issue entirely).

Other than that, I don't plan on using a lot of tricky, advanced,
HLA stuff. After all, I'm targetting the book for the person who
has just made one pass through "The Art of Assembly Language
Programming" so I can't really expect the kind of sophisitication
that would be needed if I really pulled out the stops and used
a ton of advanced HLA features.

Rest assured, the primary purpose of the book is to teach
Windows assembly language programming. I have to use
an actual product for the examples, and you'll have to forgive
me for tooting my own horn here and using my own product :-),
but I'm cognizant of the fact that some people aren't going to
want to use HLA and may still want to learn from the book.

I can say this, MASM32 programmers won't be *too* dissatisfied.
I will be using the same programming paradigm that common for
MASM32 examples. As an example, take a look at the Iczelion
Tutorials I've converted to HLA
(http://webster.cs.ucr.edu/Page_win32/0_win32asm.html).

Though I won't be using the Iczelion tutorials directly in the text,
the comparison of the MASM32 code and the HLA code will give you
a good idea of the type of coding you will see in the book.

Of course, if you're using NASM, FASM, or Gas (I wonder how many
people actually use Gas for Win32 asm programming?), then the
presence of IF and WHILE statements may be annoying, but for the
most part they'll be there just to make the code more readable and
their conversion to these other assemblers should prove fairly easy.

Randy Hyde
Posted on 2003-01-19 19:19:58 by rhyde
One new feature that will appear in HLA v2.0 is
that the reserved words of HLA v1.x are only pseudo-reserved
words in HLA v2.0.

This means that it is possible to create macros or other symbols
using identifiers that would normally be reserved by the compiler.
So if you really want to create a "mov" macro to extend the syntax
of the MOV instruction, for example, this will now be possible.

HLA v2.0 achieves this in an interesting fashion.
First of all, HLA v2.0 really does have a set of reserved words,
they consist of the normal set of reserved words prefixed with
a tilde character ('~'). E.g., "~mov" is the reserved word that
would normally correspond to "mov". To allow the use of the
standard "reserved words" HLA effective defines text constants
for all the reserved words (e.g., "mov" is a synonym for "~mov").
With a single directive, however, you can tell HLA to forget the fact
that "mov" is a reserved word and treat it as standard identifier.
You can reimplement the standard 80x86 MOV instruction with
a simple macro as follows:

#macro mov(src, dest);
~mov(src,dest)
#endmacro

Of course, by adding extra code to this macro, you can change
the semantics of the mov instruction (e.g., handle new versions
of the MOV instruction that Intel adds, prior to support by HLA).

Another use of this feature is that you can reverse the operands
back to the Intel format if you can't really stand the "src,dest"
ordering, e.g.,

#macro mov(dest,src);
~mov(src,dest)
#endmacro

Yet another use for this feature is to embed the mnemonics
for a different assembly language into HLA; e.g., you could
write a simple 8051 or 6805 assembler within HLA using
this feature.

From time to time, I'll discuss additional features like this
one that you can expect to find in HLA v2.0
Cheers,
Randy Hyde
Posted on 2003-01-25 11:45:00 by rhyde