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

It's fun to read about Moore and ColorForth and his views of simplicity and sparsity. Reading some of the late Jeff Fox's papers about it. What code of theirs that I've seen is beyond inscrutable. It's very dense, and it's just gorged with magic numbers with no context. The simple example of ColorForth IDE reading word, its basically ports and INPUT instructions. Perhaps if you know its an IDE routine, and you know the actual I/O ports IDE uses, it's a bit more clear.

I wonder how often these guys went back to their code after 6 months of working on something else.

I'm in the process in my spare time of trying to port F83 to 6502. F83 is a PC implementation, but it's complete, has a meta compiler, etc. Ostensibly I simply need to convert the code words (and I'll use my Fig implementation for inspiration there), and then figure out how to get it to dump out a big hex dump instead of a COM file.

That is a very large source base. And trying to make heads and tails of what is where, especially with he meta compiler -- boy I tell ya, it's not for the meek.

F83 is really well documented, they had shadow screens for most of the code to explain what it does. But it, too, take serious study to follow along.

Since I use it to modify itself, I find I have to reset a lot. Sometimes I'm able to exit to DOS and reload, but more than not, if you get a loop bad, I have to restart the VM.

It's definitely challenging to work back in the day of a 80x25 screen with no scroll back.

I managed to create text files of all the source, with the shadow screen side by side. Those are great for references.

But, this is well written, well documented code, and it's work to get through it and figure stuff out for sure.

What I should do is load the entire system in to a single file. Switching between files is a bit of a pain, and if you use the VIEW command to see the source of a word, it swaps files underneath and you have to switch back to the file you're working on.

I know, this is not indicative of how things are done today, for sure. But it's how it was done back in the day. Both F83 and Pygmy Forth were pretty advanced. F83 even has the tasking system, which should port easily to the 6502. Just still have to get in the groove of it. We are certainly spoiled and jaded today.

Your post reminds me a bit of APL... APL can be very very dense, and with single-letter variables, and the idea is that you read a program the way a mathematician might read a proof - very slowly and carefully, and with great concentration, and with every character being crucial. At the opposite extreme, perhaps, is COBOL, with long meaningful names and lots and lots of lines in the program. You might skim a COBOL program the way you'd skim a newspaper.

So, maybe the Forth style you're describing is somewhat like a dense APL style, where the reader is expected to study and internalise the logic, moving very slowly. That's more demanding, which means fewer readers are going to manage it, which means it's unsuitable for large corporate teams - but for a tiny team or a one-person show, so long as those people can maintain their mathematical proof-reading performance, it might be a win.

I think, for me, the fundamental issue is the lack of visibility of data in flight.

Simply, at the beginning (barring a comment), you don't have a view of what the stack should look like.

Next, without intimate knowledge of the individual words, you don't know what the stack looks like in during processing. With normal code, you see the values bouncing back and forth across work registers and memory as the data is passed from routine to routine.

Finally, the terse nature of the commands doesn't help for casual reading either. So, its several levels of keeping the stack in your head, trying to intuit what each words does by its name, then actually knowing what each word does to the stack.

There's a lot of unfamiliarity going on, so, especially early on, the cognitive load per character is really high.

With experience, it will go away, but for now, it's a slow start.

I do think I will combine the system in to a single file. This will entail combining the 3-4 source files in to a single file, and then rebuilding the system from that. That will make VIEW much less expensive (I'd sure like a command history, boy I'd buy that for a dollar! ). It'll also just give yet more exposure to the overall system layout.

Heck, I'm still relearning the editor when I come back after a day or two.

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

Fox and Moore seem to follow the "Denser the better" idiomatic Forth Screen model of development. One screen I saw that was supposed to be an example of Moore's work was essentially packed full. Basically, imagine the screen filled with colon definitions that are simply word wrapped, with no other new lines. He really seemed to advocate this style of work.

Yes, Forth has a brutal learning curve. I spent the first weeks yelling What?! at the screen so much I felt like the Tenth Doctor. Some things that helped me:

Swallow your pride and put a stack comment after every single word, at least at the beginning. You'll feel stupid, yes, but you can walk through the code step-by-step. Once you know the code works, you can go back and condense the comments. But don't. You'll thank yourself when you come back in a year.

Use a modern Forth. Old Forths try to do all kinds of stuff at once - exhibit A is FIND which returns ( addr 0 | xt 1 | xt -1 ) depending if it found the word, and if the word is immediate, and I can never remember what addr is. ANSI Forth (and Gforth, which seems to have become the real standard) follow the philosophy of doing one thing: FIND-NAME is ( addr u -- nt | 0 ) (or xt instead of nt, depending on your Forth). REFILL just returns a flag if it worked or not. PARSE-NAME replaces WORD and just does ( "name" -- addr u ) while WORD ends up being BL WORD COUNT anyway and then does something weird with an extra space character at the end of the input.

Write shorter words. This is still one of my biggest problems, my words still tend to be multi-line. It seems wasteful, but remember that a good Forth compiler will turn everything into very small assembler snippets.

Rewrite again and again. I mostly use Python, where there is supposed to be one obvious way of doing things, and there usually is. Forth rewards going back over your code and refractoring it. That is where you'll have sudden insights about how CREATE DOES> would be really cool or how you really should use DEFER (I love DEFER). This means that your Forth code will follow Hemingway's famous line about normal writing: "The first draft of everything is ****."

I know what you mean about not knowing what the words are for. It took me ages to realize that COUNT is also used to walk through strings, not only to convert old style to new style. Maybe somebody should start a "bestiary" of Forth words with examples and such?

... unless you are a one-in-a-million genius, then the odds get a bit better. I have ample proof that I am not a member of that elite group, but I know that they are out there.

https://www.youtube.com/watch?v=uq2eD-POpDI

Mike B.

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

Very loosely referencing the cathedral & bazaar, I've called that ultra-dense and ultra-customized style "building a little cathedral". Problem is, if something foundational needs to change, you often need to take the wrecking ball to it and rebuild a slightly different cathedral.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I think the rebuilding idea is indeed built in - scotws mentions refactoring. It's not necessarily a bad idea to have a page or two of very dense code which is sometimes completely rewritten. But it doesn't scale to multiple authors or maintainers.

Just for amusement, here's some C code written by an APL guru:


Don't look too closely or you might lose your mind in there. We're used to understanding ten lines of code in ten seconds. In this case, probably ten hours would be enough.

I always used HP calculators and I'm very familiar with RPN. That hasn't helped me one bit with Forth though, the more I look at it (and I have, for years, if not decades) the worse it gets. As it is now, I don't understand anything of what has been posted lately in the Forth section here.
As for C though, I had a brief start with BASIC in the dark ages, then quickly got disgusted, and found structured programming. I wrote Fortran 77, and Pascal, mostly. Later C came around, but I can't remember any learning curve worth mentioning for C. I started with an existing piece of code, as I recall, and Henry Spencer's 10 Commandments for C Programmers (to learn about pitfalls). Taking a step back, C looks just like any other structured programming language. Thus the non-issue of moving from Fortran and Pascal to C.

Despite my initial attraction to Forth, I'm now more and more in agreement with those who have said that the way to write Forth is to find a problem which fits Forth, and ignore every other kind of problem. That may be very black and white, but it doesn't feel too far from the truth either.

I had a similar experience moving from BASIC to C ... it just "flowed", with minimal fuss. If I need to hack something out, my "GOTO"s are still BASIC and C. I want to learn Forth because I feel like I might be missing out on something really neat, but there seems to be a barrier in my thought processes that is making it difficult. I'm certainly not ready to give up yet.

Mike B.

Yeah. I won't give up just yet either.. thanks Mike. Will fiddle a bit more with gforth I think. It's been a while now.

One insight that helped me was realizing what Forth was originally made for and what it is used for in Real Life (TM) until this day: Situations when your hardware is really not adequate for the job you have to do - when you have to "do more with less". You're NASA and you're sending a probe into the cold and radiation-bathed hellscape around Saturn, so you're hardware has to be robust and dirt simple. You're trying to generate a Mandelbrot set on an 8-bit processor. Stuff where you have to punch far above your weight.

Forth manages this by brutally offloading stuff to the user. It exposes the stacks instead of hiding them like the Java VM. It uses RPN for math because infix needs special rules ("multiplication comes before addition") and requires special characters like ( and ). You have to remember things like cell sizes and word alignment issues, create your own data structures, balance said stacks. It doesn't hold your hand and check your types or even protect your memory.

Put differently, Forth places an enormously high "cognitive load" (for lack of a better term) on the user. This is the price for being able to get every last byte and cycle out of a system without having to drop down to assembler and not having to create a super-efficient, complex compiler. What runs on my Devil's Canyon PC in 64-bit Gforth will (er, should) run on little 6502 8-bit Tali.

Pretty much every other language out there tries to reduce the cognitive load, because this lets the user think of other stuff and makes programming accessible to more people. The Zen of Python states (https://www.python.org/dev/peps/pep-0020/) Simple is better than complex, and its "executable pseudocode" is arguably the best of example of a low cognitive load -- it can't get much easier than Even if you don't know jack about computers, you sorta, kinda see what is happening here. Forth looks like the cat walked over your keyboard with the caps lock on.

What this means in practice (I tell myself) is that it's no use waiting for some flash of insight with Forth that will make everything suddenly come together and turn easy. It's hard, and it's going to stay hard, because that's the price you're paying for doing "more with less". The fun part, if you enjoy these things, is that you're allowed, even encouraged, to (try to) be clever, because if you're desperate enough to be using Forth for your project, that's probably what it is going to take. With every other language telling you to "keep it simple, stupid", that's kind of a nice change once in a while.