Looking at the fig-FORTH listing, I see two different methods used for taking 2 values off the stack and replacing them with a single value. For example, PLUS uses this method:

while other operations like AND, etc. use this:

As near as I can tell, they both have the same stack effect (n1 n2 -- n3), the only difference is one is a few bytes longer but a few cycles faster, while the other is a few bytes shorter but a few cycles slower. Is that correct?

Yes, I think you summed it up. If you want to study a FORTH that makes sincere efforts to maximize efficiency with the NMOS instruction set, check out Charlie's PETTIL ... he utilizes a split data stack, a dedicated zp TOS, lots of fall-throughs and direct threading, with many many trade-offs carefully considered and meticulously balanced.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

I think AND is used far less than PLUS, so probably doesn't hurt to save a couple bytes at the expense of speed.

Some of the decisions used in figForth were a little surprising to save space. One that I rectified for myself a few years ago was the 6809 Forth for the TRS-80 CoCo called ColorForth (not to be confused with Chuck's later version called ColorForth). It was meant to fit in a cartridge ROM, so there were many places were NEXT was branched to, even though the 6809 was practically designed for Forth and could pull it off in two machine instructions. I went through the code (someone else had done the work to extract it and create a RAM based version of the cartridge) and in-lined NEXT in all the words that had branched to it. The funny thing is that I was using a modern cross assembler that must have done a better job with instruction encoding than the one figForth used, so the actual result was *smaller* than the original. I added a few handy words that had been missing and *still* had a smaller binary.

That sounds right ... in Phillip Koopman's 1989 "Stack Computers" he does a frequency of word use for four different benchmarks, and the average for + is 4.18% while the average for AND is 1.61%, so in userland + may be roughly two and a half times more frequent ... and if + is used more heavily than AND in the fig-Forth outer interpreter, the (system+userland) frequency might be higher still.