Subject:
|
Re: NQC versus Lego RCX Code Speed
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 25 Oct 2000 04:46:11 GMT
|
Viewed:
|
1074 times
|
| |
|
|
In article
<85669FE51E37D411B97900B0D022E9C417FA92@mail.medivation.com>, "Wilcox,
Doug" <Doug.Wilcox@iMcKesson.com> wrote:
> Let me try to get at the point that most interests me--what is the
> difference, at the RCX level, between programs coded in NQC and programs
> coded in RCX Code. Is the compiled NQC code closer to the "machine level"?
>
> Dave Baum, are you out there?
Sorry for the delay...I haven't been keeping up with lugnet.robotics as
much as I should.
NQC generates the same sort of bytecodes that RCX Code does, so they are
both at the same "level" (specifically bytecodes executed by an
interpreter in the RCX firmware).
However, the code generation in NQC is generally a bit tighter than
you'll get from RCX Code for several reasons...
1) RCX Code has a code generation model that relies heavily on multiple
tasks. Task 0 is used to poll all the conditions of the sensor
watchers. The "stacks" of blocks that are the actions associated with
these watchers are put in their own tasks which are then started when
the sensor condition is met. This in itself isn't too big a hit, but
then there's a lot of bookkeeping that goes along with checking the
sensors (so you don't double-start an action, etc). Overall this
generates a lot of overhead that just isn't there with NQC.
2) NQC has a variety of constructs and API calls that tend to allow more
concise description of the problem (and typically result in more concise
bytecodes). For example, the ability to have compound conditions in an
NQC "if" statement avoids the excessive nesting or duplication of
actions that you'd see in an RCX Code program that had to check multiple
conditions. In theory, a really smart RCX Code genearator could also
optimize such cases, but its easier to write the optimizer when the
language supports easy/common ways for the programmer to express their
intentions.
3) I spent a reasonable amount of time optimizing the code generation
for some common cases. For example, code generation for a while loop
takes into account two special cases: a constant condition, or an empty
body. Initially, the code was very tight, but as the complexity of the
compiler has increased, my attention to optimization hasn't quite kept
up with the introduction of new features.
4) And my favorite...jmpl was intended by Lego to allow jumping forwards
or backwards so they encoded a "direction" bit into the arguments. In
contrast, chkl doesn't have a direction bit...just a 16 bit offset. I
believe TLG always treated this instruction as a forward-only sort of
jump. However, I didn't know any better and I assumed it was a 16 bit
signed offset and a two's-complement could be used for a backwards jump.
Turns out it works by accident...not by design. But it works.
Dave
--
reply to: dbaum at enteract dot com
|
|
Message is in Reply To:
 | | RE: NQC versus Lego RCX Code Speed
|
| 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 in NQC and programs coded in RCX Code. Is the (...) (24 years ago, 5-Oct-00, to lugnet.robotics)
|
6 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
