 | | IDE using Forth ?
|
|
How about a Forth based environment running on the PC? It would not be that difficult to move the RCX based compiler to be a cross compiler on the PC. One would be able to run in two modes - "native" through a Forth based terminal (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.pbforth)
|
| |
| | Re: What should be in the next version of RcxCC
|
|
(...) After spending another two nights with NQC & RcxCC (:-), another wish came up in my mind quite clearly: I use the "Watching the RCX" tool window quite frequently for debugging, and I'd find it great if it could display the *names* of the (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: What should be in the next version of RcxCC
|
|
How about a more generalized interface to the pbForth system. Although Ralph Hempel believes this to be unnecessary, I find the RcxCC interface quite appealing. Harald Striepe (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.nqc)
|
| |
| | RE: Thought on pbForth
|
|
(...) Wow! Great company indeed! (...) This would be a good idea, and one day, pbForth will get there. I used to ship a Tcl based shell with pbForth, but it wasn't working well on all platforms. Here's why pbForth is the way it is, and forgive the (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx.pbforth)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) Yes. It is important to realise, that the RCX, does not perhaps do the interpretation in the way you think. In each 'loop', it executes one instruction from each of the possible threads, and also reads the A-D's, on each sensor, and updates to (...) (25 years ago, 2-Jan-00, to lugnet.robotics.rcx)
|
| |
| | 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)
|
