Hardware Reference
In-Depth Information
Figure 4.3
This 32-bit assembly language program (using MASM-32)
produces exactly the same message as that produced by the Visual Basic code
shown in Figure 4.1
passing parameters between the main program and the code generated by the
assembly language module.
●
What, if any, provision is there for handling interrupts?
Some mechanism for allowing the user to incorporate his/her own interrupt
handling routines will be essential in many real-time control applications.
•
What provision is there for event/error trapping?
The ability to include specific event/error trapping routines can be important
in making the program robust and suitable for non-technical users. Error
handling routines should permit meaningful error reporting as well as the
ability to retain control of the program with an orderly shutdown when
operation cannot continue.
•
Finally, will the language allow multi-tasking for use in event-driven
processes?
In control applications, the ability to support multi-tasking is a highly desir-
able feature. In addition to the main process, the programmer will then be
able to define one, or more, background tasks (sub-processes) to run con-
currently with the main program. These tasks will be switched to repeatedly
during program execution and thus effectively run in parallel with the main
program.
Unfortunately, true multi-tasking can be a problem within an x86 DOS
environment as the Real Mode provided by the x86 processor in the ori-
ginal PC, PC-XT, and PC-AT employed straightforward addressing with
no inter-process protection. The limitation in available memory (640 KB
under PC-DOS or MS-DOS) further mitigated against applications that were
truly multi-tasking. Happily, with modern 32-bit operating systems and
large memory environments this constraint no longer applies (Figure 4.3
and 4.4)!
Figure 4.4
The warning
message produced by the
MASM-32 program shown
in Figure 4.3
