Perhaps, for the purposes of boot-strapping a more general-purpose assembler, you could get by with an assembler with a more inconvenient syntax?

Garth and I have both implemented 65816 assemblers using the simple approach of embedding address modes right into the mnemonics, as shown in this deliberately lengthy example:



Note how relative branch targets are computed with *+1 instead of *+2. This is because "BNE" would already have laid its opcode byte down in the output image by the time the assembler starts the parse for the branch displacement calculation.

There's no question about it being less convenient to use than a normal assembler syntax; however, the purpose of this assembler is correctness above all else, and to serve as a means of bootstrapping the "real", production-ready assembler. You would only have to use it once, since presumably, you would use this assembler to write the first production version. Thereafter, all later releases are written in the previous version released.

The boot-strap assembler should by tiny in comparison to most assemblers, since it doesn't have to parse anything except for mathematical formulae needed to compute relative branch offsets. I'd wager this kind of assembler should be easy, and small, enough to implement in BASIC for a wide variety of RAM configurations on 8-bit computers. Provided you don't go hog-wild on lengthy label names, it should even yield good results on 8KiB computers. (Just a guess though; I haven't tested this!)

I have an example of using it for assembling the 65c02 ITC Forth internals for a 32-bit DO...LOOP (and associated words), at http://wilsonminesco.com/Forth/32DOLOOP.FTH . The , (comma) lays down a 16-bit operand after the mnemonic and merged address mode, for example LDA,X 101 , (in hex—I leave the base in hex most of the time). C, ("see-comma") lays down an 8-bit operand. Initially you'll keep forgetting to add the , or C, but soon it will become rather second-nature. Vertical alignment makes a tell-tale if you forget. It's obvious.


Mine is purely Forth, so a few things might work slightly differently. To mark a place to branch back to, use HERE (which puts the current address on the data stack). Then later, GO_BACK fills in an operand for a backward branch to the address left on the stack, typically by HERE (standard Forth word). The details are handled inside GO_BACK. Any label at that point would be commented out, because it's only for human reference and doesn't do anything. That place can of course be used by multiple GO_BACK occurrences if it gets DUPed (since each one will remove a stack cell). SWAP, ROT, and so on. are of course available too, so you can make all the spaghetti you want!

Forward references work differently, using for example BNE 1$, where 1$ remembers where the operand is needed for later filling-in, then the label 1$: (with the colon, the colon actually being part of the name (which you can do in Forth) goes back and fills in the needed operand. That unfortunately means that if you have three places that branch forward to the same spot, it needs three labels (like 1$: 2$: 3$:) but it's not really a problem. (You can put them all on the same line in you want to.) After one is resolved, you can re-use it.

Since it's Forth, multiple instructions can be put on a line. Computations of operands can be as complex as you like, because it's in Forth. Also, for the same reason, macro capability is automatic, with no added effort. The entire assembler is only a few KB, including macro capability. In its original version, I wrote it in one evening. It's not suitable for large applications (because of my label situation), but that's fine in Forth where you use it to assemble primitives, runtimes, maybe ISRs, etc., where none of them are even a page long.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I was trying to avoid bringing up Forth, to focus on the essential qualities of the assembler. It was not clear the OP was using Forth, and did not want to assume.

I've never used Forth. My goal is to be self-bootstrapping. That is, I take a commodity machine with no software other than its ROM, and write my own assembler. It didn't start out as a goal, it started out as a necessity. But I achieved it once (well, technically a half dozen times maybe), but most of that is lost to history (or the lack thereof).

I do have copies of my earliest assembler which was not much of an assembler at all. In fact, in retrospect, I think it may have been easier to assemble on paper it it weren't for the ability to instantly execute and debug. I did use that to write a fully functional symbolic assembler, albeit with a few limitations (most notably a complete lack of decimal numbers), but I have no existing copy of that assembler, that I know of.

The syntax for my assembler, which currently runs in BASIC, is probably very alien to anyone using a commercial assembler. I've never used any other assembler for 65xx than my own (other than what's built into the Apple ][ ROMs). I have used commercial x86 assemblers, in the distant past. But I wrote mine before I even used any of those. I am self taught. That is, I learned 6502 machine language from program listings in magazines. Eventually, I found magazines with parallel listings for machine language and assembly language. That's when I wrote my first assembler, which must have had syntax like those magazine listings. Prior to all that, I did have experience with TMS1000 machine language, and a theoretical processor that I designed with its own machine language, on paper. That's how I was able to pick up on 6502 so quickly. To this day, I'm not very proficient in 6502, because I have no other training or study. For example, I've never used BIT, and actually don't know how.

