After disassembling the full Forth system and gaining a fairly good working knowledge of Forth, I have always felt that Forth could be stripped down even more.

I started separating all the word dependencies and have come to realize that the Interpreter, itself, is only dependent on a few words. This is great because the goal is to write applications or games with Forth, and once the game or application is complete, the Interpreter words are no longer needed. But stripping out the Interpreter and moving the program down to close up the space, looked like a real chore to have to readjust all the links.

As I moved the source code around and studied the Interpreter words, it became obvious that the Interpreter did not need to be part of the Forth system to do its job. With the Interpreter moved out of the way, OS words were then moved on top of the Forth system. I now have a stripped-down Forth system without an Interpreter, Editor or Assembler, but with disk-access words added on.

I am getting to a place where I want to be with Forth. With the Interpreter moved out of the way, I can now start building an application or game and just have the basic Forth needed to run the program.

_________________
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 won't need a metacompiler. I can still make a headerless Forth with the use of FIND and INTERPRET. In another thread I mentioned using an insertion sort to sort words. The words are passed to the insertion sort with a beginning length byte and the CFA pointer after the word. The insertion sort not only inserts words into the sorted dictionary, but can also find any word and return the CFA after the word. The CFA obviously pointing to the actual code in the Forth system.

Because the words are sorted alphabetically, they can then be searched using a binary search method, which means they don't require the Link Field (LFA). It becomes even more handy for me that I can move the Interpreter to anywhere in memory, because the insertion sort can be part of the interpreter. I have not decided where to move it yet, because once the Interpreter is compiled at a certain location, it will have to stay there. I may end up with the Interpreter compiled at a couple of different locations, depending on how memory restrictions pop up.

Anyone wondering how I plan on compiling the interpreter without the Interpreter as part of the Forth system?

In traditional Forth, if a word is redefined, the more recent one is found.

Does your implementation guarantee that?

Not sure what you mean by traditional Forth as, there is almost certainly something in one standard that ends up broken in another standard. But there is always work-arounds.

With an insertion sort, normally there wouldn't be two words with exactly the same name, since with a search by the name itself, it would not be easy to distinguish the two word definitions apart. But I made it flexible enough that it could be programmed to check the words before and after the matching word, and only if they are the same, it can then compare the CFA addresses. It could then return the word with the CFA address that is higher in memory.

Unless the insertion sort method became popular, I probably wouldn't program it to do that as I am not a fan of having the same word with two different meanings. Instead I prefer to append a sequential number after the word if it already exists. This has the added benefit of being allowed to be inserted in the dictionary, and also lets me know as a programmer that there is more than one definition with the same name and to which one the listing is referring to.

It won't matter in the final compilation, as the code will be exactly the same.

I guess I have not come across enough ways to extend a word's functionality yet to see any advantage. All I can see right now is that one loses the original word's functionality except to the words that already have been compiled to use it.

And using TO, TO1, TO2 lets me know that I have 3 words whose functionality is very similar, without losing the functionality of any of them.

Don't get me wrong. I am not trying to dissuade any one from doing it. I am just trying to persuade myself which way is actually better for me, and if I am missing something in its use, or lack of.

I think I see a disadvantage to using methods like this.

I had to ask myself what my ultimate goal was, and the answer to that is, I would like to be able to create a headerless, self contained program in the end. The applications that I have disassembled so far do not have either an interpreter or a compiler, nor an editor or assembler included.

I guess that means the applications I want to create will have only run-time words. I won't be able to do deferred compiling.

Have you thought much about how to also cut all of the primary words that aren't used in the final program? It could save a lot of space although it would be tough to implement.

Yep! Moving the interpreter and compiler out of the way along with associated words and only leaving the words that a Disk OS is dependent on, reduces the unused words down to a bare minimum. Words that were removed can be added back if the application requires them.