DE3321131A1 - SELF-LEARNING CALCULATOR - Google Patents

Abstract

A computer and a system for integrating software with hardware, which is referred to as an "integration control system - ICS" are disclosed. This is an automatic method of formatting machine-independent program writing in a sophisticated programming language in order to give a processor a system without the need for precise knowledge of the assembler, the linker requirements or the language interface requirements. ICS specifies the minimum requirements itself. The ICS system can be stored in a special memory that can be accessed by any computer configuration. The process of the integration system is automatically built from this. By using highly developed directives, the development system is much faster and checks itself for errors. Even errors that otherwise only become noticeable during operation are eliminated. The result is an immediately executable module that can be stored in a conventional manner, for example in PROM.

Description

The present invention relates to a digital computer in which the functional sequence changes in accordance with a file which is obtained by the machine itself during the sequence, and to a method which makes interfaces between software and hardware available. More particularly, the invention relates to a system for translating hardware / software interface specifications immediately into specific microprocessor executable code and into instructions for the linker / loader system of a selected set of hardware.

Devices assembled into computers and made available for any use essentially consist of mechanical and electrical, i.e. circuit components, which interact with the program components entered or stored in these hardware components. The task of providing suitable and suitable links for the hardware component and the software component has always been a very difficult and time-consuming problem to be solved. The system of the present invention enables the designer of a computer device composed of certain pieces of hardware to specify an interface between hardware and software in a sophisticated language in a cooperative manner. This system then translates these specifications into a code that can be processed by the computing device and is accepted as other commands from a program linking loader system can also be included. In this way, a development process that would otherwise take several days or even weeks can be reduced to minutes.

If a highly developed language, such as PASCAL, is used, the system is independent of the actual type of machine language or the interpreter used. Programs based on PASCAL essentially do not need to be changed, regardless of the method or the machine configuration on which they are used. However, with the conventional PASCAL there is no direct way to specify accessory-dependent requirements such as interrupt vectors, restart routines or the memory configuration.

Large-scale machine language or assembly language routine could be developed to link the PASCAL program to the prototype hardware and a linker instruction file to specify the memory configuration. For this it would be necessary to go into great detail about the peculiarities of the specific assembler, the linker and the PASCAL interface requirements. Experience shows that this way of adaptation is very time-consuming and since so many individual steps have to be carried out close to the machine language, i.e. at a low level, errors are inevitable on the way and again only a single solution is created. In the prior art, there are no systems that automatically generate the linker commands and the configuration-dependent command files.

It would be desirable to be able to have a system available that would keep a list of all the steps to be specified for configuring a program on a prototype - from the name of the translated target program to the address where the program begins to execute, and then Based on the responses, the configuration target file is generated and linker commands required for the configuration of the prototype.

If the steps to be carried out in such a system were controlled by a highly developed language, the prototype could be described faster and with fewer errors, and the system itself could immediately check the validity of the information provided and thus avoid errors that would otherwise could only be determined later. The object of the present invention is to make such a development system available in connection with specific hardware. The solution essentially emerges from the preceding claims.

In accordance with the embodiment shown in the drawing, the integration control system (ICS) disclosed here frees the developer of computer-assembled devices and details from designing hundreds to thousands of steps in the computer's own code and then making it error-free and / or optimizing it as well as becoming familiar with increasingly complex linker and / or loader systems that require dozens of special commands in a special linker-command language.

The present invention provides a method and system which allows a program of a high level language with the hardware limitations of a selected one

Prototype processor can be integrated. This is done automatically through the collaboration of the developer to obtain a source file which includes all of the software, hardware and breaker configuration specifications for a selected prototype processor. The system also includes processing the previously created source file to create a linker command file and a configuration target file.

The linker command file controls the process of linking the program in the sophisticated language with the configuration target file to generate a load module that can be executed by the prototype processor. If required, selected routines from the run-time library of the advanced language can also be included during linking.

Interaction with the developer includes responding to necessary inputs relating to the software and prototype processor hardware, and "interrupt" specifications, and then generating a source file in response to those inputs.

The aforementioned configuration target file includes interrupt vectors, interrupt service routines, a reset routine and a program initialization routine for the prototype processor.

Further details, features and advantages emerge from the following description of the exemplary embodiment reproduced in the drawing and the tables.

In the drawing show:

Fig. 1 is a flow diagram of the integration control system according to the present invention and

Figure 2 is a simplified block diagram of a terminal connected to a computer configuration with which the present invention can be practiced.

