Software/hardware integration control system4672532Abstract A method and control system for integrating machine independent software written in a high level language with the hardware and software characteristics of a selected processor system to generate an executable load module in the same high level language with selected machine codes merged therewith to be run on the selected processor system. The method and system includes the interactive preparation of a source file containing software, hardware and interrupt configuration specifications of the selected processor system in response to designer inputs. Also included is the processing of the source file to generate a linker command file and a configuration object file. Additionally, the machine independent software is linked with the configuration object file under control of the linker command file to generate the executable load module for the selected processor system. Claims I Claim: Description BACKGROUND OF THE INVENTION
______________________________________
;VECTOR INTSERVE,m
RESUME ICS.INSTR
VECTOR$ SET $
save some registers and preserve traceback
call interrupt servicing routine
restore registers
IRET
RESUME ICS.VROM
create interrupt vector in memory
______________________________________
In the first listing line, ;VECTOR is the ICS directive that declares the interrupt service routine and the type(s) handled by that routine. INTSERVE represents the routine that services the interrupt type number "m". The SET directive causes VECTOR$ to become a pointer. VECTOR$ points to the beginning of the interrupt handling code for this interrupt type. The "save some registers and preserve traceback" code performs two functions: saves selected registers and allows the runtime error checking routines to trace the source of runtime errors. The "call interrupt service routine" code calls the routine that services the interrupt type. The "restore registers" code restores those registers that were saved. (Refer to Table 4 for a list of ICS subroutines that are used to save and restore registers.) The IRET instruction returns control to the interrupted routine. The RESUME ICS.VROM directive causes any lines of code that follow the directive to be placed in the ICS.VROM section. Next, ("create interrupt vector in memory") a vector is created in memory pointing to the beginning of the interrupt handling code. This is done with two assembler directives (an example is shown in the sample ICS listing). The first defines the location where the interrupt vector is to be placed. The second creates the value of the interrupt vector in that location. The sample ICS listing, later in this section, shows the particular code produced for each of the interrupt types in a sample ICS source file. Table 4 lists the subroutines that may be included in the ICS object code. Interrupt types specified with the INTERRUPTS.sub.-- TYPES.sub.-- USED directive, but not mentioned in a VECTOR directive, are referred to as undefined interrupt types. The FAULT.sub.-- NOTIFICATION directive is used to specify the interrupt handling routine for these undefined types. The RESTART.sub.-- LABEL directive generates interrupt vectors for these undefined interrupts. See the sample ICS listing, shown later in this section, for an example. If the INTERRUPT.sub.-- CONFIGURATION is RAM, the interrupt vectors must be created (in CONSTANTS.sub.-- ROM) and then transferred to the interrupt vector area (ICS.VRAM) at runtime. The FAULT.sub.-- NOTIFICATION directive reserves the appropriate areas in ICS.VRAM for the interrupt vectors and sets up the code to transfer the vectors there during program initialization. The table created in ICS.VROM has the form shown in Table 5. The program initialization code is created by the RESTART.sub.-- LABEL directive starting at the location PASCAL.sub.-- BEGIN. The initialization code is executed at runtime and performs the following tasks: sets the DS, SS, and ES registers to the base of the data segment (DATABASEQQ); sets the stack pointer value to STKBASEQQ minus DATABASEQQ; initializes the heap pointers at HEAPBASEQQ; if necessary, calls COPYVECTORS$ to copy the interrupt vectors from ICS.VROM to ICS.VRAM; if necessary, initializes the 8087 by doing an FINIT and initializing the control word; clears the global variable floating point status word; clears the BP register so that the traceback routine knows that this is the main program; and jumps to the main program's entry point MAINQQ. The reset code is a JMPS instruction, placed at location FFFFOH, pointing to the intialization code. After the microprocessor is reset, this JMPS instruction causes the initialization code to be executed. The RESTART.sub.-- LABEL directive also includes the code for any interrupt-related subroutines that are needed (as listed in Table 4.) If the configuration object code generated by ICS does not fit the prototype processor system application the code ICS produces may be modified. When ICS is invoked, if the -l (listing) or -o (object code) option if specified, and the ICS integration source file contains no errors, ICS generates a temporary assembly language source file from the ICS directives. If the o-option is included, ICS invokes the 8086 assembler to create the object file (filename.io) and assembler listing (filename.il). The assembler invocation that ICS uses looks something like this:
______________________________________
/lib/ /tmp/
asm filename.io
filename.il
8086/ics.mc
XXXXXTnnnnTnn
______________________________________
.vertline.
.vertline. .vertline.
.vertline.
object listing ICS macro temporary assembly
file file definitions
language source
(if requested) file
______________________________________
The input to the assembler consists of two files, which are processed as if they were concatenated into a single file. The first file, /lib/8086/ics.mc, consists mostly of assembler macro definitions that are used by the second file. The second file is the temporary assembly language source file that ICS has just created. After the assembler finishes, the temporary file is automatically deleted. If the -o option is omitted, the temporary assembly language source file is saved as the listing file (filename.il). If the designer would like to modify the code that ICS produces, he can edit this source file or create a modified version of the ICS macro file. However, modifying the code that ICS produces may cause your program to be linked, loaded, or executed incorrectly. For example, suppose the designer wants to change the code that saves and restores 8086 registers. This code is found in ics.mc, in macros SAV-86-INLINE$, RES-86-INLINE$, and SAVE-RESTORE-86$. He creates his own copy of ics.mc and modifies those three macros:
______________________________________
cp/lib/8086/ics.mc mymacros
[Make a copy of the
ed mymacros ICS macros.]
[Modify his copy.]
______________________________________
Each time he invokes ICS, he can create the assembly language source file but skip the assembly step:
______________________________________
ics -1 myprog.is [Generate assembly language
source file in myprog.il.]
Then he assemb1es the source file using his own macros:
asm myprog.io myprog.list
[Generate the object file
mymacros myprog.il
myprog.io and listing file
myprog.list]
______________________________________
This assembly command line effectively concatenates his macro definitions (mymacros) with the ICS produced myprog.il and then assembles this file. Table 6 lists the assembly language macros in the ics.ms file and their functions. The ICS listing file produced by ICS from a hypothetical ICS integration source file is now shown. By examining the ICS listing file the ICS configuration object code that is linked into the executable load module that runs on the prototype processor system can be understood. ICS creates a temporary file from the ICS integration source file. This file is assembled and produces the ICS configuration object file and an assembly listing called the ICS listing file. Table 7 is an actual listing produced by ICS. The following is an explanation of the listing of Table 7. During assembly, the assembler uses macro definitions from the file /lib/8086/ics.mc. The macro definitions and their line numbers from the ics.mc file are not shown in the listing. Lines 1-187 are from ics.mc; the remaining lines in the listing are the ICS directives and the assembly language statements they create. (Lines 11-186 are the macro definitions from ics.mc, which are not listed.) Lines 4-9 set up section ICS.INSTR and the standard global symbols, and associate the value DATABASEQQ with the DS register. Line 202 sets up section ICS.VROM, which will contain the interrupt vectors. The VECTOR directive on line 207 generates lines 208-238. Lines 211-235 save the 8086 registers in-line, call the interrupt service routine (called NMI), restore the registers, and return from the interrupt. Lines 236-238 create an interrupt vector at address 0008 that points to the beginning of the register save code (line 212). This spot was marked by the "VECTOR$ SET $" directive on line 210. Lines 237 and 238 (ORG and WORD assembler directives) are typical of lines that create an interrupt vector. ORG defines the location of the vector. This code is placed in the interrupt vector table at address 8H (for interrupt type 2). WORD creates the interrupt vector. The first word created is VECTOR$-CODEBASEQQ. This word is the offset from the CS register which points to the code that saves registers (starting at location 0, lines 212). The second word created, BITS(CODEBASEQQ,4,16) contains the top 16 bits of CODEBASEQQ (which has 20 bits). These 16 bits will be placed in the CS register when the interrupt occurs. The VECTOR directive on line 239 generates lines 240-249. This directive code is similar to the previous code (lines 211-235), except that the 8086 registers are not saved and restored in-line. Instead, they are saved and restored using the subroutines SAV.86$ and RES.86$, the code for which will be generated by the RESTART.sub.-- LABEL directive. The VECTOR directive invocation on line 250 generates the lines 251-262. Since the SAVE-FLOATING.sub.-- POINT and EXCEPT.sub.13 FOR directives direct ICS to save the floating point registers for interrupt types 32 and 34, lines 255-257 save the FPSWQQ variable and the 8087 status on the stack before the call to the interrupt service routine, and restore them afterward. The VECTOR directive on line 263 generates lines 264-275. This directive is essentially the same as the previous directive. The VECTOR directive on line 276 generates lines 277-282. Because of the OWN.sub.-- CODE parameter, no register save and restore code is generated. The four interrupt vectors that are generated all vector directly to TIMER (lines 279-282). All remaining code is generated in response to the RESTART.sub.-- LABEL directive (line 283). The FAULT.sub.-- NOTIFICATION directive (back at line 206) specified that undefined interrupts are to be handled by the interrupt service routine called BAD.sub.-- INTERRUPT. Since interrupt types 33 and 35 are undefined (not listed in any VECTOR directives), lines 284-291 generate the code necessary to save the 8086 registers, call BAD.sub.-- INTERRUPT, and restore the registers. Lines 292-296 generate interrupt vectors to this code for types 33 and 35. Lines 298-352 generate the code for the 8086 and 8087 register save and restore routines: SAV.86$, RES.86$, SAV.87$, and RES.87$. The program initialization code starts at label PASCAL.sub.-- BEGIN (line 356). Lines 357-361 initialize DS, SS, and SP. Lines 362-366 initialize the heap pointers. Lines 368-374 initialize the 8087. Lines 377-381 initialize ES and BP. Line 384 jumps to the main Pascal program. Lines 386-391 set up the RESET vector FFFFO. Table 8 shows the interrupt type, the name of the interrupt service routine for that type, the ICS code that saves and restores registers after an interrupt, and the line numbers of the code in the ICS listing. To create an executable load file, the linker is involved, specifying only the linker command file that ICS has created and the load file to be created. Table 9 is a sample listing of the prompter (block 4) routine and Table 10 is a sample listing of the processor (block 8) routine. Referring now to FIG. 2 there is shown a computer terminal 40 and a host computer 30. Terminal 40 includes a CRT 42, keyboard 43, processor 41, memory 44 and timing and control 45. In addition, terminal 40 includes I/0 46 to enable two way communication between the terminal and host computer 30. Host computer 30 includes CPU 32 which operates under the control of timing and control 36. In addition, host computer 30 includes memory 34 and I/0 38. I/0 38 is the communications link between host computer 30 and the peripherals, i.e. terminal 40, printer/plotter 39 and PROM programmer 37. In operation, the prompter and processor routines, like those included in Tables 9 and 10, are initially stored in memory 34. When the designer, via keyboard 43 of terminal 40, initiates the ICS system the prompter routine is called up by CPU 32 from memory 34. The individual prompts are then transmitted to the CRT of terminal 40 via I/Os 38 and 46. The designer enters his responses via keyboard 43 which are then transmitted back to CPU 32 where the prompter routine formulates the integration source file (FIG. 1, block 6). Next the processor routine is called-up by CPU 32 to convert the integration source to the linker command file and the configuration object file as discussed above. When these steps are completed, the machine independent program to be conditioned for use on the prototype processor system is loaded into host computer 30, together with the standard run-time support library for the language in which that program is written. If host computer 30 includes a compiler for the language, the machine independent program can be entered in either source or object form. In the above example the language of the desired program was to be Pascal. With the four above-identified files, the linker routine of host computer 30, under the control of the linker command file, links the configuration object file, the Pascal object file, and selected as necessary routines of the Pascal runtime library to create the executable load module (FIG. 1, block 20). The executable load module includes, in machine language, the information and locations in the ROMs of the prototype processor system for that system to operate as per the program included in the Pascal object file. With the proper peripherals, the host computer 30 can list the executable load module, via printer/plotter 39, or program test PROMs, via PROM programmer 37.
|
Same subclass Same class Consider this |
||||||||||