Sometimes it can be beneficial to use names common in the general programming community but not always. For example, COBOL uses ADD n TO SOMEVARIABLE but Forth has +!. Some languages use one or two symbol tokens for AND, OR, EXCLUSIVE-OR, etc. while the Forth words for those logic functions are spelled out: AND, OR, XOR.
I just don't see the value of looking outside the Forth community to name a given functionality when there already exists a name in the Forth community for said functionality.


Even more reason it would be prudent to reserve the name PAUSE for multitasking.

I am trying something totally new in Forth programming and in doing so, am deviating greatly from any Forth standards, but the benefits in space savings and speed increase will be far greater in the end, so I would like to throw my hat in the ring for contention.

I created an insertion sort that greatly simplifies a lot of Forth idiosyncrasies. Here are some of the benefits.

- Links are no longer needed
- Words are sorted in alpha order and kept separate from the code.
- The word search is binary search instead of linear. Any word can be found in 3-5 tries.
- Many words are no longer needed and some have to be redefined, but are usually much shorter.
- Due to this ease of operation, Forth is much simpler to use and the complex operation of DEFINITIONS and VOCABULARIES is no longer required, making Forth even more simplified.
- No extra space is required as the sort routine is < 512 bytes and the space used is about the same as the space for the words removed. The 2-byte links alone for 256 words is 512 bytes and savings is multiplied with more than 256 words.
- Saving the Forth system with the code of an application or game is much easier and smaller since the words and links are not included with the definitions and nothing extra has to be done.
- Word lists can be listed alphabetically or by the order in which they were entered into the dictionary, or by the first character without having to search the entire dictionary, all with minimum code. The code to do this in regular Forth is substantially greater.
- The space savings now allows for use of the graphics screen.
- This layout also allows way more definitions to be crammed into a small area where the small area was separated by the graphics screen, like on the Apple II. The system definitions can now fit below the graphics screen, and the game definitions can fit above the graphics screen.

The more I delve into this method the more benefits I come across. And there has not been any disturbances in the Forth that I have found that I cannot work around. It has been fairly easy to slightly alter any word definitions from regular Forth to make them work.

The main part of the sort routine is written in strictly 6502 code, and is not computer dependent. I have extra code that allows to use the sort routine in a 2nd bank of 64k, where the words are stored. Which goes to show that if one has extra memory, this routine can benefit even more.

Once I am sure all the bugs are worked out, I will start another thread for anyone to follow along.

_________________
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 have written so many Forths, initially for the 6511, 6502, 65816, M377xx etc as well as many other 8 to 32-bit micros. In some systems there isn't much memory and so there is always the desire to save memory and also speed up dictionary searches. I think I have tried every method I could think of and while some of them worked very well, they also added processing overhead and housekeeping complications thus negating many other advantages. I have even had the dictionary in I2C EEPROM and on SD cards.

But one thing I always do now is never compile the headers inline with the code, and there are lots and lots of very good reasons not to. Rather, build the dictionary down from some predetermined location towards the code growing up in memory. Also, because all the words are packed in together with the newest word lower in memory then there is no need for any link fields. Instead each entry has a byte that combines the word count + attributes. I find that I rarely use very long words, preferring to factor into smaller functions with simpler names. Though I never go beyond 15 characters, I still allow for 31 and another 3 bits for attributes. There is no such thing as a smudge flag either and while a word is being defined, it itself is not included in the search although RECURSE will always compile a call to the current definition. One of the attribute bits will indicate that this word is "private" which is useful later on since we can reclaim all the memory of all or certain words that are private and recompact the dictionary without worrying about link fields etc. Another attribute I call preempt which works like the traditional immediate does, but because my newer Forths always compile word by word even in interactive mode (that's another big story), then preempt is used to override this when needed. Finally there are two bytes after the name for the address of the code and although I use 32-bits these days I still favor 16-bits for address or encoded instruction (literals, IF etc). This is a quick dump to show how it all looks:

Now we add a new word and examine memory again:

And to see what the code looks like:

I also have another stack just for looping including the loop branch address that is saved by DO/FOR.

There are stacks of advantages in having a separate dictionary and because my code does not have a code field it allows one function to fall through into the one after it. Since all code is word aligned I use the lsb to indicate jumping rather than calling, thus saving on a call/EXIT.

BTW, we can also trace the execution of the code if you are interested. I plan to build all these features into a 65816/7700 Forth one day, just for the fun of it. I still have scores of boards floating around.

Just to add a little bit more on the "save memory" part of this thread, remember that having dictionary separate from the code allows a lot more flexibility and another thing to remember too is that Forth benefits from factoring into smaller definitions except that that requires more and more dictionary words. That's the beauty with "private" words in that we can have all the names we like when writing and compiling but save the memory by reclaiming those private words. Much better than the headerless kludge that I used to use in my first Forth, "RSC Forth".
Here's an example from an editor I wrote and even though I have plenty of memory available in this system, I may not in another, or if or when I do a 65816 version.

The editor has a mix of public and private definitions, like this:

Now pub and pri just create standard : definitions but force an attribute flag in the header. The very first word in this editor is *SED*, so now I can tell my Forth to reclaim all dictionary memory or just up to this point, like this:


Only the dictionary is compacted word by word (using a <CMOVE) and in this case since it is only a small editor of 1.6kB of code, but still there were 401 bytes freed.

_________________
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?

Dictionary/Vocabulary/Lexicon/whatever are all just lists of words that become something a bit more specialized when you treat them differently although they haven't changed. I create vocabularies in the same "dictionary" of words simply by inserting special control fields where the count byte = 0 then the following bytes are dictionary control bytes. For instance, a count byte of 0 followed by 0 indicates the end of the dictionary etc. My vocabs are embedded inside the dictionary with these control fields and the search can be customized. My assembler works this way.

You mentioned data spaces and that is something that traditional Forth does not really handle well especially for embedded use since variables are normally sitting in with the code which could be Flash for instance, rather than a separate area. Once again, I keep all "variables" separate so that any inadvertent ! instead of C! etc does not write into code although it can take advantage of contiguous variables where four byte sized variables can be treated as a 32-bit variable or a whole area can be filled etc. So we need something other than VARIABLE, we need to describe what it is and how it fits into memory like in this section of my FAT32 driver:




The fat32 "variable" is really a constant that points to the data area and "3 bytes" advances the data pointer by 3 while creating "fat32" as a constant with the current data pointer. Now the whole data structure can be written to from the boot record sector with a simple CMOVE but I can still do the traditional fetch operations etc. If I do a it will wipe all these variables in one hit or will buffer in that sector.

But all this is probably digressing too much from this thread. Perhaps I will start a new one with my Tachyon '816 Forth which will be a 32-bit Forth since I find this the most useful for large memory addressing but also for file addressing etc.

_________________
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?

Yes, real systems that ended up with Forth in some kind of ROM rather than PC Forths that assumed they ran out of RAM is something I dealt with over 35 years ago when I designed commercial POS terminals and first used Forth. So I've never been a PC Forth guy and my main focus is on custom hardware I have designed for commercial products. When I look back at some of that software, while I am amazed at how much it did, I also see how much kludging I had to do to use a standard Forth.