PUTing number on tos in fig-FORTH

[glockr]

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:

Code: Select all

PLUS   CLC
          LDA 0,X
          ADC 2,X
          STA 2,X
          LDA 1,X
          ADC 3,X
          STA 3,X
          INX
          INX
          JMP NEXT

while other operations like AND, etc. use this:

Code: Select all

XOR    LDA 0,X
          EOR 2,X
          PHA
          LDA 1,X
          EOR 3,X
          INX
          INX
          JMP PUT

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?

[barrym95838]

glockr wrote:

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.

[IamRob]

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

[resman]

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.

[BruceRMcF]

IamRob wrote:

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

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.

[JimBoyd]

In my Forth, I used POP in both + (plus) and AND . It is an ITC Forth so reducing how often NEXT executes was a design consideration. If I can squeeze a few bytes out of enough words then I can make more of the words in the kernel primitives while keeping the kernel about the same size, or even smaller.