If a sophisticated language such as PASCAL is used in creating a device-independent program, the computer-generated code cannot be directly executed. The appropriate codes in the runtime instruction set must be linked to the "compiled" code. Depending on the hardware and software requirements of the prototype processor system, this must be initialized for the program. The "linker" must receive an instruction where the generated code is to be stored in the memory of the prototype processor system.

The software / hardware integration control system of the present invention operates generally in accordance with the flow chart illustrated in FIG. A block 2 symbolizes the specifications of the hardware, the software and the interrupt configuration ("interrupt") of the prototype used interactively by the designer in response to the prompts of the prompter or editor according to block 4. These specifications are then used by the prompter 4 to generate the integration Sources file from block 6 used. The source file from block 6 is processed by the processor, block 8, and generates the linker control file, block 12 and the configuration target file, block 10.

The PASCAL target file according to block 14, the software running with the prototype processor system, together with the PASCAL runtime support instruction set according to block 16, the configuration target file, block 10 and the linker control File, block 14 are connected to a linker 18. In the linker 18, the configuration target file is linked to the PASCAL target files and the runtime support instruction set. Under the control of the linker control file, the linker 18 creates a load file, block 20, which can be executed by the prototype processor system specified in response to the prompt 4.

The configuration target file, block 10 contains interrupt vectors, interrupt service routines, a reset routine and program initialization routine for the specified prototype processor system. The linker control file, block 12, created for the particular prototype processor system links the PASCAL target code, block 14, the configuration target file, block 10, and the appropriate run-time support instruction set together. The linker control file, block 12, also maps the target code according to the memory layout of the prototype processor system as specified in response to the prompt 4.

In order for the ICS to function, the basic values of various prototype processor systems must be included as working parameters. These parameters contain such information as for example the maximum memory size and configurations, interrupt procedure etc. In the following description examples of an ICS system are dealt with, which can interface with a PASCAL language program with any of the following microprocessors: 8086, 8086/8087 , 8088 and 8088/8087.

Before the PASCAL target code, block 14, generated by the computer can be executed, it must be supplemented by a configuration target code, block 10, generated by the ICS. If the designer already knows the details of the prototype processor system, he can generate and process an ICS integration source file, block 6, even before he begins programming in PASCAL. In fact, the ICS integration source file provides a concise, human-readable description of the hardware / software interface and this can be used immediately as a programming document.

It is likely, however, that the software will be developed in parallel with the hardware and that portions of the program will be tested prior to the development of the whole program. The standard ICS configuration target file and the linker control file can be used for tests on the program parts in emulation mode. When interrupt handlers are added to the program and fed to the prototype processor system, an ICS integration source file is created, block 6, and / or it is modified to suit the changing environment of the program .

When the ICS system has been initiated, the prompter 4 asks the user for information about the configuration of the prototype processor system. The following table 1 shows a typical compilation of prompts, user responses and a comment field that forms a typical integration source file according to block 6.

Table 1

The ICS prompter according to block 4 is an interactive program which generates the integration source file. The prompter 4 queries the information about the prototype processor system, target files and interrupt configuration and builds the file according to the responses.

When the ICS system is addressed, the processor 4 switches itself on and shows a menu of options for selection on the display. In the "question mode", the prompter 4 begins with the question and the structure of the integration source file. Immediately after the ICS has been addressed, the processor 4 first generates an error integration source file as shown in Table 3 below and then modifies it according to the specifications of the designer.

As previously described, the integration source file is used on processor 8 to generate the linker command file, block 12, and the configuration target file, block 10. Table 2 is a typical linker command file as shown in the integration source file from Table 1

would be generated.

Table 2

Table 3

When the ICS processor 8 has finished reading the integration source file in accordance with block 8, it addresses the assembler of the resident computer so that it generates the configuration in accordance with block 10. The listing of the integration source file according to block 6 is automatically terminated after the assembler has finished.

If the ICS processor 8 finds any errors in the ICS integration source file, it does not generate a linker instruction file or configuration file and the listing only shows the ICS instructions and the associated error indications.

The ICS configuration code according to block 10 performs the following tasks:

- it builds up breaker vectors;

- it builds interrupt service routines;

- he builds a reset routine and

- it builds up program initialization routines.

The ICS generates two types of code to perform these tasks:

- Interrupt Handling Code - Interrupt vectors and the register save / restore routines that can be used in interrupt handling.

