Subject:
|
Re: Memory - Where did it go?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Thu, 20 Jul 2006 14:05:51 GMT
|
Original-From:
|
Greg McKaskle <GAM@antispamNI.COM>
|
Viewed:
|
4416 times
|
| |
|
|
I'm coming in a little late on this topic, but I wanted to restate things
just a little.
NXT programs are built using a library of blocks. These blocks are not
"built-in", to the compiler, but are simply shipped and placed in the
palette. Each of the blocks is actually replacable and is itself written and
shipped as source code.
As mentioned, the block interfaces are very general, general to a fault.
Some blocks have all of their code inlined. A multiply block will produce
some code to reference the data values or constants and multiply them. Other
blocks will have some code inlined, but much of the code in a reusable
library. These library blocks are only placed in the code once and called
from each usage. For example, a motor block will have some code inlined so
that it can work in parallel with other motor and move blocks, but will call
reusable code to carry out some of the atomic actions.
This means that block size is pretty well characterized with mx+b for m
blocks. Often it is b that is the somewhat large but reusable code that is
added to your program when you use the first block. The m tends to be pretty
small.
Comparing the NXT blocks to hand-tuned C code is a fine thing to do, but it
isn't exactly apples-to-apples. The NXT compiler will optimize the inlined
code to be based upon the configuration, but it is not able to propagate
this information into the reusable library blocks. Most C compilers will not
attempt this either. And so, because of the large number of drawer items on
the blocks, the compiler is given a difficult task. Writing a similarly
complex C function capable of parallel operations and such will also yield a
lot of code. By simplifying the function, removing parameters, not dealing
with bad input values, and removing parallel execution with related blocks,
it is possible to shrink the blocks using either language.
The good news is that it is quite easy to write blocks. An SDK will be
released later in the year allowing for small and customized blocks to run
faster and smaller, more like what is now available in the C variants. And
in many cases, it is only necessary to remove a single parameter to shrink
the block size considerably.
For now, the advice already given about removing data files like sounds and
data are invaluable. In reality, it is these files accumulating on the brick
that usually use most of the room. Also, keep in mind that small programs
and large programs are similar in size. The file size isn't likely to
prevent you writing a very very complex program. It is however likely to
keep you from storing all the small programs on your brick. You can use the
NXT window>>Memory to keep all of the programs on a PC and move them back
and forth to the NXT.
One last detail, kind of just for trivia. The NXT has two types of memory,
flash, and RAM. The NXT program code is actually kept in flash and executed
from flash. The stuff built into memory is for storing dynamic data and for
scheduling parallel code.
Greg McKaskle
--
View this message in context: http://www.nabble.com/Memory---Where-did-it-go--tf1903631.html#a5415830
Sent from the LEGO Robotics forum at Nabble.com.
|
|
Message is in Reply To:
 | | Re: Memory - Where did it go?
|
| (...) With a newly loaded firmware: C:\WINAPPS\projects\...c>nexttool /COM=x -freemem 70324 C:\WINAPPS\projects\...c>nexttool /COM=x -listfiles NVConfig.sys=1 RPGReader.sys=14346 Demo.rxe=9436 Try-Touch.rtm=3788 Try-Light.rtm=4456 Try-Sound.rtm=6864 (...) (18 years ago, 10-Jul-06, to lugnet.robotics)
|
9 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
