Subject:
|
Re: NQC 2.x event processing
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Mon, 5 Jun 2000 17:09:51 GMT
|
Viewed:
|
2034 times
|
| |
|
|
Dave Baum wrote:
> I don't have any changes in mind for the monitor/catch construct,
> although I'll listen to suggestions if people have any. There was a
> brief discussion about this a while back:
> http://www.lugnet.com/robotics/rcx/nqc/?n=570
Yes, I've already gone through those messages. Seems most people liked
#3, which was the approach you took.
> I haven't played with the pBrick scripting myself, so I'm not sure
> exactly what sort of syntax or feature you'd like to see. Bear in mind
> that NQC is similar to C in that is doesn't put too much between the
> programmer and the metal (or in the RCX case the bytecode interpreter).
> I don't have an objection to layering more sophisticated APIs (or
> perhaps even syntaxes) on top of basic low level forms, but I certainly
> don't want to start off with a lot of program structure being defined by
> the compiler.
I think what I liked about the approach in pBrick script was that it was
fairly like coding a microcontroller in assembler: set up an interrupt
vector and then include a label and code for the interrupt in the
program. When the interrupt occurs, jump to the label.
I don't have any suggestions for handling this syntactically in NQC.
What I was actually thinking, though, is to reduce structure, not add to
it. Not being all that familiar with compiler design I didn't know why
#1 in your original call for approaches required goto's. I take it this
is a problem with the stack?
In pBrick, control either ends, or the interrupted task restarts after
the event is finished (apparently, and from my reading of the LEGO docs,
there is no interrupt stack, so no way to resume from the point in the
code that was interrupted).
I'm trying to get into the head of the designers of pBrick script, and
one thing that occurred to me is that they've designed their language to
readily support behavior-based robotics through Rod Brooks' subsumption
architecture. They appear to have done things to specifically support
this, in fact -- hence the sometimes unusual syntactical and structural
appearance of their language.
Being based on C, NQC should let coders shoot themselves in the foot (I
think that's part of the ANSI C spec, right??), so my preference tends
to be gravitate more to atomic functions, than wrappered API functions.
In pBrick, while you can turn event handling on and off, for the most
part you'd seldom want to. For a subsumption architecture, you'd want to
let the priority system dictate which events take precedence over the
others; manually turning tasks on and off would be fairly rare. In
current NQC code it's a good idea to stop and restart tasks when a given
event occurs, but in pBrick this is generally not required (though the
language supports starting/stopping watchers and tasks).
I can already envision many of the difficulties...what happens in NQC if
priorities for tasks aren't set, for example. Still, this isn't all that
different from current NQC code where multi-tasking without strict
starts/stops at specific events can cause unpredictable behavior.
> If I get assignment working, I may then move to an array style syntax:
>
> UpperLimit[0] = 10;
>
> since "UpperLimit(0) = 10;" looks very strange to most people (although
> some C++ programs have a lot of this sort of thing).
I like UpperLimit[0] = 10; just fine. The parens look too much like
Basic! <g>
-- Gordon
|
|
Message has 2 Replies:
 | | Re: NQC 2.x event processing
|
| (...) Not really a stack problem, just a control flow issue. On suggestion for the event handling was something like this: begin_events(EVENT_MASK, event_handler); // put code that executes during event monitoring here end_events event_handler: // (...) (24 years ago, 10-Jun-00, to lugnet.robotics.rcx.nqc)
| | | Re: NQC 2.x event processing
|
| (...) Getting things like Timer[0] = 100; to work while still allowing if (Timer(0) < 100) { } is a lot harder than I had anticipated, so I'm punting on array-style setting of the various RCX source (such as Timer(), UpperLimit(), etc). There are (...) (24 years ago, 13-Jun-00, to lugnet.robotics.rcx.nqc)
|
Message is in Reply To:
| | Re: NQC 2.x event processing
|
| (...) I don't have any changes in mind for the monitor/catch construct, although I'll listen to suggestions if people have any. There was a brief discussion about this a while back: (URL) that point I was already pushing a procedural approach - (...) (24 years ago, 4-Jun-00, to lugnet.robotics.rcx.nqc)
|
6 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
|
|
|
|