- initialization and reset code; a code that contains the segment registers (CS, DS, SS, ES), the storage address, the quantity address ("heap pointer"), the BP register, the 8087 and the floating point status word variable. This code can also comprise a COPYVECTOR routine which copies the interrupt vectors from ROM to RAM and also a RESET vector which generates the reset code (an SMPS instruction) at the point FFFFO.

Most of the code from an ICS configuration object file can be used to interrupt processing. A total of 256 interrupt types are possible and each type can have a different interrupt service routine. Each type of interrupt can save and restore the 8086 and 8087 registers. The code actually generated by the ICS depends on the choice of each interrupt type in the ICS integration source file.

Two sections for the interrupt service code are generated at the same time; one section containing the interrupt vectors (ICS.VROM) and one section containing the execution code (ICS.INSTR). (The "RESUME" assembler statement acts as a switch by first referring a certain amount of the code to one section and then a certain amount of the code to the other section.)

Some of the code of each interrupt service routine is devoted to its manipulation. The assembly code for handling each type of interrupt follows a general pattern.

The general pattern shown below is part of the ICS listing. Uppercase words are either actual assembly language directives or instructions. Mixed-letter (lower-case) words are a description of the function of the assembler code and represent one or more lines of the listing.

; VECTOR INTSERVE, m

RESUME ICS.INSTR

VECTOR $ SET $

Save some registers and get return

Call interruption service program

Regenerate registers

IRET

RESUME ICS.VROM

Create interrupt vector in memory

In the first listing line, "; VECTOR" is the ICS directive which explains the interrupt service routine and the type (s) handled with it. INTSERVE represents the routine which operates the interrupt type number "m".

The SET directive causes the VECTOR $ to become the pointer. VECTOR $ refers to the beginning of the interrupt handling code for this interrupt type.

The "secure some registers and preservation trace-back" code fulfills two functions:

it secures selected registers and enables

the runtime error checking routines to track down the source of the runtime errors.

The "call-to-interrupt-service-routine" code calls the routine that services the interrupt-type.

The "Restoring Registers" code restores the saved registers (see Table 4 below for a list of ICS subroutines used to save or save and restore registers).

The IRET instruction returns control to the interrupted routine.

The RESUME ICS.VROM directive causes any lines of code following the directive to be referenced in the ICS.VROM section.

Thereafter, a ("create interrupt vector in memory") vector is created in memory which points to the beginning of the interrupt handling code. This is achieved with two assembler directives (an example is given in the "sample ICS listing"). The first indicates the place where the break vector should be pointed. The second generates the value of the breaker vector at this point.

The Sample ICS listing later in this section shows the particular code that is generated for each of the breaker types in a Sample ICS source file.

Table 4 lists the subroutines that can be contained in the ICS object code.

Table 4

Interrupt types that are specified with the INTERRUPTS_TYPES__ USED directive but are not mentioned in a VECTOR directive are referred to as undefined interrupt types. The FAULT__ NOTIFICATION directive is used to specify the interrupt handling routine for these undefined types. The RESTART__ LABEL directive creates interrupt vectors for these undefined interruptions. See the "Sample ICS Listing" shown later in this section for an example.

If the INTERRUPT_CONFIGURATION is RAM, the interrupt vectors must be generated (in CONSTANTS_ROM) and then transferred to the interrupt vector area (ICS.VRAM) in runtime. The FAULT_NOTIFICATION directive reserves the appropriate areas in ICS.VRAM for the interrupt vectors and sets up the code for the transfer of the vectors to them during program initialization.

The table created in ICS.VROM is like that shown in Table 5.

Table 5

The program initialization code is generated by the RESTART_LABEL directive, which begins at PASCAL_BEGIN. The initialization code is carried out at runtime and performs the following tasks:

- sets the DS, SS and ES registers at the base of the data segment (DATABASEQQ);

- sets the "stack pointer value" to STKBASEQQ minus;

- initializes the "heap pointers" at HEAPBASEQQ;

- if necessary, calls COPYVECTORS to copy the interrupt vectors from ICS.VROM to ICS.VRAM;

- initializes, if necessary, the 8087 by executing a FINIT and initializes the control word;

- clears the global variable flowing "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 starting point MAINQQ.

The reset code is a JMPS instruction at the position FFFFOH, which refers to the initialization code. When the microprocessor is reset, this JMPS instruction causes the initialization code to be executed.

