Subject:
|
Re: NBC arrays
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Fri, 4 May 2007 17:41:39 GMT
|
Viewed:
|
18958 times
|
| |
|
|
In lugnet.robotics.nxt, Pavel Petrovic wrote:
> Is there some more detailed (and lower-level) description of how the arrays work
> in NBC, please? Something that would complement the description in the manual?
Perhaps the executable file and bytecode reference PDF explains arrays in a way
that would complement the description in the NBC manual. The firmware source
code is also a good source of information about how arrays work.
> Here is a first question: if the array variable already contained some value
> (existing array), what does the arrinit do with this old value and with the
> previously allocated memory?
The firmware source code reveals the answers to your questions. It looks like
it shrinks the dope vector count if you are allocating a smaller size than the
array previously had and leaves the extra bytes unused where they were. If you
are allocating a larger size it tries to grow in place (to reuse some available
unused memory at the right location) if it can and if it can't then it allocates
memory at the end of the pool of already used memory and copies the old array
data (if any) to the new location.
> is that right that the target array (new_array) in both of these calls does not
> have to exist/be allocated before, or does it already have to have the proper
> size? if it has larger/smaller size, is it automatically shrunk/extended?
The target array does not have to have more than 0 elements but it must be an
array defined in the dataspace with the appropriate dimensions given the context
of the array operation.
> Impression is that "newly created array"s concept for top-level arrays means
> that the existing top-level arrays are resized as needed to fit the results of
> the array operations, but new arrays are never allocated at top-level. Is that
> right?
Any output argument for an array operation must be a top-level array defined
within the dataspace. If there isn't a known dataspace element ID associated
with the name of the array (and the dataspace is fully defined at compile time)
then you can't use that in an array operation. Nearly every operation in the VM
operates on one or more dataspace element ID and the array operations are no
exception to that general rule.
> Or is it rather so that the memory is not reused, and new arrays in new memory
> locations are created and the old values are just lingering around, slowly
> filling up the memory? Or is there perhaps some kind of immediate garbage
> collection of the unused blocks implemented?
Generally old values linger and slowly fill the 32kbyte of available memory.
However, if the attempt to execute an operation in the VM results in ERR_MEM
then the cCmdDSCompact routine is called and the operation is attempted again.
So there is a form of garbage collection which occurs when memory is at the
point of exhaustion.
> Are the array operations completely general (if the element types are the same),
> or should one avoid certain situations/combinations?
Aside from a bug in the OP_REPLACE operation which breaks support for
multi-dimensional arrays (nested arrays) and aside from the restriction that you
not use the input array as the output array in OP_REPLACE I would say that the
array operations are general. The distinction between strings (arrays of byte
with a null terminator) and arrays of byte can cause some grief. And the
inability to directly manipulate array elements is annoying. But overall you
can do what you need albiet with a little juggling.
John Hansen
|
|
Message has 1 Reply:
 | | Re: NBC arrays
|
| (...) I misspoke here. It is not OP_REPLACE which requires that the output array be different from the input array. Using the same arrays as input and output with OP_REPLACE, in fact, is quite normal and usual. I was actually thinking of OP_ARRBUILD (...) (18 years ago, 5-May-07, to lugnet.robotics.nxt)
|
Message is in Reply To:
| | NBC arrays
|
| Is there some more detailed (and lower-level) description of how the arrays work in NBC, please? Something that would complement the description in the manual? This is how I see the arrays in NBC/standard firmware: * a compiled program works with (...) (18 years ago, 29-Apr-07, to lugnet.robotics.nxt)
|
4 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
|
|
|
|
|
|
