6502.org

Hello Everyone - I registered a while ago, as I am in the process of building a small 6502 SBC and of course, it will need to run Forth. I have moved over from the Z80/8085 world, and this is my first post.

I am currently trying to understand the code in the FigForth Installation Manual - The idea of Forth being able to assemble itself appeals to me. Therefore, my intention (once my hardware is up and running) is to use a "standard" assembler version of Forth to run the assembler, and get the Forth Assembler version up and running (if that makes sense).

Working my way through the Installation Manual (This document: http://6502.org/documents/books/forth_i ... lation.pdf) I realise I need Mr. Ragsdale's assembler from Forth Dimensions, and so far everything makes reasonable sense.

However, I am stuck on what is happening on Screens #70 and #71 - obviously "Forward References" makes sense in that we are referencing things which haven't been defined yet but I am not understanding the how.

As an example: Surely the words BYTE.IN and REPLACED.BY must be defined somewhere? I can't find them in any of the source files. What am I missing?

It's probably a pretty basic question, I wouldn't consider myself to be a Forth expert - I know just enough to cause mayhem - but it's been bugging me for hours!

Welcome, Robert, and congrats on your first post!

I don't have time to fully unravel this for you, but luckily I kept my paper copy of the Installation Manual, and in it are some pencilled notes made by me over 40 years ago which help to clear the fog.

Let's be clear that Screens #70 and #71 resolve forward references whose targets are now defined. I don't know where the source code for BYTE.IN and REPLACED.BY are, but if you want that code I suspect you may have to rewrite it yourself... or instead poke in the necessary bytes manually (which wouldn't take very long).
In this example, zero -- an offset -- is pushed to stack. Then BYTE.IN executes; it looks ahead in the input stream (apparently using -FIND ) and determines the pfa of the next word in the input stream ( which in this case is : ) and adds that pfa to the offset that's NOS (in this case zero). The result is the address of a 16-bit value which is merely a dummy placeholder, one which needs to be updated in order to resolve the forward reference.

Then REPLACED.BY executes, and it too looks ahead to determine the pfa of the next word in the input stream ( in this case the pfa of ?EXEC ). IIRC, the pfa needs to be changed to a cfa. Then, if I'm not overlooking anything, we have on stack both the address of the placeholder and the value that'll overwrite the placeholder. All that remains is to SWAP and !.

Screen 70 reveals that the word : include ten more forward references in addition to the one just described. Notice how a separate offset is specified for each.

FWIW, BYTE.IN can be used in another situation, too -- one not involving forward references. Line 15 of SCR # 29 includes the snippet which assembles a JMP to an offset of 1 within the parameter field of MINUS (which you'll find defined on line 9 of that screen). IOW, DMINUS concludes by sharing most of the code of MINUS, thus saving memory.

HTH,
Jeff

Hello Jeff,

Thanks for taking the trouble to respond. At first glace, I think I understand.

I now need to get my head around it fully!

Hi Robert,
you might run into a chicken-egg-issue with this. The code from your installation manual can only be compiled if you have a running Fig-Forth installation. If you don‘t have that, your best way is to use the 6502 assembler source for Fig-Forth. That way you can start from bare metal with any assembler or cross-assembler
Dietrich

Thanks, Dietrich -- and apologies, Robert. I failed to comment on the larger issue, the "chicken or the egg" thing.

The code in Screens #70 and #71 appears to be part of an effort to use a Forth installation to assemble & compile a new Forth installation. But that effort is anything but complete, and FIG Forth is far from being able to recreate itself. The Installation Manual might just as well have omitted Screens #70 and #71.

-- Jeff

Thanks for that Dietrich - I was aware of the Chicken and Egg thing. I don't think my original post was really clear, but that's what I meant with the "standard" assembler version of Forth. I realise I need to get a version running (and the assembler) before I can think about compiling the version in the installation manual. I have also come to the realisation that the installation manual code is missing other words (LABEL among others - as Jeff said, anything but complete).

I realise I am getting ahead of myself here, because I don't have any functioning hardware yet (the board is designed, but I haven't sent it off for fabrication). However, I don't think there would be too much work to get FigForth to compile itself. I think what is going to make things complicated is getting it to relocate itself - once it has been compiled.

I am probably oversimplifying things, but it should make for some interesting experimentation once I get that far!

We'd be happy to know the details of the hardware if you care to share them. (Y' might want to start a new thread for this.)

Anecdotally: my own solution to the chicken or the egg problem was to manually enter FIG in the form of about 8 kbytes of hex. (This was pre-DOS days for me, and I had no assembler of any kind, just a KIM-1 with Cheap Video and some added memory.)
Later in the 20th century I embarked on a project that's broadly equivalent to what you seem to have in mind. And indeed it did lead to "some interesting experimentation" as you say; but, contrary to your expectation, it was a LOT of work. Perhaps I inadvertently adopted a sub-optimal approach, but OTOH perhaps my gnarly solution was unavoidable, given the tools I had to work with and the inherent Catch-22s to be resolved.

What I developed was dozens and dozens of screens of source code (which my KK Computer was capable of reading in from floppy disk). When I asked FIG Forth to LOAD this sequence of screens, Forth's DP -- the dictionary pointer -- would get moved up to $8000 or thereabouts. Then, still chaining back to the original dictionary in low memory, a whole new Forth installation was assembled and compiled. (Ragsdale's assembler was part of the parent FIG installation.)

Did I mention Catch-22s? It was HORRIBLE! I wrote a variety of novel, ugly hacks (some of them reminiscent of Screens #70 and #71) because FIG Forth doesn't seem to include the hooks that would make self-re-creation straightforward and sanitary.

Nevertheless, I eventually was successful in getting the new Forth running up at $8000, and the last step was to sever the connection to the old dictionary. Believe me, that felt like a heckuva victory! Whew!!

At last I was running a system created under my control from source code I provided, and -- with this major advantage achieved -- I then became distracted with other shiny toys, and didn't carry the thing as far as originally planned. My intention had been to revise the code until what got placed at $8000 was a Forth that had the hooks in place to make things easy and allow the Catch22s to be worked around. After that, all subsequent iterations could be done cleanly! For example, I envisioned being able to put DP back down at $0200 and -- without resorting to ugly hacks -- use my new installation to create yet another new version of itself. But this never happened.

Sadly, I'm not easily able to share the dozens and dozens of screens of source code I mentioned, because nowadays KK and its floppy disk SBC are finding it almost impossible to get out of bed in the morning. But I tend to think you don't wanna see that code anyway. There's gotta be a better way to achieve a self-re-creating Forth! And very likely it has nothing to do with FIG. Screens #70 and #71 seem to suggest that I'm maybe not the only one who was trying, but....

-- Jeff

...the ultimate in self-flagellation! 

That is why I took the 6502 Assembler Route. I added a DOS Interface too.
The only thing to worry there is the JMP ($xxFF) bug.
You might want to Check out my GitHub repo for the Elektor Junior Computer
Dietrich

Yes - I will start a thread. I am still ironing out a few of the details at the moment.
I am probably over simplifying my approach! We all know how it is, it all seems simple when you set out on a new project, but the devil is in the detail!
I will! I also noticed your CPM-65 which looks interesting.