The RESTART__LABEL statement also contains the code for any interrupt-related subroutines that are required (listed in Table 4).

If the configuration object code generated by the ICS does not match the prototype processor system application, the code generated by the ICS can be modified.

If the ICS is addressed, if the -l (listing) or -o (object code) option is specified and the ICS integration source file does not contain any errors, the ICS generates a temporary composition language source File from the ICS instructions. If the o-option is included, the ICS addresses the 8086 assembler to generate the file name (filename.io) and the assembler listing (filename.il). The assembler call used by ICS looks something like this:

What has to be entered into the assembler consists of two files, which are processed as if they were concatenated in a single file. The first file /lib/8086/ics.mc consists mainly 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. When the assembler stops, the temporary file is automatically deleted.

If the -o option is omitted, the temporary assembler language source file is saved as a listing file (filename.il). If the programmer wishes to modify the code generated by ICS, he can edit this source file or generate a modified version of the ICS macro file. However, changing the code generated by the ICS can result in the program being linked, loaded or not executed correctly.

For example, if it is assumed that the programmer wants to change the code that saves, saves, or restores the 8086 registers, he can write that code in ics.mc, in macros SAV-86-INLINE $, RES-86-INLINE $, and SAVE-RESTORE-86 $ find. It creates its own copy of ics.mc and changes these three macros: cp / lib / 8086 / ics.mc mymacros ["Make a copy of the ICS macros"]

ed mymacros ["change its copy"]

Every time he calls ICS he can generate the assembly language source file, but omit the composition level:

ics -l myprog. is ["Create assembly language source file in myprog.il."]

Then he assembles the source file using his own macros:

asm myprog.io myprog.list ["Create the object file myprog.io and listing file myprog.list"]

mymacros myprog.il

This composition command line effectively concatenates its macro definitions (mymacros) with the myprog.il produced by the ICS and then composes this file.

Table 6 lists the assembly language macros in the ics.ms file and their functions.

Table 6

The ICS listing file generated by the ICS from a hypothetical integration source file is now displayed. By studying the ICS listing data, the ICS configuration object code associated with the feasible load module connected on the prototype processor system can be understood.

ICS creates an intermediate file from the ICS integration source file. This file is put together and creates the ICS configuration target file and the resulting listing is called "ICS listing file".

Table 8 shows the interrupt type, the name of the interrupt service routine for this type, the ICS code which saves and stores the registers after an interruption and the line numbers of the code in the ICS listing.

In order to be able to generate an executable, loadable file, the linker is involved in each case, by which only the linker file command is specified which was created by the ICS system and which loads the file to be created.

Table 9 is an exemplary listing of the prompting routine according to block 4 and table 10 is an exemplary listing of the processor routine according to block 8.

Table 8

Table 9

ICSP_MENU

1) Enter 'question mode'

2) Enter 'edit mode'

3) Display the file

4) Check the file for errors

5) Back up the running copy of the file

6) Acknowledge

7) Show an introduction to 'edit mode'

8) View an introduction to ICSP

Remember: You can "?" Enter for more information or "!" to return to the menu.

1) Enter 'question mode'

In 'question mode', ICSP asks questions and modifies the file according to the answers. To get out of 'question mode' enter "!" a.

2) Enter 'edit mode'

In 'edit mode' the file can be scanned and lines of the text can be added, omitted or substituted. For a description of 'edit mode' choose point 7 of this menu.

3) View the file

ICSP keeps a copy of the file in memory and modifies this copy according to the instructions. This option shows the copy of the file that is in memory, but not the file on the disk.

4) Check the file for errors

ICSP contains ICS to check the carrier file for errors. If the carrier file does not contain the latest changes, it will be brought up to date before ICS starts.

5) Back up the running copy of the file

The copy of the file in memory is written out from the carrier.

6) Acknowledge

ICSP is exiting. If the carrier file does not contain the latest changes, the option is given to bring the carrier file up to date.

7) Show an introduction to 'edit mode'

This introduction contains a listing of the 'edit mode' commands.

8) View an introduction to ICSP

This is the same 4-part introduction seen earlier.

What should be done with the information?

1) Leave them unchanged.

2) Add more lines.

3) Remove this information and get new information for this instruction.

mulit_line_info

If you only want to change some of the information, try 'edit mode'.

(Write! To get to the 'main-menu'.)

no mistakes

Congratulations - no mistakes! Now back to the ICSP menu ...

in case some bugs

