Subject:
|
RE: NXT Optimized Array Handling
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Sat, 30 Dec 2006 14:57:13 GMT
|
Reply-To:
|
<dickswan@sbcglobal.#NoSpam#net>
|
Viewed:
|
11625 times
|
| |
|
|
I would suggest that the easiest way to understand how standard firmware
handles arrays is to go to the NI web site and do a search on something
like "efficient LabVIEW memory management" which will result in a nice
description of how LabVIEW handles arrays. And then assume that the
NXT-G firmware does something quite similar.
As I recall from memory:
* LabVIEW maintains internal "heap" for memory management.
* Garbage collection on the heap will be performed when a memory
allocation fails. Execution of user program will be stalled during
garbage collection. On the NXT, the heap is about 32K in size.
* A 2-dimensional array would contain a 1-dimsional array of
"rows". Each element in the row array is in turn a 1-dimensional array
containing the column entries.
* Similarly, an N-dimensional array is a 1-dimesional array
where each element is in turn an N-1 dimensional array.
* Size of array will be dynamically increased if you try to
write an element outside of the existing array bounds.
* Pretty much every opcode that does array manipulation copies
the input array (i.e. will allocate new array from heap and copy) and
then operates on the copied array. One reason for this is that an array
item could be "wired" into multiple opcodes; if you adjust an array
in-place, then you run the risk of changing the values that were wired
into another opcode. So there's a lot of memory allocation involved in
manipulating arrays!
* LabVIEW compiler has optimization which avoids some
unnecessary array "copy" operations. I don't know if NXT-G has similar
optimization.
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com] On Behalf
Of David Wallace
Sent: Thursday, December 28, 2006 4:10 PM
To: lugnet.robotics.nxt@lugnet.com
Subject: NXT Optimized Array Handling
There doesn't seem to be any information on the most memory-efficient or
speed-efficient way to handle arrays in the NXT Executable File
Specification. For example, if you want to create a multi-dimensional
array, you use the opcode OP_ARRBUILD (arrbuild in NBC). However, you
must create the single-dimension arrays first and then OP_ARRBUILD
appears to copy them to a new, contiguous memory location. This
effectively doubles the amount of memory used!
Also, operations can be performed that change the size of an array (like
OP_ARRSUBSET). You could increase or decrease the size of the array with
this command. How does the NXT firmware handle this? Is new space
created and old space freed via some sort of heap management?
Knowing how the firmware handles this would aid in writing efficient
programs. I suppose I could wade through the firmware code, but I was
hoping someone would know the answers.
David Wallace
--
MIME ATTACHMENTS DISCARDED:
1. Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-Length: 7858
|
|
Message has 1 Reply:
 | | Re: NXT Optimized Array Handling
|
| Thanks Dick, I also found info on how arrays are handled in the Executable File Spec. I didn't see it before. My cut on this is that I will use single-dimension arrays in non-time-critical areas and avoid mult-dimensional arrays alltogether. It (...) (18 years ago, 6-Jan-07, to lugnet.robotics.nxt)
|
Message is in Reply To:
| | NXT Optimized Array Handling
|
| There doesn't seem to be any information on the most memory-efficient or speed-effecient way to handle arrays in the NXT Executable File Specification. For example, if you want to create a multi-dimensional array, you use the opcode OP_ARRBUILD (...) (18 years ago, 28-Dec-06, to lugnet.robotics.nxt)
|
3 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
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
