home *** CD-ROM | disk | FTP | other *** search
- ---LIST.DOC---
-
- Listings with A86
-
- A86 does not produce a .LST file, or anything similar to it! (We now pause,
- to allow traditionalists to recover from their swooning shock.) OK,
- everybody back to consciousness? Good. Now let's all try to strip away our
- preconceptions, and look at things with a fresh viewpoint.
-
- In particular, let's consider what we use a listing file for, and see how A86
- meets those needs. I've been programming for 20 years; I have generated
- literally tons of listings. Historically, here's what I have used listings for:
-
- 1. To find out what my error messages are. In the early days of Intel, the
- text editor was so bad that it was actually faster to march across the
- building and physically print the list file, than it was to use an editor
- to find error messages! But even with a fast editor, what a pain it is to go
- into the list file, enduring its 120-column wide format on your 80-column
- screen, copy down the errors on paper, then go back to the source file
- to find where the errors were. Why doesn't the assembler just stick the
- messages directly into your source file, where you can view them and
- edit the source simultaneously? That's what A86, and only A86, does.
-
- 2. To see what code was generated; those hexadecimal bytes at the left of
- the listing. That was a real necessity, back in the days of hexadecimal
- debuggers. There we were, furiously patching those hex object bytes.
- We needed the listings to find our way around the program, while debugging.
- Today, we have symbolic, disassembling debuggers. (Well, at least I have
- a symbolic, disassembling debugger. The rest of you will have it too,
- by August, 1986). The power of today's debuggers means that you seldom
- need to look at hex bytes. If you do, the debugger can show them to you.
-
- 3. To get a symbol-table listing. The necessity of this diminishes a great
- deal when you have a SYMBOLIC debugger; but I still like to have a listing
- from time to time. So I have devised a separate program, XREF, that goes
- through another pass of the source file, and creates the world's finest
- cross-reference listing for assemblers.
-
- You may ask, "Why am I being forced to essentially re-assemble my code to
- get a symbol table, when other assemblers will give it to me in the original
- assembly?" Don't be fooled. Those other assemblers go through all your
- source files twice, or even three times. They just do it behind your back,
- every time you want an assembly. That's one reason why my assembler is so
- much faster than everyone else's.
-
- 4. To just look at the code. I have often in the past needed to see that
- program, spread out on paper, just to get a handle on what the program is
- doing. But I have needed this less and less lately. Why? For two
- reasons. First, text editors have improved. It's much, much easier than
- it was before to cruise through a file on the screen. Second, my programs
- have adapted to the screen-viewing methodology. Almost subconsciously, I
- have started making the conceptual "chunks" of my code fit into 1 or 2
- 24-line screens, rather than 1 or 2 60-line pages. This, of course, makes
- better, more modular programs. (Spaghetti tends to untangle when you chop
- it up.) It's gotten to the point where I can develop a 5000-line
- application, fully debugged, without ever making a listing!
-
- 5. For archival purposes. I still do this; you should never put 100% trust in
- magnetic media. But I've stripped away the reasons for having anything but
- the source code and the symbol table. So I just copy the source files and
- the cross-reference listing to the printer. I haven't looked at the listings
- too much; so I haven't bothered with pagination control. If you want to,
- you can insert form-feeds into your source; A86 will ignore them. Or, you
- can write a simple listing-tool that recognizes the PAGE directive; A86
- ignores that directive, also.
-