Welcome back to ICSP. It looks like ICS found some errors in the file just created.

If you understand what is wrong with the file, you can try using 'edit mode' to identify the faulty lines. However, if there are errors that are not understandable, check the prototype section of the manual. You can also use question mode to get more information about the problem areas in the file.

INTRODUCTION TO ICSP

ICSP creates or modifies an ICS source file according to the instructions. From this source file, ICS can generate:

° an object file which contains code to initiate the Pascal program and interrupt vectors; and

° a linker command file, which tells the linker how the object files are combined using Pascal, ICS and the 8086/8088 assembler.

INFORMATION REQUIRED FOR ICSP

The ICS source file provides the following types of information about the program:

° HARDWARE CONFIGURATION - what kind of chips are used; which areas of memory serve as RAM and which as ROM; whether the program uses service calls.

° SOFTWARE CONFIGURATION - the names of the object files that make up the program.

° INTERRUPTION CONFIGURATION - which types of interrupts (if any) the program must handle; the names of the interruption service programs; how these programs are initiated.

To use ICSP effectively, this information should be available.

Example of an ICS source file

PASCAL_KONFIGURATION:

HOW ICSP WORKS

ICSP has two modes of operation: 'question mode' and 'edit mode'.

In question mode, ICSP asks questions and uses the answers to generate an ICS source file. When using ICSP for the first time, question mode should be used. It helps in learning the meaning of each ICS command and its parameters.

In edit mode, the ICS source file can be scanned and easily changed. A detailed description of edit mode follows later.

In every operating state, ICSP shows the old parameters of a command before it is modified and shows the new parameters afterwards.

? AND !

In both modes, ICSP waits for the user to write something. You can use a "?" or a "!" input. "?" indicates to the ICSP that it should provide more information about what to expect as input. "!" creates a compilation of requirements which ICSP can execute.

TROUBLESHOOTING

In question mode, ICSP tries to provide enough information to ensure that the generated file has the correct syntax and is logically consistent. To ensure that the file is actually correct, a "check file for errors" can be selected from the main menu. ICSP causes ICS to scan the file; ICS reports any errors and records them in the file.

ALTERNATIVES TO ICSP

ICSP is provided to simplify the creation and modification of the ICS source file. However, if the user is familiar with the ICS language, he may find it just as easy to use a standard text editor to output the ICS file.

SYNTAX CONSIDERATIONS

Any hexadecimal number that is entered must start with a decimal digit and end with an "H". (e.g. OFFFFH, not FFFF)

Each range of numbers has the form (small number, large number), e.g. (25,30) means the range from 25 to 30 (decimal) and (OH, OFFH) means 0 to FF (hexadecimal).

EDIT MODE

Edit mode has two uses:

1) Once a file has been created (e.g. using question mode), edit mode can be used to scan the file and make corrections.

2) Once the user is familiar with the ICS language, edit mode can be used to create new files from the ICS network.

In edit mode, ICSP displays a line from the ICS source file. The line can be confirmed by pressing the RETURN key and the next line can be passed or a new parameter field can be entered to replace the one shown.

The following is a summary of the possibilities of edit mode:

Command function

! exit edit mode and return to main menu

? show this list of edit-mode commands

[return] go to the next line

[text] replace the text in the parameter field

- go to the beginning of the file

++ go to the end of the file

-n go back n lines in the file

+ n go n lines forward in the file

AC add a command after the current line

IC insert a command before the current line

D delete the current line

For instructions that occur more than once:

A add an instruction after the current line

I insert an instruction before the current line pas_con

Please enter a title for the ICS source file.

pas_con_info

This title can be as long as you want and can contain more than one symbol, just no double quotes.

hw_con

Which of the following expressions best describes the processor you are using?

1) 8086

2) 8088

3) 8086 with 8087

4) 8088 with 8087

Explanation of the memory

The program contains "absolute" codes and "shiftable" codes. Absolute codes must be placed in specific locations in memory (e.g., break vectors must be placed in locations 0-3FF).

The code generated by the Pascal compiler can be moved. The ICS can instruct the linker to place the relocatable code anywhere in memory.

The following types of code can be stored in ROM:

INSTRUCTION ROM - Executable Code

CONSTANT ROM - other codes that do not change when the program is run - for example, strings of letters and numeric constants.

The following types of code must be stored in RAM:

GLOBAL-VAR-RAM - variable from the outer level of the program.

