Casually glancing through the threads, it seems that the '816 Forth are basically 16-Bit Forths, with 64K memory, using the enhanced '816 instruction set.

Rather than something different that can leverage the segmented nature of the CPU.

In truth, I haven't quite grokked the nature of the '816. More so than the Intel's segmented architecture, the '816 does seem more like "a bunch of little 6502s" rather than a single CPU with a large memory space.

Maybe I'm misunderstanding, but this:

Were I to start the program running at 01:FFFE, in the end, the PC WILL NOT cross the 64K boundary, but will rather wrap around on the page register. Granted, a single piece of code can access data throughout the memory space, and can jump to arbitrary segments of code. But, in the end, you do, really, have a bunch of 64K instances that are all little islands on the CPU.

Anyway, given that, what kind of thoughts have there been about a segmented Forth runtime. You could separate the headers and dictionary code, maybe. You could easily create a heap that lives on its own segment, unaffected by the vocabulary. 64K of BLOCK buffers…whee… I'm sure there was some thinking about this for the Intel systems.

Just curious what folks have thought about here.

In 1994 I created a hybrid 16-/32-bit Forth for 8088, and if I ever get time I'll do the same for '816.

Tokens are 16-bit, and the size of the dictionary is limited to 64K. I don't have a problem with that. 64K is a LOT of Forth -- I'm unlikely to ever need that much code space. But of course data space is a whole different story.

