Druzyek's speed comparisons of assembly vs C vs Forth on the 6502 was very interesting to take a look at. If you haven't seen it already, you can find it at
http://calc6502.com/RobotGame/summary.html#Results
Scroll down just a little bit to see the table of results.

One of the things I noticed is that many of the slower (<10% the speed of assembly) items had nested do loops in them and I was just curious what the penalty/overhead of using 16-bit loop variables for small counts (eg. stuff you'd count in X or Y in assembly). Fortunately, because Forth is awesome, I can scratch that curiosity itch and discover that the answer is "not as much as I was expecting, but more than double", which totally makes sense to me for using a 16-bit index vs an 8-bit one.

Leepivonka had provided some "replacement" words for do loops, so that made me want to try that myself. Rather than replace Tali2's do-loop words, these words are meant to compliment them. They use the Y register similar to how one might in assembly to count down to zero, so only the upper limit is given, and it's limited to 8-bits (but you can get 256 loops by specifying 0 as the starting value). Because these words use the Y register, I just made word names with a "Y" prefix. After writing this, I realized that it doesn't really matter which register is used, and A could have been used just as well (and sometimes is used because Tali2 has a PUSH-A macro to get A on the top of the Forth data stack.

For those that are interested, here is my code and the results I got (using the cycle counting tests available in the simulated Tali2 test suite).

Code:

\ PROGRAMMER  : Sam Colwell
\ FILE        : yloop.fs
\ DATE        : 2021-04
\ DESCRIPTION : For small loops of 256 or less, these words will use
\ the Y register in cowntdown mode only (eg load with 8-bit starting
\ count and it will always count down to zero) which is generally useful
\ for code that needs to run a number of times, but doesn't need to
\ control the direction of the counting (in exchange for speed).

\ Add the assembler.
assembler-wordlist >order

: YDO  ( C: -- addr) ( R: n --)  ( Start loop that will run n times )
  0 POSTPONE LDY.X          \ Load Y with the starting value.
  POSTPONE INX POSTPONE INX \ Remove value from stack.
  HERE          \ Save location to loop back to (leave on stack)
  POSTPONE PHY  \ Save current index to return stack.
; IMMEDIATE COMPILE-ONLY

: YLOOP ( C: addr -- ) ( R: -- ) ( Loop back up to start if y nonzero)
  POSTPONE PLY    \ Get current index from return stack.             
  POSTPONE DEY    \ Count this iteration.                             
  3 POSTPONE BEQ  \ If we reached zero, continue on (branch over jump)
  POSTPONE JMP    \ otherwise jump to the top of the loop.
  \ The jump should pull it's address from the stack
  \ It was placed there by the ydo word.
; IMMEDIATE COMPILE-ONLY

: YI
  \ The current index is on the return stack.
  POSTPONE PLA    \ Get the index into A and put it on the Forth stack.
  POSTPONE PHA
  POSTPONE PUSH-A \ This is a macro in Tali to put the value in A on TOS.
; IMMEDIATE COMPILE-ONLY

: YJ
  \ The index from the outer loop is the SECOND byte on the return stack.
  POSTPONE PLY \ Pull the one we don't want into Y
  POSTPONE PLA \ Pull the one we do want into A
  POSTPONE PHA \ Put both of them back (in the right order)
  POSTPONE PHY
  POSTPONE PUSH-A \ Put the J index on the Forth stack.
; IMMEDIATE COMPILE-ONLY

Tali2's assembler words are immediate. By using POSTPONE, that essentially makes these assembly macros. I could have used a runtime word and COMPILEd it, but these were so short it made more sense to me this way.

Next is a basic functionality test:

Code:

\ Try it out.
: testing
  5 ydo
     3 ydo
        cr ." yi=" yi .  ." yj=" yj .
     yloop
  yloop
;


\ Results:
testing
yi=3 yj=5
yi=2 yj=5
yi=1 yj=5
yi=3 yj=4
yi=2 yj=4
yi=1 yj=4
yi=3 yj=3
yi=2 yj=3
yi=1 yj=3
yi=3 yj=2
yi=2 yj=2
yi=1 yj=2
yi=3 yj=1
yi=2 yj=1
yi=1 yj=1  ok

Note that it counts down from the starting value, including the starting value, but does not run with the value 0.

Finally, the cycle counting tests (the cycle-test word takes the XT and prints the number of CPU cycles):

Code:

\ Cycle-Test RESULTS:
decimal
: testingy   255 ydo  yloop ;
: testingdo  255 0 do  loop ;
: testingyi  255 ydo  yi drop  yloop ;
: testingdoi 255 0 do  i drop  loop ;
: testingyy    255 ydo   255 ydo  yloop  yloop ;
: testingdodo  255 0 do  255 0 do  loop  loop ;
: testingyyij    255 ydo   255 ydo yi yj 2drop  yloop  yloop ;
: testingdodoij  255 0 do  255 0 do  i j 2drop  loop  loop ;

' testingy           cycle_test   CYCLES: 3660  ok
' testingdo          cycle_test   CYCLES: 16775  ok

' testingyi          cycle_test   CYCLES: 13605  ok
' testingdoi         cycle_test   CYCLES: 32075  ok

' testingyy          cycle_test   CYCLES: 933900  ok
' testingdodo        cycle_test   CYCLES: 4291340  ok

' testingyyij        cycle_test   CYCLES: 5420625  ok
' testingdodoij      cycle_test   CYCLES: 11053940  ok

These are trivial tests, but the results are enlightening. For each group above, the first one is the simpler 8-bit "Y" version of the loop running 255 times, and then using the regular do loop words running 255 times. I then have tests using i (which I just drop) to show the effects of getting the index, and then I do nested loops (without and then with indices).

I very much enjoy the way these new looping words are just as "valid" as the words that Tali2 comes with, and I could use them in places where I needed to squeeze some extra cycles out of a routine.

Cool idea! Out of curiosity, could you compare the cycles of a DO that still uses the R stack but only the lower 8 bits?

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

I love the Forth language for it's compactness and elegance, but in my limited experience it is slower than assembler. For example:

I wrote an ASCII art Mandelbrot in Forth to demonstrate how much faster it is than Basic. I was pleased with the results because the Forth code was about five times faster, although fixed point integer arithmetic was likely a big reason why.

I then rewrote it in assembler and found that it was four times faster than Forth! See: viewtopic.php?f=2&t=6347

If you read the assembler it uses macros that emulate Forth words, and it is identical in structure to the Forth program with two exceptions. First, the macros inline many operations rather than a JSR to a subroutine. Second, I use 8.8 fixed point and byte operations rather than lshift and rshift to rescale after a multiply.

I am not sure which of those caused the bump in performance. The first is intrinsic to the way many Forths work and harder to fix. But the second might be amenable to Garth's idea that rewriting the rescale function in assembler with byte level operations might lift Forth's performance.

Correct, I did say that some of the slowness in the results is due to lack of experience on my part, so I don't want people to take the numbers in the charts as completely representative. However, I still stand by the conclusion that using Forth on the 6502 entails an extreme loss of performance. That can be demonstrated by analyzing the underlying assembly, and I tried to cover that briefly in my article.

You have said this many times, but my objection is this only really applies to some projects. I've gone back and watched years and years of the presentations at the SVFIG meetings and noticed that the programmers there tend to apply Forth to one or a small handful of problems and then claim based on that that it's superior to C and competing languages at all times and in all circumstances. One guy has been showing off a small robot he made in the 90s programmed in Forth and sold to educational markets and claims that Forth is the only language that makes sense for robots. I'm not sure to begin with that it was the best choice in the 90s for an educational robot, much less that it's always the best choice for educational robots nowadays, much less for all robots at all times nowadays. People tend to put on blinders when they find something that works for them and demonstrate the "If it works for me, it ought to be good enough for anyone" fallacy.

On the other hand, I can see how I put on my own blinders and might criticize Forth too heavily sometimes since I care about performance, which isn't a concern for a lot of other people's projects. I got interested in the 6502 to make programmable calculators where you're never thinking about making a device that is "fast enough" but one where you need to maximize performance since you're letting users create their own programs on the device. Squeezing out an extra 5-10% of performance is a huge win if that's horsepower you can hand over to the user to do calculations with. Compare this to something like a microwave. I've noticed that mine has a noticeable delay between the time I press a button and it responds with a beep. Adding more horsepower to get the delay down is a waste of time and won't sell more microwaves. A lot of engineering is aimed at producing "good enough" rather than maximizing performance where it wouldn't make a difference anyway. If you're able to hit those engineering goals with Forth, or by rewriting 5-10% in assembly as you suggested, then that sounds like success to me. My objection is to the idea that this method works for all projects all the time. If over half of my ROM is taken up by calculations that I need to be really fast, there just isn't a 5-10% chunk for you to find and rewrite because it's equally important that all of them be fast. Like I said, however, I can see the appeal of using Forth for something where you don't miss the extra performance, and I don't mean to say it's a bad choice just because it doesn't work for what I want to do.

This is really interesting. Have you looked at Mecrisp Forth? It uses a very cheap ARM board as a tether to program MSP430 microcontrollers. It generates optimized assembly for the target, so no kernal or thread overhead on the MSP430. There's also a version that uses an ARM board to program other ARM boards. Some of the guys involved with it claim it's only about 3 times slower than C, which is pretty darn impressive. One of the optimizing Forths for Windows leaves the majority of registers vacant. This seems like a waste, though from people I've talked to who know a lot more about x86 than I do, thrashing the stack and ignoring the extra registers may not really have a speed penalty on modern processors. I would love to know more.

Chuck Moore has said this kind of thing in his presentations before and it's almost certainly nonsense. I think it belongs in the same garbage bin as saying that pure Forth on the 6502 is "only 25% slower" than the equivalent assembly, which pops up on other forums from time to time. Please let me know if you have any way of verifying this (EDIT: this meaning the claim about C programmers). I've often thought about how you would organize a comparison by having a C and Forth team solve the same problem.

If true, that man is to be respected, celebrated and admired. However ... I have a feeling that it might be foolish to depend on him for updates and support, or to expect him to consistently repeat that inspired feat of excellence.

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

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

To say it's superior at all times and in all circumstances is rather a sweeping statement. No way do I endorse talk like that. Perhaps it's a case of the Vocal Minority making the most noise. I hope no-one makes the mistake of supposing all Forth adherents are afflicted with such an unreasoning excess of zeal.

Minor correction. Yes, nowadays I use a parallel link to the host. But back in my Wonder Years ™ there was no host.

I credit Forth with letting me pull off stuff like this (MCS48 development system)... long before I acquired my first 8088 box.

-- Jeff

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

I agree. The topic started out about making loops faster, so discussing the role of performance is relevant in my opinion.

Hmm, maybe some historical context would help. I remember waiting 30+ seconds to cross-compile relatively small 68000 binaries written in C on my (old for the time) Windows machine in 2002. Now I can compile much larger binaries with gcc in a second or two. Maybe the interactivity of Forth had more of a payoff at the time than it does today. I do wonder if many of the Forth guys who talk about how insufferably awful C is have touched a C compiler in the last decade or two, at least when they criticize speed and interactivity. No comments on Garth's beefs with C page since they seem accurate and are taste-based.

I think this is a good illustration of the fallacy I mentioned above. It's begging the question to assume I even have a threshold and a realtime demand to keep up with. I don't. If I have to wait 9 seconds for a calculation to complete instead of 10, then I'm really happy about that. This applies to all kinds of other things as well like video games where 10% more performance might let me put 10 objects on the screen at once instead of 9. That lets me make better games, and the user does notice and value the difference.

Right, there are all kinds of engineering problems where this is definitely the case. The point I'm making here is that there are also all kinds of other problems where that is not the case and that 30% speedup or even 10% speedup is really, really important. Wouldn't you agree that this is true for some projects even if it's not true for the ones you have in mind?

That's a good question. I see where your method is valuable when that has an exact answer. In my case, it doesn't, which is why I'm pointing out that that method doesn't always work.

I think you're right. There seems to be an uncommonly high number of just that type of overzealous adherent in the Forth community, but I didn't mean it was the majority.

EDIT: and to bring us back on topic as Garth suggested, didn't someone find out TaliForth 2 was pushing a 1 on the stack then falling through to +LOOP? It might be worth looking at 8 and 16-bit versions that don't do this if you're looking at new DO...LOOP versions.

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

If that's true, it might be partially my fault, since ISTR mentioning an idea like that to Scot a few years back, without considering the potential performance hit.

[edit: yep, guilty!]

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

YLoop could be 3 bytes shorter & a few cycles faster if you compile a short branch instead of a long branch in the cases where a short branch will reach.


Another way to squeeze out some more cycles from a YLoop iteration, at the cost of more bytes & cycles for loop initialization & termination, is to decrement a zero-page location instead of ply, dey, iny, .


I've also implemented YDo & friends on 65816F ( a subroutine-threaded FORTH running on the 65816 in native mode using 16 bits)

This speed up seems to only work for STC Forths. Is that correct?

When doing a direct jump back to YDO on an ITC Forth, Forth's IP pointer also has to be updated to start processing to just after the YDO that is being returned to. Otherwise the IP pointer just continues through the YLOOP as if nothing happened. I do get one iteration of YI and YJ though before it crashes.

Jumping back to ML code that has Forth words in between would require an extra step to update Forth's IP pointer.

The idea of using an 8-bit down counter instead of a 16-bit index & limit for higher speed should apply to any FORTH where the machine (like a 6502) can implement it in faster machine code.

So far this thread has focused on implementations in Tali FORTH (a Subroutine-Threaded-Code FORTH for the 6502) that generate inline machine code.
The idea can be implemented on an Indirect-Threaded-Code FORTH, but as you've noted, the details of the implementation will be different.

Here is a quick untested attempt for FIG FORTH for 6502 that uses the ITC word structure & flow control.