HEAP-STACK-RAM - the area occupied by the stack memory and the heap. The stack starts at the top of this area and grows down, while the heap starts at the bottom and grows up. The stack contains parameters, return addresses and local variables of the programs. The heap contains linker-listed variables obtained with the standard NEW procedure.

For more information on these four ICS instructions, including an explanation of programming assembly languages, see the compiler manual.

Menu memory

The user can:

1) confirm the assignments

2) change the INSTRUCTION ROM

3) change the CONSTANT ROM

4) change the GLOBAL-VAR-RAM

5) change the HEAP-STACK-RAM

6) view the ICS explanation of these terms

Save prompt 1

Enter one or more ranges of hex addresses (more than one line can be used).

Save prompt 2

Enter one or more ranges of hex addresses.

Any additional storage

Does another line of address ranges exist for this instruction?

Range syntax

Every hexadecimal number must begin with a decimal digit and end with an "H".

Reset memory

How does the prototype handle a RESET?

1) The memory contains the first instruction to be executed after the RESET at locations FFFFO-FFFFF.

2) Special hardware causes the first instruction to be executed. (Type "2" of the program does not handle the RESET.)

svc-info

A service call is a request from the program for a service of the MDL operating system (OS / 40 or DOS / 50). Pascal I / O determinations (e.g. READ, READLN, WRITE, WRITELN) are converted into service calls. If all of the program's I / O is handled by the prototype, then you can probably answer "N"; otherwise the answer is "Y".

Vector channel info

A service call (SVC) begins when the program executes an OUT instruction on one of the selected ranges of 8 I / O channels. The operating system (DOS / 50 or OS / 40) directs the channel number to an "SRB pointer" which points to the SRB (service request block), which describes the service to be performed.

The arrangement of 8 SRB pointers is called an "SRB vector". The SRB vector usually occupies bytes 40-5F of the memory. If the program requires the use of these areas of the memory for other purposes (such as interrupt vectors, for example), a different arrangement for the SRB vector can also be provided. If the program uses I / O channels in the default SVC channel area (FFF0-FFF7), another channel area can be used for the SVC.

The SVC are described in detail in the 8540 and 8550 manuals.

svc-menu

It is possible:

1) confirm the settings

2) change the arrangements of the SRB vector

3) change the SVC channel range

4) Show the ICSP explanations of these terms on the display.

sv-con-info

This is the object file that is created when the main program is compiled (the one with the PROGRAM statement). An object file can also be specified which has been generated by the assembler, or "NONE" can also be entered.

Other module

Are there any other object files to be linked to the program?

Module info

Such a file could in particular be:

° the object file that is created when a Pascal module is translated that begins with a MODULE; or

° an object file generated by the assembler.

module-prompt

Enter the pathname of the object file to be linked (example: /usr/john/controller/meltdown.po)

Libraries

Does the program use any subroutines from libraries other than the usual Pascal runtime auxiliary library?

ANNOTATION

If the user has created his / her I / O library (to replace pas.posi.scsd), this library should not be included here. This library will be explained later with the FILE SUPPORT statement.

Library info

The library generator (libgen) can be used to create libraries with your own Pascal or assembler language routines. If libgen was not used, an "N" should be answered.

Library prompt

Enter the "pathname" of the library used by the program (example: / usr / john / controller / lib)

other libraries

Does the program use routines from other libraries?

file-sup

If the program uses one of the following methods or functions:

READ, READLN, WRITE, WRITELN, REWRITE, RESET, GET, PUT, PURGE, ASSIGN, PAGE?

file-lib

Should the program use the standard library of the Pascal I / O programs?

enter lib-info

If "Y" is entered, the I / O program is taken from pas.posi.scsd.

If "N" is entered, a library program must be entered to replace pas.posi.scsd.

get-file-lib

Enter the pathname of the library of the I / O programs (example: /usr/john/controller/io.lib) get-io-lib

Enter the pathname of the I / O library.

(Example: / usr / john / controller / iolib)

ram-or-rom

Which of the following sentences best describes the interrupt vectors stored in positions 0-3FF?

1) the places 0-3FF are in the ROM.

2) the places 0-3FF are in the RAM. The interrupt vectors are copied into locations 0-3FF during program initialization.

intrpt-types-intro

List the interrupt types (0-255) that the program has to process. (More than one line can be used.)

intrpt-types-prompt

Enter one or more decimal numbers or ranges of decimal numbers. Example: 0,2,4, [16,31], 33, [128,143]

intrpt-types-info

