The counterpart to the 2 instruction ITC NEXT is a 1 instruction DTC NEXT, namely RTS, where the S register is once again Forth's IP register. This has the same limitations with JSR, JSL, and interrupts as its ITC counterpart, since it also usurps the S register, so I won't repeat the limitations here. Additionally, the X register is left free, so it can be used as the data stack pointer.

Note that this is different from subroutine threading. In STC, the 65816 PC register is Forth's IP register, the S register is the return stack pointer, and RTS is EXIT (unnest). In this DTC implementation, the S register is the is Forth's IP register, and RTS is NEXT (the inner interpreter). STC is compiled into ML and is NOT interpreted. Here, the DTC is stored on the stack (as was the ITC with the 2 instruction NEXT), and it IS interpreted.

Also, RTL can also be used as a DTC NEXT. Interpretation is just as fast as using RTS since both instructions take 6 cycles. The difference is whether 24-bit addresses (RTL) or 16-bit addresses (RTS) will be interpreted. (The compiler must store addresses of the appropriate width, of course.)

Since there seems to be an uptick in interest in Forth lately, I'll mention that I've finally written a Forth kernel for the 65C816 using this NEXT technique, though I'm still in the process of debugging it.

I wrote it to experiment with this DTC technique rather than as a Forth I would actually use. I'm of the opinion that STC (in the colorForth vein) is the way to go, and this Forth hasn't really altered that belief. My plan is to get this working, then (at some point in the future) make an ITC version using the techinque described here:

viewtopic.php?t=584

But that's as far as I'll probably go with either of these Forths, as I've satisfied my own curiosity about the DTC technique, even before I've got the Forth up and running.

However, if there is actually any interest in this particular Forth, I could get it into a more releasable state. The kernel size is roughly 2k, which will obviously vary as I fix things, but that should be pretty close to the final size. The idea is that the kernel provides just enough to LOAD a more complete system. Specifically, if you are interested, let me know whether you want something that you can play with, or whether you're less interested in actually trying/installing it and more interested in source code you can read and learn from, as that will influence what I'd run up the flagpole as a first draft, so to speak. ("I want both" is also an acceptable answer.)

By the way, the way I've "solved" the interrupt issue (described in the ITC thread linked above) by my initial idea of not having interrupts at all, so YMMV with this Forth if you want to use interrupts. The NEXT/UNNEST (DOCOLON/EXIT) idea, as initally suggested by Garth in that thread, still seems viable to me (though I have not tried it) as long as you don't need immediate interrupt response.

If anyone has any questions, feel free to ask.

I would like to express my interest.

I will read those threads after getting a little more familiar with Forth. At my present level, I cannot make any informed decisions concerning which is better suited for me. However, having a well documented source is always a great thing.

Thanks!

Daryl

I'm interested - I have almost no experience with FORTH, but a very small kernel could be an asset for the 65Org16 (or 65Org32)

Edit: or... confused, because an '816 kernel might be relatively hard to port...

Cheers
Ed

Indeed, I have been lurking for 6502 related Forth info that could be easier to port to 65Org16. Back to lurking...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

You don't really need to know anything about Forth to understand the key difference between the two. Mine should be faster, but as is often the case, the trick I used to accomplish this has a tradeoff, and in this case it's a doozy. Your program is stored on the stack (!) which means that anything that pushes onto the stack will clobber your program, PHA, JSR, interrupts, etc. For instructions like JSL you can simply temporarily change the stack pointer to point to an area of RAM that can be safely overwritten (and restore the stack pointer afterwards). This is how I implemented character input and output. However interrupts are far trickier. The fact that the program is on the stack is why I consider this an experimental Forth rather than a practical one.

