6502.org

by Bill Ragsdale, in Forth Dimensions Vol 3 Number 5 (pdf) (or this archive version) (or this wikified version)

"Some will be fascinated by a label-less, macro-assembler whose source code is only 96 lines long! Others will be repelled by reverse Polish syntax and the absence of labels."

"The author immodestly claims that this is the best FORTH assembler ever distributed. ... It is released to the public domain as a defense mechanism."

Features:
- User macros, definable at any time
- Literal values expressed in any base
- Expressions using any resident computation capability
- Nested control structures without labels, with error control
- Assembler source itself in a portable high level language

Machine-readable source code for this remarkable assembler is found here. For a description of the assembler refer to the Forth Dimensions article mentioned in the previous post (thanks, Ed!).

-- Jeff

Fer sure; assemblers are a great example of an application that Forth excels at.

And tastes do vary, of course. I'm not trying to suggest that Ragsdale's fully-RPN approach is superior to the more-standard mnemonic-operand order you mentioned, or that other choices he made are necessarily the best. But I used to use the Ragsdale assembler quite extensively. Now, years later, I'm fooling around with FIG Forth again, so it's only natural to pick up where I left off. The other day I got FIG Forth running in the Kowalski simulator, and tonight I started the simulation and then dropped in Ragsdale's high-level source code -- which compiled instantly without a glitch

FWIW I am a fan of the structured conditionals that Ragsdale included -- such as IF ELSE THEN and BEGIN UNTIL, for example, as opposed to bare assembly-language instructions ( BNE BCC etc.). Ragsdale even included error-checking (similar to that used in the high-level FIG compiler) which ensures that your conditionals are properly paired. But, frankly, for assembly-level coding I found that the error-checking can get to be a nuisance... although it's not terribly difficult to circumvent -- you can break the rules if you need to.

Back in the day I extended the Ragsdale assembler to include Rockwell 65C02 instructions. If I can find that code I'll post it.

-- Jeff

At the time Jeff's post appeared I decided to offer my 65C02 assembler (written longer ago), if Jeff doesn't find his. It took some time to get it on-line, after some "face-lifting", however, here it is: Forth 65C02 assembler
(sorry for the strange text format which comes from the the editor on my "development system", a Forth on a C64 )

BTW, it's influenced by several assemblers, but the roots in Ragsdale's version can't be denied. It has two (CPU) modes to adapt on how the code for structural elements is generated. WDC specific instructions are included too (just for completeness).

Johann
(yes, I know, call me a grave digger )

Welcome, Johann -- nice to have another Forth enthusiast in our midst!

Can you explain how you evaluate the result of your test suites? When executed, T1C02 evidently assembles some code, as does T2C02. Then what?
Oops, I have yet to follow through on the search for that code. Unfortunately, it's probably on a non-DOS 5-inch floppy. LOL! Back then that medium seemed perfectly wonderful -- I was delighted just to avoid using audio cassette! We're talking mid 1980s, btw, so I guess you & I were hacking Ragsdale at about the same time.

Cheers,
Jeff

