Subject:
|
Re: Memory - Where did it go?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Mon, 10 Jul 2006 04:24:20 GMT
|
Viewed:
|
5255 times
|
| |
|
|
In lugnet.robotics, steve <sjbaker1@airmail.net> wrote:
> These 'blocks' ought to be turned into little interpreted byte-code
> segments - it's hard to imagine how a block could possibly take up more
> than a handful of bytes - so a 180 block program ought to be under 1000
> bytes.
Everything in NXT-G is a block that you drag and drop onto your program. All
blocks in NXT-G are LabView Virtual Instruments (VIs). Some blocks expand into
a loop construct. Others expand into a switch construct. They often represent
non-trivial operations. Many of the blocks in NXT-G are highly configurable and
generic to a fault. That means the LabView code internal to the block has to
handle many different cases. The NXT-G compiler does NOT do a good job of
optimizing out all the generic case handling so that the only thing left is the
specific use you make of the block. Blocks in NXT-G often have a lot of input
error checking code and parameter passing code (i.e., the transfer of data into
the block and the transfer of data out of the block) that gets compiled into
your NXT-G executable.
One example of a block that you can use in an NXT-G program is a wait for sensor
value block. This single block will more often than not get compiled into at
least 3 "clumps" or separate threads of execution. The three threads implement
a looping construct which manages the process of waiting and reading a sensor
and terminating the wait loop once the value matches the specified criteria.
> The exception would be some kind of a block that draws an image or
> something - which would have to contain the data for the image itself -
> which might be quite a bit bigger.
Part of the problem with executables for the standard LEGO NXT firmware is that
the file format is extremely inefficient. A huge chunk of the file size is the
definition of the dataspace - the variables, arrays, structures, static data,
and dynamic data that is used by the executable byte codes. The more blocks you
use the more unneeded and wasteful variables you wind up with in an NXT-G
program. With a draw block which can do 6 different things you get variables
for drawing an image (including a byte array defining the image name and a
structure declaration for passing data to the draw image system call) and
variables for drawing text (including a byte array defining the text string and
a structure declaration for passing data to the draw text system call) and
variables for all the other drawing functions even if all you want to use the
draw block for is to clear the screen (the reset function). And if you use more
than one draw block you get another set of those unneeded variables. The code
itself isn't duplicated (the compiler turns it into a callable subroutine) but
even in that case there is a lot of overhead in calling this extremely generic
block that wouldn't be needed if you wrote equivalent NBC code to just clear the
screen.
> If ~40 blocks is ~23kb then I *suspect* that there is a 22kb "thing"
> that goes along with every program
Nope. An NXT-G program containing just the keepalive block compiles to a 92
byte executable. The actual codespace in those 92 bytes is only 20 bytes long.
An NXT-G program containing just an add block compiles to a 98 byte executable
of which only 18 bytes is actual code.
Here's the decompilation:
dseg segment
;------- definitions -------
;------- declarations -------
sl0000 sdword
sl0001 sdword 3
sl0002 sdword 4
sl0003 sdword
uw0004 word
dseg ends
; -------------- program code --------------
thread t000
add sl0003, sl0002, sl0001
mov sl0000, sl0003
exit -1, -1
endt
As you can see, even in this trivially simple block there is overhead. It will
be multiplied as you use the add block more and more. In an NBC program there
would be no reason for the mov operation. The NXT-G language requires the extra
variable (sl0003) because each block has its inputs and outputs and the compiler
needs to copy data into the block and out of the block whether you want it to or
not. I have no idea why the NXT-G program introduces the unsigned word variable
which isn't used at all in the executable code. But you see that a lot (!) in
NXT-G programs.
John Hansen
http://bricxcc.sourceforge.net/
|
|
Message has 1 Reply:
 | | Re: Memory - Where did it go?
|
| Wow, what a wealth of information. Thanks for the great detail. I am already using the Wav2Rso program but did not know enough about sound files to understand the convertion options. Which option gives you the smallest converted file? In your other (...) (18 years ago, 10-Jul-06, to lugnet.robotics)
|
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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