As for porting it to the 65org16, that should be possible but I'm not sure how easy it will wind up being. Offhand, TCS, TSC, TXY, and TYX are used in a bunch of places (but should be easy to implement on a 65org16 -- actually, having TSY and TYS would help considerably), MVN/MVP are used, but only in a couple of places (and could be replaced by a 6502-style move/copy), REP and SEP are used to switch between 8-bit and 16-bit accumulator, but those can simply be discarded, of course. I can't think of any places where exotic addressing modes (like [direct] or (stack,S),Y) are used. Most of it just uses 65C02 instructions in 16-bit mode. 65org16 portability was not a consideration when I wrote this, so if it winds up being easy that will be purely by accident.

The first milestone has been reached, in that the text interpreter works, and it is now possible to enter and execute colon definitions, like so:

: A 65 EMIT ; A

There's still more work left (it doesn't yet support entering negative numbers, e.g.) but hopefully this will help get the rest of it going sooner, as the 65C816 stack is not the most convenient location for a program when debugging assembly.

Thanks - you've given us some hope, anyway!

Great!

A brief status update: it's inching along. I've got a RAM-disk BLOCK driver and the assembler going. I still have to implement the rest of the CORE wordset along with some optional words, then it's onto the unfun part: documentation and converting the assembly into a more traditional syntax.

One thing I've been going back and forth on is whether to implement numeric entry of double (32-bit) numbers, e.g. 0. (with a trailing period) indicating a 32-bit number and 0 (without a trailing period) indicating a 16-bit number. You can always use 0 0 (i.e. two zeros) in place of the former. The trailing period feature is optional in ANS Forth, and it's not very difficult to implement, but I haven't done so yet and I'm not sure it's worth the trouble. I thought about using DEFERred words, so that it could be added later, but that got ugly. If you have an opinion ("add it" or "leave it"), feel free to reply here or via PM or e-mail if you wish.

A useful feature, I'd say. If you deal much with doubles I think you'll find it handy. Although it's true as you say that the workaround option is to separately state the high and low words, to do it that way is error-prone and less readable in the source code. Better to state the entire number as one entire number, IMO.

And there's scarcely any downside. It's easy to implement, and it doesn't prevent you from using the workaround should you feel so inclined. Just my $.02 worth...

BTW in Fig Forth the period can appear anywhere in the string; it doesn't have to be trailing. Has ANSI changed this, then?

-- Jeff

I agree with Jeff, its not hard to add and has little to no downside. It will help keep source readable.

Daryl

Consulting the standard itself at http://www.taygeta.com/forth/dpans8.htm and the appendix A.8, I can find no place in the ANS(I) standard which defines precise dot-notation syntax. GForth and SwiftForth, both well-respected implementations of ANS Forth, allow the period to appear anywhere, as far as I can see.

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

The people have spoken! I suppose the strongest argument in favor is that the 65C816 address are 2 cells, and the "strongest" argument against is that I was half-hoping to weasel out of implementing it.

Section 8.3.2. in the link above is what I was referring to. My interpretation of the spec is that an ANS-compliant implementation must at minimum support the trailing period. And an implementation is free to go above and beyond that and support the period anywhere (and use DPL), since that does not conflict with anything else specified. (My guess is that they had trouble reaching a consensus about whether 1.0 should be considered a double cell integer or a floating point number, so they left it as implementer's choice. There's a corresponding section in the floating point wordset.) Thus, for something which is supposed to work across many implementations, you'd use the trailing period, since that is supported "everywhere". For something that's only going to be run on one implementation, you could take advantage of its specific features and use the extended syntax.

I've never really made any use of the "period anywhere" feature or DPL, so I'm in the habit of using a trailing period. I'll probably just support the minimum syntax at first, and the extended syntax could be added later for or by anyone who misses it.

dclxvi:

Just looking for some information for a potential project. In the following quote, you refer to some unimplemented instructions in the 65Org16 instruction set that may be useful for implementation of Forth. Can you think of any other instructions or features, in the spirit of a 6502/65816, that would also be of benefit? I have thought of a JSR (A), where the contents of the accumulator are a pointer to a function, which may be of benefit to a Forth implementation. Another is a second stack pointer to avoid some of the memory and return stack management issues you have discussed in this thread. (If you prefer to start another thread for this sub-topic I'll let you take the lead.)

_________________
Michael A.