Subject:
|
Re: Alternatives for NQC Event Support
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Tue, 2 May 2000 10:15:05 GMT
|
Viewed:
|
1909 times
|
| |
|
|
3 for me.
When can we expect to see a version of nqc that will download the new firm
into the rcx?
Dave Baum <dbaum@spambgoneenteract.com> wrote in message
news:dbaum-062405.16444501052000@lugnet.com...
> RCX 2.0 adds firmware support for events and resource acquisitiion. The
> primitives are rather straight-forward. For events, one command beings
> event monitoring on a set of events, another stops monitoring. If a
> monitored event occurs, control is transfered to the address specified
> in the monitoring instruction. Resources are manages in a similar
> scheme, but with resource flags rather than events being specified.
>
> A rather primitive way to incorporate this into NQC is with some API
> calls that wrap the mone and monex primitives. For my examples I'll
> assume the goal is to monitor event source 0 (mask = 1) while playing a
> beep every second for 10 seconds. A different sound will be played if
> the event occurs.
>
> BeginEvents(1, handler); // monitor event 0
>
> repeat(10)
> {
> PlayTone(440, 20);
> Wait(100);
> }
> EndEvents();
>
> goto done;
>
> handler:
> PlaySound(2);
>
> done:
>
> This approach is the most flexible since it gives atomic control over
> the actual mone and monex statements. On the minus side the control
> structure is far from obvious and it forces liberal use of goto (which
> presently doesn't even exist).
>
> ----
>
> Another approach is to use a try/catch sort of syntax which makes the
> control structure more apparent...
>
> try
> {
> repeat(10)
> {
> PlayTone(440, 20);
> Wait(100);
> }
> }
> catch(1)
> {
> PlaySound(2);
> }
>
> My problem with this is that the events being monitored aren't specified
> until *after* the try block (in the catch phrase). This is fine for the
> likes of C++ exception handling where the type of the catch is a
> compile-time constant. However, in this case the events being monitored
> can come from any expression including some with side-effects...
>
> try
> {
> // body
> }
> catch(++x)
> {
> // handler
> }
>
> Now its far from obvious that x is incremented prior to starting
> execution of the body, but that's exactly how the code would need to be
> generated since ++x would need to be evaluated in order to begin event
> monitoring. Another problem is that this doesn't make as much intuitive
> sense for resource acquisition.
>
> ---
>
> A third option is to still use the try/catch sort of syntax, but replace
> 'try' with the actual event monitor..
>
> monitor(1)
> {
> repeat(10)
> {
> PlayTone(440, 20);
> Wait(100);
> }
> }
> catch
> {
> PlaySound(2);
> }
>
> This solves the ++x problem and also gives an obvious extension for
> resources...
>
> acquire(OUT_A + OUT_B)
> {
> }
> catch
> {
> }
>
> As an added benefit, the 'catch' clause could be optional, allowing for
> the case where an event simply caused early termination of the body.
> The only real drawback is I'd be adding two new keywords and getting
> pretty far astray from mechanisms in C and C++.
>
> ---
>
> To sum up, there are three options on the table...
>
> 1) API calls (e.g. BeginEvent() EndEvent()). Most flexible, but
> encourage goto and obscure structure.
>
> 2) try/catch. Nice structure, but out-of-order execution.
>
> 3) monitor/catch. Nice structure, but adds new keywords.
>
> My personal preference is 3. What do other people think? Any other
> ideas?
>
> Dave Baum
>
> --
> reply to: dbaum at enteract dot com
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Alternatives for NQC Event Support
|
| RCX 2.0 adds firmware support for events and resource acquisitiion. The primitives are rather straight-forward. For events, one command beings event monitoring on a set of events, another stops monitoring. If a monitored event occurs, control is (...) (25 years ago, 1-May-00, to lugnet.robotics.rcx.nqc)
|
8 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
|
|
|
|
