'Fake' events
-
RayBritton
- Veteran
- Posts: 109
- Joined: Thu Feb 10, 2005 12:38 pm
'Fake' events
Hi, people keep saying that QB's events are 'fake', i was wondering why are they fake.
True events trigger a hardware signal (interrupt) that takes the control of the program to a sobroutine that services them, then the program resumes where it got stopped. The program does not have to worry about if an event occurs, and it's not slowed down if there are not events, as the hardware polls for them.
QB's events are not hardware triggered, instead the compiler adds hidden code to poll for events after every line of your program. This bloats the program and makes it slower because of the constant polling of the events.
QB's events are not hardware triggered, instead the compiler adds hidden code to poll for events after every line of your program. This bloats the program and makes it slower because of the constant polling of the events.
Very good explanation, Antoni.Antoni wrote:True events trigger a hardware signal (interrupt) that takes the control of the program to a sobroutine that services them, then the program resumes where it got stopped. The program does not have to worry about if an event occurs, and it's not slowed down if there are not events, as the hardware polls for them.
QB's events are not hardware triggered, instead the compiler adds hidden code to poll for events after every line of your program. This bloats the program and makes it slower because of the constant polling of the events.
Let me expand a little.
When a hardware interrrupt occurs, the hardware obtains the address of the corresponding interrupt handler from an interrupt vector table, and transfers control to the interrupt handler, which is like a subroutine.
The interrupt handler then saves all the registers, inhibits all other interrupts, and goes about doing what is required for this interrupt. When it's finished, it restores the saved registers, enables interrupts and returns to the original program which was interrupted. The time involved to service an interrupt is negligible to the interrupted program. A good example of this kind of interrrupt is the clock. For each click of the clock, which could be every "x" milliseconds, the interrupt handler for the clock is invoked to update all time-related information.
As Antoni said, QB has fake events, like ON ERROR, ON KEY, etc. for which the compiler intersperses tests for these conditions after each line of your program. When the event occurs, it is not an interrupt. It is detected by the code after each instruction. Imagine, testing after each instruction: "Did this instruction cause a QB error?" The result is a much larger and slower program.
*****
The "real" versus "fake" distinction in most programming areas usually breaks down along the software/hardware lines, and as operating systems have become more and more complicated, the entire issue becomes murky.
Even in the case of a simple application running under DOS, however, the notion of an event is sort of fuzzy. Consider a "keystroke event". You press the "enter" key. The keyboard signals the keyboard controller, which signals the PIC, which signals the CPU. The CPU saves part of its context, switches to an interrupt handling routines which polls the keyboard controller for a scan code, translates the scan code into an ascii character and a BIOS scan code and shoves them into a buffer in memory, then jumps back to where it left off before the interrupt. For the application to handle the event, its code must call BIOS (or indirectly through a DOS call), which retrieves the ascii code and/or the scan code), then branches to an appropriate section of the program to handle the "event". That is one sort of event. Events such as errors differ in details, depending on which type of error they happen to be (dividing by zero triggers an interrupt whereas passing a bad file name to OPEN does not.)
Now, the QB event handling features automate much of the proccess for the programmer, but not very efficiently. Years ago, fast event handling could be achieved by replacing the hardware interrupt handler with code taylored to the needs of the application, but QB lacks the functionality to do so without code generated by some other compiler or assembly language code.
The picture under Windows is even fuzzier. Here, device driver code handles the hardware interrupt, and the information generated by that routine "bubbles up" through several layers of abstraction and translation and usually winds up in a windowed application message queu until the appropriate program polls its message queu then "dispatches" the message to an event handler.
The more you dive into the details, the more the notion of an "event" evaporates, because the truth is that "events" are merely a matter of appearence. Event driven programs appear to respond to user input and other asynchronous behaviors of the system in a cause/effect manner. The only aspect that matters is how the program appears while executing.
So, QB events are not "fake". They may be slow, but they are just as much "events" as in any other event handling scheme. I personally never use them, but that besides the point.
Consider these questions. Does a program that uses a hardware graphic accelerator to produce an image create a more "truly 3-D" image than a program that does so solely with software techniques? Is the result of a floating point calculation less "real" if it is produced by code that emulates the FPU?
Even in the case of a simple application running under DOS, however, the notion of an event is sort of fuzzy. Consider a "keystroke event". You press the "enter" key. The keyboard signals the keyboard controller, which signals the PIC, which signals the CPU. The CPU saves part of its context, switches to an interrupt handling routines which polls the keyboard controller for a scan code, translates the scan code into an ascii character and a BIOS scan code and shoves them into a buffer in memory, then jumps back to where it left off before the interrupt. For the application to handle the event, its code must call BIOS (or indirectly through a DOS call), which retrieves the ascii code and/or the scan code), then branches to an appropriate section of the program to handle the "event". That is one sort of event. Events such as errors differ in details, depending on which type of error they happen to be (dividing by zero triggers an interrupt whereas passing a bad file name to OPEN does not.)
Now, the QB event handling features automate much of the proccess for the programmer, but not very efficiently. Years ago, fast event handling could be achieved by replacing the hardware interrupt handler with code taylored to the needs of the application, but QB lacks the functionality to do so without code generated by some other compiler or assembly language code.
The picture under Windows is even fuzzier. Here, device driver code handles the hardware interrupt, and the information generated by that routine "bubbles up" through several layers of abstraction and translation and usually winds up in a windowed application message queu until the appropriate program polls its message queu then "dispatches" the message to an event handler.
The more you dive into the details, the more the notion of an "event" evaporates, because the truth is that "events" are merely a matter of appearence. Event driven programs appear to respond to user input and other asynchronous behaviors of the system in a cause/effect manner. The only aspect that matters is how the program appears while executing.
So, QB events are not "fake". They may be slow, but they are just as much "events" as in any other event handling scheme. I personally never use them, but that besides the point.
Consider these questions. Does a program that uses a hardware graphic accelerator to produce an image create a more "truly 3-D" image than a program that does so solely with software techniques? Is the result of a floating point calculation less "real" if it is produced by code that emulates the FPU?