 | | 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)
|
| |
| | 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)
|
| |
| | 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
|
|
(...) 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)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) Are you sure you mean each of the POSSIBLE threads? I did test to see whether it was slower to count to 1000 with another task running, and it was. Not half as fast, only about 30% slower. --Ben (25 years ago, 3-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) half (...) Yes, it seems to switch between two 'modes', one being effectively single tasking, and the other multi-tasking. This gives the change you are seeing. The 'loop' time, can be measured very easily with a scope, by setting a motor (...) (25 years ago, 3-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) What is in a "counter loop iteration" ? Please share the NQC program you used to measure this with us. I fail to believe that a simple loop runs this slow. 16000 cycles per loop iteration does not sound right to me. -Kekoa (25 years ago, 4-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) From memory, the NQC was: int count; task main() { count = 0; CreateDatalog(100); ClearTimer(Timer(0)); while (count <= 1024) { if (count & 0xff == 0) AddToDatalog(Timer(0)); count += 1; } } The downloaded datalog will show the last log entry (...) (25 years ago, 5-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
Its been a long time since I looked at the firmware in detail, but is it possible that the bytecode interpreter is driven from one of the timer chains? If this was the case, it wouldn't matter if the CPU could execute the bytecode in 200 cycles...it (...) (25 years ago, 5-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) Hmm. If so, an interesting option for a theoretical replacement-but- compatible firmware to have would be the ability to do things as fast as possible. (Of course, it'd have to be an option, since it's possible that some badly-designed code (...) (25 years ago, 5-Jan-00, to lugnet.robotics.rcx)
|
| |
| | Re: Speed of RCX interpreting bytecodes: slow
|
|
(...) I'm pretty sure this is not the case. The interpreter constantly runs the "execute bytecode" function if it is sitting idle. -Kekoa (25 years ago, 5-Jan-00, to lugnet.robotics.rcx)
|
