6502.org

I wonder if there is a lack of interest in Forth assemblers with structured conditionals or if Ragsdale's is the only one with which most Forth programmers are familiar? Here is the source for mine. Any comments, questions, suggestions?
[Edit: It's released under the LGPL version 2 or later. Do I need to include a copy of the license?]
[Edit: Included license]

The problem with Forth assemblers isn't necessarily the syntax (as off-putting as it may be to some), but the fact that it's in Forth in the first place.

If it were just a stand alone program that takes a text file and spits out an assembled binary, then it's simply a different syntax rather than an entirely different tool chain.

and, yes, you should include a copy of the license in the ZIP file.

That's the basic problem, though.

Forth assemblers (and when I say "Forth assemblers", I'm talking the typical Forth Assembler most of us are familiar with rather than some edge case) are for writing words for a Forth environment, rather than large assembly language programs. So, they're not, typically, designed for some of the problems that regular assemblers are designed for.

Notably, Forth assemblers aren't set up to manage or work with libraries and object files. They don't need a linker. They also don't offer things like cross references, reference tables (labels and their assignments), etc.

Early Forth assemblers were also, naturally, limited by the BLOCK structure of Forth source code, which is why much of it is written with several instructions on a single line vs one instruction per line in traditional assemblers.

Forth assemblers are single pass assemblers as well.

Basically consider someone writing Prince of Persia using a Forth assembler.

There's nothing to stop someone from writing a full boat, stand alone, full featured assembler using the RPN syntax. But, in the end I don't think it would save much in terms of the assembler code, or how wide of an appeal it would have in the end.

Well, Ragsdale's assembler (which includes structured conditionals) has been around since Day One -- ie, FIG Forth for 6502, which was 1980 or thereabouts. Said assembler very likely has room for improvement, but any revised or alternative version has some catching up to do when it comes to garnering attention.

There has, however, been a fair amount of discussion here on this forum. It's not all tidily arranged in one thread, unfortunately -- that can't 100% be expected, given the way discussions evolve!

In addition to this thread, here are two others with pertinent remarks:

• This and nearby posts in the Petil thread pertain to CASE statements.
  Self Modifying Code (perhaps too broad a title, as you didn't mention the intended context of structured conditionals)

BTW, I'll quickly inject a comment of my own. Ragsdale's assembler (and yours, I think) check to see that conditionals are properly paired, which means (for example) that BEGIN leaves both an address and an error-check code on stack and UNTIL removes these two items. Usually that's fine, but in certain situations the error-check code becomes a nuisance, leading to extra SWAPs ROTs etc. I daresay there's no perfect solution, but perhaps it'd be best if the error-check codes (but not the addresses) got pushed & popped from their own separate stack. (This is a variation of an idea Garth suggested elsewhere.)

-- Jeff

Well, there's this example:

http://www.forth.org/fig-forth/fig-forth_68000.pdf

This is an implementation of Fig-Forth written in an RPN assembler (itself written in Forth). Though if you look at it, you'll see it's more traditional assembler than the typical utility in a Forth system to build assembler based words.

AT A GLANCE, this listing is almost unreadable, to me. By that I mean I would have to give it some thorough study to get past the syntax that they are using. But if you notice, this assembler does NOT offer structured conditionals or loops (this is readily apparent in the FIND word, where you see FIND1, FIND2, etc. labels.

I only mention this as an example of the momentum that typical assembler syntax has, being pretty common across CPUs and instructions sets.

RPN as an expression representation has utility to folks, particularly in calculators as it just works better on going calculations. But having as assembler of this scope relying on RPN, is really designed as a benefit to the computer, not the developer. I don't think I would necessarily enjoy working with the assembler syntax presented here.

But, then, we can get used to anything.

I enjoy postfix assembly. I'm curious, you've mentioned how bad that metacompiler was, could that have colored your perception of the assembler?

Ah but that's not the case with the metacompiler's assembler ( which is also postfix ). When I was developing my metacompiler, I added a feature that I never actually needed ( it was easy to add ). The metacompiler has a word SUB which is used to write subroutines a code word might need. SUB creates a label ( on the host, of course ) but does not create any header or code field on the target. It then switches to the metacompiler assembler vocabulary. Here is a short test routine I wrote last night. I know it's not much, even for an example but, it shows that it is possible to use the metacompiler's assembler to write stand alone programs.
This short piece was saved with the metacompiler word TSAVE and loads at address $C000 or decimal 49152 ( an address familiar to Commodore 64 users who also programmed their machines ). The screen shot shows the short BASIC program that uses this routine. The screen shot was taken during the test. Yes it completed successfully. This has given me food for though about the metacompiler. Currently, the source is compiled with MLOAD or MTHRU but, writing MINCLUDE, a metacompiler version of INCLUDE will be easy to write but, there may be a better way. I'll have to go through the metacompiler code and clean it up and maybe rethink some of the metacompiler design.

Cheers,
Jim

P.S. BOTTOM! could be renamed ORIGIN.

Sorry about that, I kinda got sidetracked on that one. The disscussion digressed to a discussion on fixing that ugly hand calculated offset in my example SMC. My assembler uses structured conditionals, so I'm biased that way. In addition to the SMC use by NEXT, I was hoping to see more examples of SMC in assembly, in any notation, or high level Forth, although I've never had an occasion to use it in high level Forth. Still, it would have been interesting to see some examples. There's chitselb's example here but, I really would have liked to see more examples. That's why I've got CS-DUP CS-DROP CS-SWAP and CS-ROT which also work with high level Forth conditionals. I just treat the address and security number as a single unit.

No; the postfix assembly might have colored my perception of the structured conditionals, but I didn't pay much attention to that part anyway.

Part of the problem with postfix assembly is not the postfix itself, but the difficulty in applying vertical alignment for visual factoring, since the addressing mode is separate, and operands are of varying lengths (regardless of what system is being used).  Sometimes operands must be calculated from a longish line of source code; so vertical alignment of instruction mnemonics would require putting them waaaaay off to the right; and then if you want to indent a portion for a structure, well, forget it.  Now there's no room for comments either.

I don't usually align on the opcode, but rather the first character on a line as shown below: Is high level Forth so different?

Oops. And the digression was caused by me. FWIW, my excuse is that Self Modifying Code has gotten a lot of bad PR, and I feel the best way to overcome that is to show SMC being used in a clean and tidy way. When your example of SMC also happened to include hand calculated offsets I felt compelled to speak up, because the two do NOT go hand in hand.
Yes, you have a solution of sorts but it's not one I like much, and I thought perhaps I could do a little better.

Unfortunately, after refreshing myself on the subject (it's been years since I involved myself with this) I have no dramatic improvement to offer. In my notes I did find the following...... but this is less flexible than what you're doing, and certainly no prettier.

cheers,
Jeff

ps: returning to the subject of clean and tidy coding, don't you think you should used a named constant in cases like this?

You are correct, I should have. I wasn't thinking about it but, those who downloaded the first ZIP file are limited to 'fair use' of copyright law. The first one has been replaced with a ZIP file containing the assembler and a copy of the LGPL version 2.1.