Subject:
|
RE: NQC versus Lego RCX Code Speed
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 5 Oct 2000 16:46:51 GMT
|
Original-From:
|
John A. Tamplin <JAT@LIVEONTHENET.COMnospam>
|
Viewed:
|
830 times
|
| |
|
|
On Thu, 5 Oct 2000, Mark Pulver wrote:
> I don't know for sure, but I would think that the RCX code is actually
> P-Code (Pseudo Code) and what's really running in the RCX itself is a
> P-Code interpreter.
>
> P-Code is a tokenized concept where a command like "get value of sensor 2"
> would simply become two bytes of data, e.g., 0x23 0x02 (not real values!).
> This saves a LOT of space for the end program, and obviously reduces the
> time required to send the program to the module.
>
> But... :)
>
> There's an engine running in the RCX that's reading through the data a byte
> at a time and interpreting it all. So, it reads the "0x23" and knows it's a
> command to read a sensor, then it reads the next byte "0x02" and knows
> that's the sensor to read.
>
> Then it executes the actual routine to read the sensor, and places the
> result somewhere in memory or on the stack.
>
> When you create NQC code, you're actually compiling code to it's native
> form for the processor. So, the processor isn't running a software based
> engine which is in turn reading your program data then working on it, the
> processor is running your code directly.
>
> The benefit of this is speed and cleaner access to all things in the RCX.
> The downfall is that errant program code or data has the possibility of
> crashing the RCX. As well, the program size is larger since you're
> generating the machine code for the processor itself.
No, the Lego GUI software and NQC both produce code for the same target
-- a simple interpreted virtual machine implemented in the firmware. I have
never looked at the code produced by the Lego GUI, but I can't imagine it
would be that much different since the graphical blocks are so minimal.
The one area where I think there might be a difference is task management,
since the Lego GUI can create watches on sensors that do something when
it is pressed, so it very well may be running a task that continuously
looks at the sensor. You can certainly program NQC that way, but the
examples I have seen tend to be more efficient, polling in the main loop
just before deciding on an action.
Kekoa's page has the internals of the standard firmware's bytecode.
John A. Tamplin LiveOnTheNet.COM, Inc.
jat@LiveOnTheNet.COM 2104 West Ferry Way
256/705-7007 - FAX 256/705-7100 Huntsville, AL 35801
|
|
Message is in Reply To:
 | | RE: NQC versus Lego RCX Code Speed
|
| Wilcox, Doug (11:04 AM 10.05.2000) wrote: >Hmm. This question seems to have gone the way of my PC-->IR Tower cable >question. > >Let me try to get at the point that most interests me--what is the >difference, at the RCX level, between programs coded (...) (24 years ago, 5-Oct-00, to lugnet.robotics)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
