Subject:
|
Re: NQC 2.2 a1 available for public test
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Mon, 8 May 2000 02:12:23 GMT
|
Viewed:
|
1954 times
|
| |
|
|
In article <3915EB84.A1442E86@gmx.de>, rkra@gmx.de wrote:
> Dave wrote that locals can't be displayed. I 've tested this and it
> seems
> so but I don't know why
Lego's concept of 'local' variables are variables that are context
swapped per task, as opposed to the normal variables that are not
context swapped (all tasks share the same vars). Thus, 'local' RCX
variables are local to the task. This is a different concept than a
'local' variable in C, which means that it has a value local to scope in
which it is declared.
NQC has supported locally scoped variables for quite a while, and
implemented them by using up the variables in the global pool. When
task-local variables are supported by the firmware, RCX uses those up
first, then turns to the global var pool for use as locally scoped
variables. As a result, most (but not all) locally scoped variables in
NQC become local RCX variables.
Anyway, the reason locals cannot be displayed is that the value of the
local depends on what task is executing, and the display isn't 'owned'
by any one task. I suppose TLG could've made it so that displaying a
local variable remembered both the var number and the task it was
executing in, but I suspect this would've involved some special case
code beyond the normal 'effective address' resolution.
Dave Baum
--
reply to: dbaum at enteract dot com
|
|
Message is in Reply To:
 | | Re: NQC 2.2 a1 available for public test
|
| Hi, that 's right, global variables could be displayed but not the local ones. Therefore I 've another test file which uses a global variable i and a local variable k. If you run the program on your rcx you would see first the global i that is 100. (...) (25 years ago, 7-May-00, to lugnet.robotics.rcx.nqc)
|
22 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