Thanks. I'm on this forum since 2012 (irregularly from time to time). The postings and the discussion level here is really "advanced", so it took some time to step in.
BTW, I was already in touch with Garth Wilson (for his '816 Forth which I studied with great appreciation).

This is not indented for some kind of automatic testing. I forgot to mention, that I cross-check the produced code just with a (my Forth) disassembler and it is necessary to tweak the test code to get it compiled (e.g. insert the keyword "FAR", to produce long branches based on JMP ...
I added the disassembler and decompiler on my home page (including some short instructive hints, hope so).
Oh my god, I had the floppy problem with my "OS-9 Level I" stuff (single density - FM formated, partially), not easily to read on PC hardware, but got it, but with a selected equipment (nothing special, anyway).

This seems like a good thread for the 1991 text document B.Y.O.ASSEMBLER -or- Build Your Own (Cross-) Assembler....in Forth by Brad Rodriguez - there's a lot more by him nearby including the Moving Forth series.

(I was actually hunting for what might be a mythical (8080) "assembler in 54 lines" mentioned in this history of Forth in Russia by Sergey Baranov, and eventually found a three-screen (8080) assembler by John Cassady (also here) which is probably the one mentioned. But it's in Forth Dimensions, not in Dr Dobb's as promised: The author wrote a book on Forth which seems to have sold over 50 thousand copies - that's some enormous pent-up demand.
)

In line assembly is always cool to that but I find that most
of my assembler needs are targeted to some other machine with
no mass storage.
I always add such things as file buffering for output.
I fell in love with John Cassady's control structures and have been
using the concept ever since.
Having no requirement for a fields or returns makes it so that one
can write more coherent code as well. It begins to be readable
an much easier to add meaningful comments to.
I still write most as single pass and add the ability to have forward
labels, that must be declared.
Since I build the object code in a buffer that is flushed to a disk file,
the dictionary space can be used for linked list for forward references
to be patched.
I also have a word called SEGMENT.
It is used like:

$200 SEGMENT MyCode
$FFFE SEGMENT InterruptVector


MyCode
LABEL init-sequence
... \ some code here
LABEL IRQ
InterruptVector
IRQ A!
MyCode
... The interrupt code

It can have other uses since it doesn't have to be defined
until needed and also easily modified to span keep out areas
that the code needs to strattle. One doesn't have to think about
where some entry point might end up.
Dwight

I found the assembler I wrote in Forth enormously helpful learning the language - it really drove the point home that you don't program "in" Forth, but that you build on the core language to create your own specific language, and that you "change the problem" by finding a different syntax for the instructions. So if anybody is wondering if it is worth the effort, I would say yes, very much so.

When I first started with computers, I saw things like BASIC as being
way beyond what I'd ever do. I don't mean writing code in basic, I mean
writing a BASIC interpreter or compiler.
It was all just magic.
Once I got my hands of Forth, I realized how simple it really was. It
is really about organization. I suspect I could write one in most any language
after using Forth for some time.
I've written a number of specialize interpreters/compilers over the years.
Last night, I wrote code to create a JEDEC file for a PAL. While I could
have let PALASM do it for me, there was some special connections for
the ZEROs that I wanted to avoid glitching.
PALASM doesn't know enough about my signals to do the optimal thing.

All the magic is within a persons grasp.
I know what you mean about expanding the language. I try to explain
it to people but they never get it. It is so uniquely Forth.
It is a shame that PCs are becoming less and less computers and more
and more just web surfing boxes.
Dwight

On the other hand, there are plenty of cheap and fun embedded processors and boards. Yesterday I ordered a $10 microcontroller kit, containing a $1.50 microcontroller and free USB programmer. It has 64kB of flash and 8kB of SRAM, timers, UART, I2C, SPI, RTC and ADC. Tools and demo programs are free. If you want, you can put Forth on it, and pretend it's still 1980.

B.Y.O.ASSEMBLER perfectly describes how this kind of assembler are designed and built. Really important referring to it, as I now added it to my site. Thanks for this pointer. Very interesting.
In "Zech, "Die Programmiersprache FORTH", Appendix "Assembler 8085 6502" (german) " we have an 8085 assembler implementation, maybe influenced by Cassady's version, but that's not clear. It's similar from the syntax (except it uses the comma style mnemonics), but not that compact in structure, probably with focus to a better readability. However, both have at least the <BUILDS DOES> style in common.
Zech's assemblers are now referenced on my site mentioned above.

Johann

The assembler I wrote for my Forth for the Commodore 64 is also based on Ragsdale's assembler. I rewrote M/CPU and the index table is ten bytes smaller. I added range checking for the instructions that compile a branch. One change I'm thinking about is removing the comma's at the end of the opcode and control structure names. On the other hand, the code words for the system are written with the comma's in the names and I'd have to rewrite it.

Which is, basically, every single day of my life. I live in the 80's and refuse to accept any other timeline.