The program does not necessarily need an interrupt service routine for each of these types. Using the FAULT-NOTIFICATION statement, ICS can be used to generate a routine for processing unexpected types, or your own default routine can be created. A 4-byte interrupt vector is generated for each interrupt type in the list.

Other types (of interruptions)

Do you want to enter a different line of interruption types?

save-float-intro

For each of the interrupt types (0-255), ICS can automatically save the program's floating registers before calling the interrupt service and refresh the registers after the routine is completed.

How many of the interrupt types handled by the program require ICS to save and regenerate the floating registers?

1) none

2) less than half

3) half or more

4) everyone save-float-info

If floating registers are to be saved, the internal Pascal variable FPSWGG is saved in the stack register before the interrupt service is called. If an 8087 is available, the program will also execute FNSAVE commands before the call is made and a FRSTOR command afterwards.

In general, only a single flow save register is needed when the interrupt service routine uses flow operations.

except-prompt

Enter one or more decimal numbers or ranges of decimal numbers.

Example: 0,2,4, [16,31], 33, [128,143]

further exceptions

Do you want to add another line of exceptions?

fault-not-menu

What should happen if an interruption occurs, but no service routine is provided for this type of interruption?

1) Stop the program with an LDS instruction.

2) Output of an error message and stop of the program.

3) Execution of a routine that is written.

fault-not-info

This question relates to any interruption that is listed in the INTERRUPT-TYPE-USED passage directive but is not assigned to an interrupt service routine in a VECTOR directive.

get-default-name

What is the name of the routine for handling unexpected interrupt types?

default-name-info

This name can be the name of a Pascal method or a general symbol that marks the entry of an assembly language routine. own-code-menu

If such an interruption occurs, the program should:

1) contact the routine directly processing the return from the interrupt, or

2) save the registers, go to the routine, reset the registers, and come back from the interrupt?

in-line menu

Should the register backup and the resetting of the routines be designed as follows:

1) including in-line (saves about 55 cycles per routine), or

2) be called as a subroutine (saves about 6 bytes per routine)

vector-intro

You will now be asked for the list of names of the program's interrupt service routine. Each name can be the name of a Pascal procedure or a general symbol that marks the entry of an assembly language routine. For each routine, the types of interrupts that the routine processes are listed.

Are there any interruption service routines to list?

restart label

Are there any assembly language routines that have to be executed before the Pascal program starts?

restart-info

The stack registers heap and segment registers are automatically initialized by ICS routines before the Pascal program starts. These routines begin at the starting point PASCAL_BEGIN. If there is an initialization routine which must precede the start of the Pascal program, answer with "Y". This routine must end with a jump to PASCAL_BEGIN.

get-restart-label

Enter the name (entry point) of the routine that must be executed when restarting. This name must be a general symbol, it is used as the transmission address of the program.

End of text.

Table 10

In FIG. 2, a computer terminal 40 is shown in connection with a central computer 30. The terminal 40 comprises a visual display 42, for example a screen or a display, an input keyboard 43, a processor 41, a memory 44 as well as a timer and a control 45. In addition, the terminal 40 is provided with an on / off interface 46, to enable a two-way connection to a central computer 30.

The actual computer 30 has a central processing unit (CPU) 32 which operates under a clock generator and control unit 36. In addition to a conventional main memory or storage medium (not shown), the CPU 32 is also connected to a special memory 34 which can be connected to the other memories. An input / output interface (I / O) 38 enables a connection to the periphery and to the terminal 40, as well as to a printer or plotter 39. A connection to a programmer 37 is also provided.

The prompter and processor routines according to Tables 9 and 10 are contained in the special memory 34 for operation in accordance with the invention. As a result, an operator can initialize the ICS system via the keyboard 43 of the terminal 40, as a result of which the prompting routine is called up by the CPU 32 from the special memory 34. The individual prompts are then transmitted to the data display device or screen 42 of the terminal 40 via the interfaces (I / O) 38 and 40. The operator enters his answers using the keyboard 43 and these are transmitted back to the CPU 32. The integration source file according to block 6 in FIG. 1 is thus created in the CPU 32 from the entries as additions.

Next, the processor routine is called by the CPU 32 to automatically convert the integration source into that linker control file, as discussed in detail above, whereupon, also automatically as previously described, the configuration object file or a new operating system for a computer or a new compactly written work file.

