Subject:
|
Re: Memory - Where did it go?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 8 Jul 2006 14:27:10 GMT
|
Viewed:
|
4728 times
|
| |
|
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> By "Block" you mean a simple operation like and add or a
> multiply or turning on a motor or reading a sensor?
By "block" I mean a NXT-G code block as dropped from a pallet. Yep, you would
think that these things would compile down to a single bytecode (or a few
bytecode sequences), but they don't. There is an awful lot going on under the
hood, and it's not apparent yet (at least to me) how much of this can be refined
away, and how much is there to stay (until 3rd party firmwares come on-line
anyway).
> it's hard to imagine how a block could possibly take up
> more than a handful of bytes...
I'm really hoping an MUP/MDP more knowledgable than me steps up on this
one... John?... it may be hard to imagine, but it's true. And there's no mystery
"22 kb" beasty attatched to every program: small NXT-G programs compile to small
(as small as 0.7 kb, perhaps smaller) executable files on the NXT.
> The exception would be some kind of a block that draws an
> image or something...
Nope. the images to be drawen are stored independant of the executable code
in their own files. Which actually gives a window into some of what's going on
under the hood: a Draw [image] block doesn't just have to turn on some pixels,
but turn a file name into a reference for a piece of memory, as well as handle
the potential problem of what to do if the file it wants isn't there (and it has
to do this all without crashing on a 12-year-old kid), determine if the program
needs the screen cleared (because this could be controled by a wire into the
Draw block, you can't compile it to be just one way or the other), do it if
needed, and if not start copying the image file data into the screen memory,
etc. There's a *lot* of programming flexibility in those blocks and the datahubs
associated with them... but it means, apparently, a lot of behind-the-scenes
shuffling that takes a lot of bytecodes and a fair amount of processor time.
> If the file does indeed double in size then there is something
> quite amazingly inefficient going on...
A single Sound block set to play a sound file: 0.7 kb
Four Sound blocks configured as above: 1.3 kb
Eight identical Sound blocks in a sequence: 2.1 kb
Conclusion? There's some significant overhead in the NXT-G language and compiler
as it stands right now.
--
Brian Davis
|
|
Message is in Reply To:
 | | Re: Memory - Where did it go?
|
| (...) By "Block" you mean a simple operation like and add or a multiply or turning on a motor or reading a sensor? These 'blocks' ought to be turned into little interpreted byte-code segments - it's hard to imagine how a block could possibly take up (...) (18 years ago, 8-Jul-06, to lugnet.robotics)
|
9 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
