To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 12686
12685  |  12687
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*saynotospam*.com>
Viewed: 
686 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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR