> Well, interrupts aren't exceptions. sorry, I'm programming an interrupt controller right now. wires got crossed.
> you have a call stack, and you want code to execute "quickly" in order to > meet a time constraint (hard or not), > Now, checking every next() call to see if it > returns EOF (or sets some EOF flag variable) is inefficient, You're not thinking like an embedded controller engineer. You're trying to make your "best case" run faster. An embedded guy has to get their code to run at some frame rate. Say 30 hz. His code has to run one frame of data every 33 milliseconds. and then the processor goes to sleep until the timer wakes it up for the next frame. What does it mean if you're code is more "efficient" but still runs at 30 hz? You're talking about the problem like someone used to programming for desktops. Make things run as fast as possible and slow things down as needed to get done. For example, you'd never read a file of unknown length in avionics or any kind of embedded controller application like an engine controller. At least not on a per-frame basis. You might dedicate so many clock cycles per frame to read some fixed number of bytes per frame, but you wouldn't have code that says "read until EOF" and then code it with an exception so that you respond to EOF more "efficiently". You're trying to make your best case better, and you worst case is how ever long it takes till you read EOF. Embedded controller guys have to make their worst case meet some minimum. And no open-ended processes are allowed per frame. _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
