 | | Re: maximum number of variables in RCX2 ?
|
|
(...) Lego's usage of the terms'local' and 'global' is a little different than what most people expect. In the RCX, global storage is available across all tasks while local storage is avaialble per task. This is different from the more traditional (...) (23 years ago, 21-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: maximum number of variables in RCX2 ?
|
|
(...) Remember that the RCX has no stack or heap. This means that, effectively, there is no memory pool from which to allocate things. Here, 'local' means belonging to the current task not the current function, and the number of tasks is fixed (at (...) (23 years ago, 20-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: maximum number of variables in RCX2 ?
|
|
Hi John, (...) Yes ! Using more tasks you will get more local space (for each task 16). So maximum number of variables is 32+(16*10) = 192 (...) That's how NQC is handling memory for local variables in functions, subroutines, tasks. Local has a (...) (23 years ago, 20-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: maximum number of variables in RCX2 ?
|
|
(...) this (...) only (...) variables (...) the (...) From my understanding of NQC, the compiler automatically selects the most suitable location to store variables. Global variables are obviously always allocated in one of the 32 global storage (...) (23 years ago, 20-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | maximum number of variables in RCX2 ?
|
|
When using the RCX2 target, the NQC manual (Section 2.2.4) states that 32 global variables, and 16 local variables (per task) are allowed. Does this mean that the whole program can only have 48 variables total when using only one task, ie. "main" , (...) (23 years ago, 20-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: BricxCC release 3.3.3.8
|
|
John Hansen wrote: > In lugnet.robotics.rcx.nqc, Stef Mientki writes: > >>I know the cause, you know the solution ;-) >> >>The size of BricxCC when opening the first file, depends on the SIZE of >>the file to be opened. >> 8 bytes, window stays as (...) (23 years ago, 19-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: BricxCC release 3.3.3.8
|
|
(...) Yes that's exactly what I'm trying to say !! To day I had an even stranger experiences: 1. the size of BricxCC became smaller after opening the first file, still depending on the size (or is it the content) of the file 2. in one of the tests I (...) (23 years ago, 19-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: BricxCC release 3.3.3.8
|
|
(...) Well, I'm stumped. I cannot get the behavior you describe to occur no matter how hard I try. I'm not sure what you mean by "I know the cause, you know the solution". Have I understood your description of the problem correctly? Are you saying (...) (23 years ago, 19-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: BricxCC release 3.3.3.8
|
|
hi John, thanks for your attention. I know the cause, you know the solution ;-) The size of BricxCC when opening the first file, depends on the SIZE of the file to be opened. 8 bytes, window stays as it is 256 bytes, blows the window up to about (...) (23 years ago, 18-Feb-02, to lugnet.robotics.rcx.nqc)
|
| |
| | Re: BricxCC release 3.3.3.8
|
|
(...) I can't duplicate this behavior. I think it might have something to do with those pesky DSK files (maybe?). Can you check to see if the files listed in your recent file list have associated desktop files (*.DSK)? Thanks, John Hansen (23 years ago, 18-Feb-02, to lugnet.robotics.rcx.nqc)
|
