 | | Thought on pbForth
|
|
Ralph, This is something that has been bothering me about pbForth ever since you developed it... please do not take this as an attack against you or your efforts. I do, in fact, truly believe that you have contributed significantly to RCX (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.pbforth)
|
| |
| | RE: Speed of RCX interpreting bytecodes: slow
|
|
Ben jackson wrote... (...) Yes, that's why pbForth is "almost ANSI" which means that it is as close to standard ANSI Forth as I could get. And PS is NOT Forth, it is Forth-like. (...) That just adds about 4 items to a datalog, (once every 256 loops, (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx)
|
| |
| | RE: Speed of RCX interpreting bytecodes: slow
|
|
(...) OK, I did some basic timing experiments....for pbForth. : TEST1 10000 0 DO LOOP ; \ This is a hard loop of 10000 iterations : TEST2 10000 0 DO I DROP LOOP ; \ Same loop except the loop index is put on the \ stack and dropped - a no-op (...) (25 years ago, 1-Jan-00, to lugnet.robotics.rcx)
|
| |
| | RE: Speed of RCX interpreting bytecodes: slow
|
|
(...) Check out pbForth too! I will get around to doing some basic loop timing if you ask me nicely and tell me what kinds of test would be useful to do! pbForth is ready to run right out of the box, there is no compiler to mess with, and it's fun (...) (25 years ago, 1-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Speed of RCX interpreting bytecodes: slow
|
|
While working on the barcode scanner I decided to see just how fast the RCX could loop. A simple NQC program can do about 1000 counter loop iterations in about 100 ticks, or 1 iteration/ms. This is shockingly slow. The native H8/329 is clocked at (...) (25 years ago, 1-Jan-00, to lugnet.robotics.rcx)
|
