Subject:
|
Alternatives for NQC Event Support
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Mon, 1 May 2000 21:44:45 GMT
|
Viewed:
|
1955 times
|
| |
|
|
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 4 Replies:
 | | Re: Alternatives for NQC Event Support
|
| (...) I like the second option, find it more elegant and similar to analogous constructs in other languages. But I do see its possible side effects and misuses, so my final choice is option 3. Mario Web page: (URL) member page: (URL) member of (...) (25 years ago, 2-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
|
|
|
|