Over the years, I added functionality based on what I thought an assembler should do. Some of that functionality ends up looking very much like commercial assemblers, I suspect, but not all of it. I also removed a lot of functionality, as well, on the grounds that it was starting to be more like a compiler than an assembler; and I decided that if I'm going to have a compiler, I may as well be using a high level language. So I'm back to using a simple two-pass assembler, and plan to keep it that way.

I am apparently very stubborn and a little determined, as I have been putting up with my currently working assembler for years now. Assembling my far-from-complete assembler takes an amount of time that I'm not even sure yet because I don't watch it, nor time it. My text editor, which consumed most of my time on this project currently takes about 2¼ hours to assemble. I used to let it assemble over night, or whilst I was doing something else. I got a lot done during Packer games in recent years. It was only very recently that I started using an emulator, for speed's sake. Else I don't know that I will live long enough to finish! I just don't have the kind of time i had to devote to this that I had in the past. I reasoned that the emulator is not really necessary; if I didn't use it, I'd get the same work done, it would only take longer.

I hereby prescribe the best programming manual I know of: "Programming the 65816-Including the 6502, 65C02 and 65802." (It's way, way better than the description there lets on.) A large section in the back has a full page, sometimes more, for every single instruction, thoroughly and clearly detailing its operation.

I all of us have neglected to take advantage of one or more instructions and/or addressing modes. I'd like to see an article or topic on ones that we forumites seem to be neglecting.

and

Whatever works. It's not a realtime thing that must meet hard deadlines to avoid failure. My HP-41 calculator's David assembler is like that—super, super slow!

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

An assembler on the 41! That would be slow.

I use my 41 regularly now, and am always mindful of how spoilt I got over the years with my less capable 32S. For some reason, before I got used to the 32S, I never realised that the 41 actually takes time to do a simple swap!

I've considered many times especially recently buying a 6502 book. I actually looked at that very one. I do even own a few books, which I haven't even opened yet. As much as I'd enjoy reading such a book, my reading queue is full. That and I don't want to sidetrack myself until this project is complete. It will be complete when the assembler can assemble itself. I fear I'd discover that I've been doing something very basic wrong all this time and end up starting over from scratch again. I've done that too many times as it is.

Yes, this is only a hobby, and part of it for me is being able to say, "you really can do it this way, with these minimal resources."

(Did you know that the new HP35S uses an 8502 uP "core"? I think I may have brought this up before.)

MOS Technology published the assembly language standard for the 6502 in 1975. At one time, I had a mimeographed copy of the standard given to me in 1976, but alas I didn't hang on to it years later when I purchased my present place and did a substantial housecleaning prior to the move (my wife, who knows nothing of microprocessors and all that jazz, was the cause of the "substantial" part). WDC has published and enhanced the original standard to account for the 65C816—the standard is part of the datasheet. It is always best to strictly adhere to standards so as to make assemblers as appealing as possible to a wide audience.


As Garth noted, enlightenment is only a download away. Incidentally, BIT works like AND, except the former doesn't change the accumulator.


Up to a point, more functionality in an assembler is useful. For example, a good macro language can take quite a bit of tedium from assembly language programming and even allow some useful features, such as code structuring (Garth describes that at length on his website), to be implemented. The presence of a strong macro language in the Kowalski simulator's assembler allows me to write complex 65C816 programs, even though that assembler knows nothing about the '816 and its substantially enhanced repertoire.

However, as you noted, you can reach a point where your assembler gets too bulky and slow. Assembly language is low level, so it's best that an assembler is designed with that in mind.


I'd like to be a purist and use only tools running on the 65C816 to write 65C816 programs. However, given the computing power of modern MACs and PCs, I'd be foolish to not cross-assemble. My POC V1 firmware, which runs to more than 11,000 lines of code, assembles in about one second. I know that if I were to implement an assembler on POC V1 and use it to build firmware, assembly time would take far longer, even though POC V1 has plenty of (SCSI) mass storage and the '816 is clocked at 12.5 MHz. Not everything associated with ancient microprocessors has to be done with a stone axe.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Also, BIT is especially useful for testing bit 6 and/or bit 7 regardless of what's in the accumulator. IOW, a bit mask is not needed for testing these bits. So without using or disturbing A, X, or Y, you can use BIT to test an I/O bit for example, then branch on V or N (BVS/BVC or BMI/BPL).


see 65c02 assembly structure macros, also examples starting about 60% of the way down the page at Simple methods for multitasking without a multitasking OS, for systems that lack the resources to implement a multitasking OS, or where hard realtime requirements would rule one out anyway, or the last three pieces of code at http://wilsonminesco.com/6502primer/SPI.ASM . I'm sure I'm forgetting several.


Fortunately the speed of the assembly process is independent of the run speed of the resulting assembled code on the target computer. When I developed on EPROMs in years past, erasing EPROMs took a lot longer than the assembly process, but I could keep and "assembly line" going in the UV eraser while I checked my latest build and worked on the next one, so it didn't hold me up. However, I have heard about, but not witnessed, the long assembly times taken by an assembler running on the C64 for example, and that was apparently not even a macro assembler.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

I've been told that there's an Apple ][ assembler that runs at 13,000 lines per minute. POC v1 should be able to do at least that then!

I've very little interest in standardising my assembler, and here's why: I'm the only one using it, and I like it to work the way that's most efficient for me. And time has proven that I all but never use anyone else's source.

I'm not trying to use a stone axe. But, having written my 65xx assembler for AmigaOS many years ago, I found that very boring. How much more boring would I find using Windows, which I detest, or MacOS, which I know very little about?

Commodore's MADS (macro assembly development system) running on the C-64 could be agonizingly slow in some cases. Part of the problem was caused by the feeble 1541 disk drive, but much of it was compute-bound in nature. When I did the initial development of my Lt. Kernal ISAM-like database engine development on the C-64, assembly times of two or more hours were common. By the time the code was fully fleshed out, I had switched to DEVPAK on the C-128 because MADS' symbol table would overflow and assembly would abort. Despite the C-128 running at 2 MHz, versus the C-64's 1 MHz, assembly time had grown to nearly three hours.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Memory limitations are a big problem for symbolic assemblers, not to mention macro assemblers.

I could at least triple the speed of my assembler if I could use the REU. But I don't care to be lugging round the REU when I'm already lugging round an SX64 and battery and inverter.

I don't know that core was a limitation on the C-128, as DEVPAK used all of RAM1 above $0400 for the symbol table and macro library. One time after I had assembled my ISAM package I poked around in the machine language monitor examining RAM1 and determined that only about 40K of the available 63K had been used, and that was with a symbol table containing several thousand entries.

DEVPAK used an insertion sort to build the symbol table, the side-effects of which became clear as the table expanded. Disk accesses would be less frequent as the symbol table grew, as processing would become more and more compute-bound. The C-128's architecture didn't help any, of course, as each fetch or store from RAM1 always involved diddling the MMU twice per transaction. All-in-all, the C-128 inadvertently demonstrated why the 65C816 was a huge leap forward in the 65xx world.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!