As soon as these steps have been carried out largely automatically, the resulting program can be made machine-independent in that, if another prototype of a processor is to be loaded, which differs from the one in the machine described here, its parameters (clock frequency with standard instruction set) in the computer 30 are loaded, whereupon a compiler can be entered in the computer 30 or, depending on the desired language, can already be contained therein, so that either a machine-independent source file or a source file linked to a specific language is created. In the example above everything was done with a very sophisticated computer language, PASCAL,

connected.

With the four files described above, the linker routine of the resident computer 30, under the control of the linker command file in conjunction with the configuration object file, the Pascal object file. File and routines of the Pascal runtime instruction set that have been found to be necessary result in an immediately executable LOAD module according to FIG. 1, block 20, to be precise in the shortest possible time, free of errors and almost completely automatically. The executable LOAD module includes - in machine language - the information and assignments in the ROMs of the prototype processor system for this system to work as a program, including in the Pascal object files, insofar as these have been created.

With the appropriate peripherals, the modules can both be fed to the programming stage 37 in order to be loaded into a PROM or the contents can be specified via the printer or plotter 39.

Insofar as the present disclosure contains details that are not directly covered by a protection from this application, the applicant reserves all rights of the on the day of the application in the Federal Republic of Germany or on the day of the disclosure of the complete application documents for the legal area of the Federal Republic of Germany commercial use of the programs disclosed herein. The programs may not be reproduced, distributed or used on computers, data processing systems or in development systems in any form without the consent of the applicant.

Claims (13)

1. Digital computers in which the functional sequence changes according to data or files that are obtained by the machine itself during the sequence, or the functional sequence adapts, including fault detection or fault monitoring with a unit composed of a central processor and peripherals which includes at least one input, one display and one output unit, characterized, that can be loaded from a control panel (43) into the central processor (8, CPU, 32) from a special memory (34) through an integration source file (6), whereupon a connector control file (12) and a configuration object file ( 10) a module (20) can be generated together with other sources (14, 16) via a connector (18), which module can be fed to a program security stage (37). 2. A method for integrating a highly developed programming language with the hardware limitation of a computer according to claim 1 with a selected prototype processor, marked by following steps: a) interactive preparation of a source file containing the content of a special memory (34) for a system required for the operation of a processor (CPU, 32) including all interruption and other specifications in response to a query via a display (42) and via the input unit (43) entries made, b) processing the source file from stage a) to generate the linker command file and a configuration target file. 3. The method according to claim 2, characterized, that it includes the following additional step: c) Linking the sophisticated programming language with the configuration target file under control of the linker command file to generate a load module that can be carried out by the prototype processor. 4. The method according to claim 1, characterized, that step a) includes the following stages: a1) displaying the programming steps required to enter software and control the prototype processor hardware and interrupt specifications; and a2) Generating a source file containing these specifications. 5. The method according to claim 2, characterized, that it also includes the following level: d) linking the advanced programming language, the configuration target file and selected routines from a runtime instruction set for the advanced programming language under the control of a linking instruction file to generate a load module (20) executable by the prototype processor. 6. The method according to claim 2, characterized, that the configuration target file from stage b) contains interrupt vectors, interrupt service routines, a reset routine and a program initialization routine for the prototype processor (8, 32). 7. The method according to claim 2, characterized, that the connection command file of stage b) contains routines for connecting the sophisticated programming language, the configuration target file and a suitable run-time support command set. 8. An integration control system for integrating a sophisticated programming language with the hardware limitations of a selected prototype processor Means for interactively preparing a source file, the software, hardware and breaker configuration specifications of the selected prototype processor in response to programming inputs and Means for processing the source file to generate a link command file and a configuration target file. 9. System according to claim 8, marked by Means for linking the advanced programming language to the configuration target file under the control of the link command file to create a load module executable by the prototype processor. 10. System according to claim 9, characterized, that the interactive preparatory devices prompt the programming for input of software to the prototype processor hardware specifications and to the breaker specifications; and Have devices for generating a source file containing these specifications. 11. System according to claim 8, marked by Means for linking the advanced programming language, the configuration target file and selected routines from a run-time instruction set for the advanced language under the control of the link instruction file to create a load module executable by the prototype processor. 12. System according to claim 8, characterized, that the configuration target file contains interrupt vectors, interrupt service routines, a reset routine and a program initialization routine for the prototype processor. 13. System according to claim 8, characterized, that the link command file has routines for linking the sophisticated programming language, the configuration target file and the appropriate run-time support instruction set.