Subject:
|
Re: NQC 2.x event processing
|
Newsgroups:
|
lugnet.robotics.rcx.nqc
|
Date:
|
Sat, 10 Jun 2000 07:57:28 GMT
|
Viewed:
|
1793 times
|
| |
|
|
In article <393BDEDF.3CDC@gmccomb.com>, Gordon McComb
<gmccomb@gmccomb.com> wrote:
> 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?
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:
// put handler code here
This is pretty similar to how one would use an interrupt routine. The
problem is that all of this code is smashed together so what happens
after end_events? Does execution "fall through" to event_handler? In
many cases this wouldn't be ok, so people would want to be able to jump
around the handler...
being_events
//
end_events
goto done;
event_handler
//
done:
//
Another way around this is to use syntax to determine the control flow
(just like an 'if' statement).
if (condition)
foo
else
bar
actually turns into
if !condition goto label
foo
goto done
label:
bar
done:
Applying the syntax solution to defining control flow is what got me
into this style syntax:
monitor()
{
}
catch
{
}
>
> 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.
I agree. If 'goto' was already a part of NQC, then I'd proably add an
event_goto style statement and let people build whatever control
structures they desired. Providing event_goto without regular goto
isn't really enough.
A good deal of the present code generation depends on the fact that
control flow is preditable from the parse tree. In other words, when
you're in a 'while' loop, although break and continue can alter your
control within the loop, they never jump to some place before or after
the loop (consider 'break' to be the end of the loop). There are some
wrinkles with event handling, but you can still make code generation
decisions based on the loop and event 'contexts' in the parse tree. I
beieve general 'goto' support would pretty much require a DAG-like
representation of code in order to make certain code generation
decisions.
Something like this is definitely beyond the NQC 2.2 changes. I've
already changed more of the compiler internals for NQC 2.2 than for
almost any previous release. Perhaps if I introduce an optimization
stage or something else that requires DAGs in NQC 3.0, then I'll add
goto and also primitive event functions.
That being said, I'm still open to suggestions on other syntaxes. One
thing I was toying with was having the programmer define a function as
the event handler. That would get around the the goto problem mentioned
above...
task main()
{
BeginEvents(EVENT_MASK, my_handler);
// do stuff
EndEvents();
// do more stuff
}
void my_handler()
{
// here's where you handle the events
}
However, its not clear what the program should do once an event occurs
and the handler completes. There isn't any way to resume from where the
event interrupted things (no stack for RCX bytecodes). There would need
to be a fixed place where my_handler transfered control after execution.
Depending on where you transfer control, this starts to feel a lot like
the present monitor/catch model.
Thoughts?
Dave
--
reply to: dbaum at enteract dot com
|
|
Message has 1 Reply:
Message is in Reply To:
 | | Re: NQC 2.x event processing
|
| (...) #3, which was the approach you took. (...) 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 (...) (24 years ago, 5-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
|
|
|
|