All cells, whether in memory or on the RStack or PStack, are 32 bit. When a cell contains an address, only the lower bits are used (24 bits for '816, yielding a flat 16 MB; for 8088 flat, 20-bit addresses are the norm, yielding 1MB). Data operations such as AND OR + etc are 32-bit, requiring double precision. If you wish you can cheat and also have some fast 16- or 8-bit words but the cells themselves are always 32 bit. This avoids the stack gymnastics (and bugs) I experienced with FIG Forth, where a 32-bit item consumed two cells but all other items consumed one. SWAPping a 16-bit item and a 32-bit item required you to ROT, and so on -- you get the idea. I never, never want to go there again!!

F32 (as the x86 version is called) remains in use to this day. Actually a rewrite of a previous Forth, it has a compiler and interpreter roughly equivalent to those of FIG Forth. Darn handy tool. The biggest boon is having the freedom to define and access data objects bigger than 64K -- without requiring special measures to do so. Stuff just works.

I concede that other approaches deserve consideration. An STC Forth could easily and efficiently provide 16MB of code space, if that's desired. But with threading other than STC it seems to me efficiency would suffer. It's a whole lot easier to keep things snappy when the tokens are only 16-bit.

-- Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I'm neither a Forth user or Forth expert, but I do know one or two things about writing software. So while I can't comment on using Forth, I can definitely comment on developing a Forth kernel.

Firstly, my pedantic tendencies prompt me to point out that the 65C816 is not "segmented." It is "banked," which is completely different than segmentation a la the Intel 8086.

As you noted, bank boundaries matter in a running program, as wrapping PC will not increment PB. Hence the maximum possible size of a program, assuming it is loaded into any bank other than $00, is 65,536 bytes, which prompts a question. When was the last time you encountered a 6502 program anywhere near that size? Even in the days when professional grade word processors, database engines and spreadsheets were written for the 6502, few exceeded 15KB in size. The bank boundary imposition on a program is, in my opinion, a non-problem.

Turning to load/store operations, they follow an entirely different set of rules, depending on whether the operation ultimately touches direct page, the hardware stack or elsewhere. Summed up:

• If a load/store access is to direct page or the stack the bank is automatically $00.
  
  
• If a load/store access is to an absolute location and is expressed as a 16 bit address ("base" address), the effective address is DB×$010000+BASE+INDEX. For example, if DB contains $01 and .X is loaded with $02, the instruction LDA $8000,X generates an effective address of $018002. If the sum of the base address and .X exceeds $FFFF access will occur at (DB+1)×$010000+BASE+INDEX. Hence it is possible to cross bank boundaries with ordinary 16 bit indexed addressing.
  
  
• If a load/store access is to an absolute location and is expressed as a 24 bit address ("base" address), the effective address is BASE+INDEX. For example, if .X is loaded with $02, the instruction LDA $038000,X generates an effective address of $038002. The instruction LDA $02FFFF,X when .X is loaded with $FFFF generates an effective address of $03FFFE.

Additional addressing flexibility is possible via use of the indirect long modes. For example, LDA [PTR],Y treats PTR, PTR+1 and PTR+2 as a 24 bit direct page pointer from which the target address is gotten. With this addressing mode DB is ignored, as the data bank is specified in PTR+2.

Essentially, the 65C816 has a flat addressing model for load/store operations, other than direct page and stack accesses. So, no, it is not a "a bunch of little 6502s."


In any program running on the '816, not just Forth, there is no requirement that the data be anywhere near the program itself. With the 65C02, everything has to fit within the 64KB address space of that MPU. With the '816, that address space is now (potentially) 16,000KB. Hence there is a fundamental difference between writing 65C02 programs and writing 65C816 equivalents. Addressing with the '816 is much more expansive and flexible. Naturally, the enhanced instruction set and availability of 16 bit registers open the door to much different and more efficient algorithms.

Considering Forth, the main dynamic data structures are the dictionary and the data stack. With the '816, the dictionary can be any size you want up to the limits of memory and can start anywhere in address space that is convenient, whether in the same bank in which the program is running or a different one. If the possibility exists of the dictionary growing to the point where it happens to cross a bank boundary you would use 24 bit addressing to access it. The basic methods of indexing are the same as with the 65C02, except an index can be 16 bits in size instead of 8, which greatly simplifies the processing of data structures that cross page boundaries. It's a matter of rethinking your methods, instead of using the traditional 8 bit approach.

Forth on the 6502 has customarily maintained the data stack on page zero. You coul do the same with the '816, except you can also relocate its direct page (page zero) to anywhere within bank $00 by changing the 16 bit value in DP (direct page register). For example, if you load $C200 into DP a instruction such as LDA ($00,X) will actually be directed to $C200 and it will be as though you had written LDA ($C200,X). The advantage of this feature is you could maintain multiple data stacks, or you could separate the data stack entirely from the physical page zero in the machine and reserve the physical page zero for such things as pointers, indices and the like.

Aside from the above, I don't have anything else specific to offer on Forth on the 65C816. However, Forth is no different than any other program when it comes to system usage. The '816 offers a lot more in that regard and as Garth has mentioned in the past, Forth written natively for the '816 will run substantially faster than it will on a 65C02, even at the same clock speed.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I briefly used a Forth version on the PC 25+ years ago that used separate 64KB spaces for code, headers, and data, basically giving up to 192K of memory usage for a 16-bit Forth. I can imagine that would come with its own set of problems if I became a serious user.

Since 64K of Forth is such a huge program space for single-man teams, when I get back to my '816 Forth, my related Forth focus for accessing more memory will just be the long fetches and stores and related instructions which weren't relevant on the 65802. For code, since long jumps and subroutines calls as well as indexed jumps can change the program bank implicitly, I will have some of Jeff's fast-I/O magic taking a lot of machine-language code space in other banks. A few long primitives could do the heavy work in another bank before coming back to bank 0, but that won't gain you much. Since stacks and vectors are always in bank 0, I suppose you could keep those from taking Forth code space by putting the Forth in another bank, but again that won't save you more than a handful of pages, max.

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

Back in the day I added long fetches and stores to the FIG Forth that runs on my KK Computer, and I treated the addresses in the same way that FIG treats 32-bit integers, which is to use two cells. That wasn't a good decision. I've already touched on this, but I found that the intermingling of single and double items on stack resulted in code that was hard to write and even harder to read. That's because the number of items will be different when some/all of them are of the long-address type.

To anyone contemplating adding long fetches and stores (or dealing with >16-bit values in any way), I suggest you consider arranging that any cell on stack always has 32 bits available, even if the high word often goes unused. A split stack or "ghost stack" is one of the possible ways to meet this requirement, without the performance penalty some of you will be concerned about (ie; you can still use INX INX to drop an item; you don't need INX INX INX INX).


(ps- "indexed jumps can change the program bank implicitly" Huh?? Did I miss something, Garth?)

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Arguably a reason we find small 6502 programs is that they work on constrained systems (notably 48K systems), where memory is precious. With more memory available, large programs are possible. I don't know how big programs native for the Apple II GS were. I don't even know how they were structured.


Historically, Forth word references (outside of token based Forths) are absolute addresses. So, were you to forego the 64K bank limitations, all of your addresses become, essentially, 32 bit. In fact, you should probably go with a 32 bit stack word as well.

However, you still have the issue of being cognizant of the 64k boundary, especially, for CODE words. You can't have a code word transition a boundary, or it will fail. Not insurmountable, but the CODE word compiler would effectively have to build the word internally, and then ensure the boundary has not been crossed, and if so, it would have to push the entire word over the boundary.

Also, you would have to do this with any of the more native implementations, like subroutine threading, since internally they would always have this problem.

Just seems to me, perhaps naively, that the '816 is far more comfortable in 64K chunks, rather than a large, single, linear space. And curious of ways a Forth could leverage that more.

Only jumps and subroutine calls with 24 bit addresses can cross bank boundaries. Sixteen bit jumps and relative branches are confined to the current program bank.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Of course -- that's why they're 24-bit and 16-bit. But Garth must've been thinking about something else when he mentioned an indexed jump changing the program bank. Even on '816 the only indexed jump is JMP (abs,X), which is 16-bit, right?

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I'd have to disagree with that. As an example, the Superscript 128 word processor for the Commodore 128 had a single binary that was the entire program. That binary was around 20KB, and this was a full-featured word processor by the standards of the 1980s and even into the 1990s. SS128 took advantage of the second bank of 64KB and stored the document being processed in it, which increased the maximum possible size by a considerable amount when compared to Superscript 64, which ran on the C-64. There was also a substantial cut-and-paste buffer that was in the same bank with the program itself.

Well-written assembly language tends to produce compact binaries. The same can't be said for compilers, especially modern ones. So I'd say the reason we see small 6502 programs is more due to the nature of assembly language and the skill of the programmer, rather than due to a constraint of address space. Don't forget that when the paint was still drying on the original IBM PC in 1981, it shipped with only 16KB, with 64KB being an expensive option (and 256KB being an even more expensive option). 16 KB sounds constrained to me, yet sophisticated software, e.g., Lotus 123, was written to run in that tight space. BTW, Lotus at that time was written entirely in 8088 assembly language.


Surprisingly, 32 bit data are readily handled with the 65C816. The program I have developed for creating a filesystem on disk uses 32 bits for all filesystem pointers, and uses 64 bit integer math to carry out the necessary calculations. A 32 bit stack word in Forth would require two reads or writes to access a data item, but that doesn't incur too much of a performance penalty. However, direct page space could be quickly consumed if that is where the data stack is located.


This is where my lack of knowledge about Forth fails me. Exactly what is it the CODE work compiler is building?


64KB chunks for programs. Data have no such constraint.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

I don't know what that would be. The only other means by which a bank boundary can be programmatically crossed is by generating an interrupt.


Correct. There is also JSR (abs,X), again which works within the confines of the current program bank.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Good idea! It would add absolutely no overhead to most words, and the "ghost stack" wouldn't need to be in DP. I'd have to change my programming thinking on a few things, but like you say, it makes stack manipulation easier.


Thanks for straightening me out. It has been a long time since I paid much attention to my '816 Forth. I just checked The Addressing Modes reference section of WDC's programming manual again, and what I said applies only to indexing data across bank boundaries, not program. I have notes penciled in there, including related questions that still lack answers, but again they're about data and effects on DBR, not program and PBR. When I get going on it again (which should be this year), in addition to experimenting, I should check with someone like BDD who has spent a lot of time programming for the '816 and get some of these questions ironed out, things I never did find clear answers to in the book.

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

A code definition, or primitive, is a Forth word defined in assembly language. This is as opposed to a colon definition, or secondary, which is defined in terms of other Forth words. Those other words could be defined either way, whether code or colon definitions. In STC (subroutine-threaded code), there wouldn't really be any difference here, because program execution in a series of JSRs or JSLs would still fail to proceed across the bank boundary, whereas in one of the other threading methods, secondaries are just lists of addresses or tokens usually picked up by an inner loop of some sort (called NEXT), and that loop could increment the bank when the boundary is reached.

"Colon" definitions are called so because the colon (":") in Forth turns on the compiler (plus does some housekeeping things) when you start a high-level definition. The definition is ended with the semicolon (";"). Usage of these is shown in the first chapter of "Starting Forth" which is available online, somewhat modernized from its original version but with still with the original cartoons, at https://www.forth.com/starting-forth/1- ... ictionary/ . The author, Leo Brodie, is quite a comedian.

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

Right, simply, high level Forth words are data to an interpreter, whereas CODE words are primitives that are simply executed.

It's not an insurmountable problem, it's just a bit of complication to what is nominally a simple compilation process.

6502 Fig Forth has a comment of an offset to ensure that no addresses end in $XXFF to get around the JMP bug.

Given the generally compact nature of 6502 machine language, I'm still not seeing much of a problem here. It falls more into the realm of good memory management than anything else. There's nothing to stop the compiler from stuffing multiple CODE functions into any given area of RAM. Surely the CODE compiler can figure out how much space the object code will occupy and plan accordingly.

As I earlier noted in one of my diatribes, the number one mistake made by 65C02 programmers in writing for the 65C816 is to continue writing for the 65C02. The two processors demand different ways of thinking, not only because of the differences in address space, but also because the '816 has capabilities that don't exist in the 'C02. Once the programmer learns how to efficiently use 16 bit registers and instructions such as XBA, as well as stack pointer relative addressing, he or she is writing native '816 code, not rehashed 'C02 code.

As for the JMP ($xxFF) bug, that's an NMOS aberration that was eliminated in the 65C02. New designs should not be using NMOS parts.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

There is an LDA & STA [DP] and [DP],Y, but no [DP,X]; so since you'd have to move an address to N in DP anyway to read or write the final effective address via a long indirect, there appears to be no penalty in having the "ghost stack" for the high cell.

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