JPH03208187A - Interface for graphic processor sub- system - Google Patents

Abstract

PURPOSE: To perform complete linkage on a test graphic sub system by loading a developed extension function and calling a function from a main program at run time. CONSTITUTION: The extension function to be executed by a graphic processor is prepared in steps STs 11 and 12 and definition is made so as to pass the argument to the graphic processor in the run time. Then, the function composed of a high standard language is called from the main program during running on a host system in the STs 13 and 14 and loaded by a graphic system. In this case, one function during running is moved and it is called by the same parameter. Thereafter, the extension function is compiled and executed on the graphic processor in the ST 14. Then, when the extension function is partially linked and a DLM is formed, the complete linkage is performed in the STs 15-17.

Description

DETAILED DESCRIPTION OF THE INVENTION FIELD OF INDUSTRIAL APPLICATION The present invention relates generally to a software interface for a computer processor, particularly for a system comprising both a host processor and a graphics processor.

[Conventional technology]

Today's computer systems that use graphical displays utilize a different set of architectures. Some systems include a host processor and a display controller. These are essentially hardwired bino1 map systems, requiring the host processor to perform all graph ink processing. However, a drawback of such systems is that as the requirements placed on the graphics, such as resolution, become more stringent, the processing burden on the host processor also increases, resulting in slower processing speed.

As an alternative to a display controller, other systems delegate graphics processing duties to a graphics processing subsystem. Some such systems rely solely on Herhoware to perform the GraphInk function. Other graphics processing subsystems use programmable graphics processors to allow programmers to add functionality.

Although graphics processor subsystems allow for high resolution and fast execution, a drawback of many such systems is that they are not easy to extend, whether hardwired or programmable. It is a point. Even subsystems with programmable processors have difficulty integrating the host system and their application programs, and for this reason they are essentially fixed function systems.

Because such systems strive to be as general-purpose as possible, adding too much functionality to a subsystem means that functionality is gained at the expense of efficiency, creating the so-called "reincarnation" effect. They tend to have. Another problem with systems that have a fixed set of capabilities or are difficult to scale is that they cannot keep pace with GraphInk software as new GraphInk algorithms are constantly being developed. It is a point.

Besides extensibility, another issue to consider when designing a GraphicSoc system is that of standardization. From a hardware manufacturer's point of view, the purpose of the Graphink standard is to allow one Graphink system to be used with many application programs. From a software development perspective, a standard must allow a program to run on any graphics system.

Many failures, such as CGA, EGA, and VGA, are directed toward single proscenosa systems rather than graphinoxa subprocenosa systems, and they are
Although it has had some success in interfacing software and graphics hardware, it has not been successful in providing an interface between the host and the graphics system.

Therefore, a need exists for a graphics subsystem interface that can provide extensibility without compromising efficiency. Additionally, a mechanism for achieving extensibility needs to provide an interface that allows both application programmers and hardware manufacturers to target their products. Although the above interfaces are of a sufficiently high standard to encourage standardization,
Moreover, it must be at a sufficiently low level to facilitate processing speed.

[Problems to be Solved by the Invention] [Means for Solving the Problems] To describe the present invention from one aspect, it is executed by a graph ink processor subsystem, but is called from a main program running on a host processor system. Contains information on how to extend functions. The basic steps of the above method are:
Create a subprogram realized by the graph ink processor, define the subprogram so that its arguments can be passed at runtime,
Compiling or assembling a subprogram for the GraphInk processor, loading the subprogram into the GraphInk processor, and linking the subprogram to the previously loaded function.

Another aspect of the invention relates to a method of using a GraphInk subsystem in a host computer system. The method uses a Graphics subsystem to provide a set of primitive core functions, a host system to download extension functions to the Graphics subsystem, and a software interface to provide a set of primitive core functions from the host system. It consists of the basic steps of passing arguments to the system and then using the GraphInk subsystem to execute extension and core functions.

Viewing the invention from a hardware perspective, executing a single software program on a first processor allows that program to call specified functions to be executed by a second processor. It is a multi-processing computer system. The system consists of a programmable host processor system and a programmable graphics processor system, the host system using a software interface that allows extension functions to be downloaded to and executed by the graphics processor.

Another aspect of the invention is a software interface for interfacing a host processor and a graphics processor subsystem of a multiprocessing computer system. The present invention includes various software programs that process data provided by an application program so that the application program can call functions executed by a graphics processor. .

Advantages of the Invention A technical advantage of the present invention is that it allows the Graphink subsystem to be both efficient and easily scalable.

Execution speed is optimized because software developers can create custom sets of graph ink functions that best fit their applications. Another advantage of the present invention is that it allows standardization of the methods used to extend the functionality of the Graphino subsystem.

This publication is intended for both hardware manufacturers and software developers to provide an interface to their products.

[Embodiment] The hardware environment in which the present invention operates is a multi-processing computer system having at least two processors, a host processor and a graphics processing processor, expressed in -tC terms. Common tasks for such systems are computer aided design (CAD), desktop rendering, image processing, and high resolution graphics processing such as presentation graphics. The hardware aspects of the invention are discussed in detail with respect to FIG.

One of the advantages of the present invention is that the main software program written in one language can run on the host system, but call functions designated to be executed by the graphics processor. be.

Implicitly, therefore, the processor used in the case of the present invention can be programmed in a high-level language;
The language may be the same for both processors. Thus, each processor interacts with its own set of instructions and a compiler to create the low-level language of that processor.

The idea underlying the invention is that the graphics functions to be implemented on the graphics subsystem are best implemented in two groups: core primitive functions and extension functions.

Core source functions are always available to the graphics processor. These core primitives include a small number of basic graphics utility functions, but also provide functions for system initialization, graphics attribute control, memory management, screen clearing, cursor manipulation, communication, and expansion. . Extension functions provide graphics functions that are loaded and used by application programs as needed.

The following description of the software aspects of the invention is primarily directed to programs written in the C language. However, the programming environment in which the present invention operates is not specific to the C language, and the programming structures and functionality described herein can be easily translated to any high-level language.

Its specific implementation is believed to be within the ability of programmers of ordinary skill in the art upon reviewing this specification. The present disclosure is provided for implementing the invention in the myriad languages and systems available today for a variety of applications.

Extension functions can also be easily programmed in assembler language, in which case they are called in a similar manner.

The same method is used except that the extension function code is unassembled rather than compiled. Therefore,
In this explanation, "assemble" can be replaced with "compile".

A "user" in the present invention can be any number of people who provide different parts of a multi-processing system. For example, the user may be a software developer who wishes to add extensions to an application or driver he is developing for use on the system. Or you may simply be a programmer providing an extension function for use by other programmers. Alternatively, hardware manufacturers, such as board manufacturers, can program functions for graph ink systems. Further, the user may be a person who actually executes a program using the interface. Furthermore, as is typical of computational methods and programs, the user may also be other software running on a computer.

For purposes of this discussion, such subprograms that a user may wish to add to a multiprocessing system will be referred to as "extension functions." The system that executes the main program is the "Host Brocenosa System" or "
This will be referred to as the "host system." In this case, the Brocenosa is referred to as a "host Brocenosa". The system on which the extension functions are executed is a "Graphics Processing System" and its processor will be referred to as a "Graphics Processor" or "Graphics System Processor J (GSP)".

FIG. 1 is a block diagram illustrating the basic steps of creating an extension function for use with a multiprocessor system that includes a host processor and a graph ink processor. Using this method,
A single programmer can create graphics functions that are not included within the core primitives. These extension functions are built into dynamic load modules (DLMs) and used by end users, who typically download them to the GraphicSoc system upon initialization. They can then be called from the main program running on the host system.

The basic steps of the above method are to create a suitable subprocessor for the graphics processor to execute, define the subprogram so that its arguments can be passed during execution, compile it for the graphics processor, and then This is to form a DLM by linking some subprograms. Ultimately, the DLM is downloaded to the graphics processor where it is linked with existing subprocessor functions and core primitive functions.

In Step 11, the programmer develops a subprogram having at least one, and usually a set of functions, suitable for execution by the GraphInk processor. These functions can be written in high-level or assembler language. One of the features of the present invention is that the extension function can be written in the same language as the main program and can be compiled or assembled for the graph ink processor. Function constants, as well as other computer programming elements used to implement the present invention, will be referred to herein as its "code."

In step 12, the subprogram is defined in such a way that subprogram arguments can be passed to the graph ink processor during runtime. Step 13 is related to step 12 in that calls to subprograms in the main program must be expressed in an understandable form by the definition of step 12. Steps l2 and 13
There are at least two different ways to do this.

These methods are described in ``Software Partitioning in Multiprocessor Systems'' and ``Extended Software Functions for Multiprocessor Systems'' (Texas Instruments Inc., Case No. 13), respectively.
No. 625, and co-pending application No. 114443). The first application describes a packet method of adding extension functions to a multiprocessor system, and the second application describes a direct method.

The disclosures of both of the above applications are incorporated into the text for reference.

The packet method is designed to extend the GraphicSoc system with minimal programming effort on the part of the user. According to this method, functions written in a high-level language such as C can be called from a main program running on a host system and executed by a graphics system. In fact, as explained in the co-pending application cited above, the Baquesoto method allows a single user to move a function running on the host system to the GraphInk system and call it with the same parameters. can. In the Paque-Noto method, function arguments are sent in the form of a Baque-Noto that describes the size and type of data to be sent.

In the direct method, arguments are not placed on the stack as in the bucket method. The function is called by the graphics subsystem with one argument. The above argument is
A communication pointer to which the host downloads the function arguments.

The above function contains an additional load, which instructs the graphics processor to obtain parameters from the bath sofa and match them with local variables. The above functions are called from the main program using the direct entry point method. The entry point determines the formalism of the function's arguments and the return condition. These direct entry points are detailed in the co-pending ``Extension Functions'' application. Stenov 14 compiles subprograms for the graphics processor. If the subprogram is written in assembler language for the Grapheno processor, it goes without saying that the Stenop 14 will assemble that code. Compilation and assembly techniques are well known.

Stethop 1 5-1. 7 calls for partial linking and loading of subprograms. The implementation of these steps is described in a co-pending application entitled ``Load Time Linker for Software Used in Multiprocessor Systems'' (Text Instrument Inc., Case No. 14442).

This application is incorporated herein by reference. Since an important feature of the present invention is that extension functions can be loaded and ringed at runtime according to the requirements of a specific application program, the link loading step described above is
In this text, this will be referred to as "dynamic downloading."

In accordance with the load time linker methodology described in the co-pending application, step 15 links some of the subprograms to form a DLM. This partial linking procedure decomposes all references to variables and functions within the subprogram.

Those variables and functions referenced externally by the subprogram remain undecomposed. Stesob 16 is DL
Load M into the Graphi Nok system. It is desirable that loading occurs during runtime so that the application program can be commercially available separately from the hardware with which it is used. Stesop 17 is D L. Complete the linking of M and disassemble all external reference variables and functions residing in the subprocessor system. These resident functions will typically be core cost functions, but may also be other extension functions loaded by the method of the invention. During the software development stage, steps 16 and 17 may be performed on a special test graphics subsystem rather than on the graphics subsystem on which the application will ultimately be used. Nevertheless, the test system is assumed to include a graphics processor and an emulator, and the method is essentially the same. The end user can also perform steps 16 and 17 at runtime.

FIG. 2 illustrates the second aspect of the invention, a method of using a graphics subsystem in a host computer system. FIG. 2 is in the form of a system flow diagram in which the method steps are associated with a software program that executes them. Overall, FIG. 2 shows host memory 210 and graph ink memory 22.
Consists of software that resides together in 0. The software resident in the memory 210 is the communication driver 2.
11, an application program object file 214, and an extension function object file 216, the latter of which is stored in graph ink memory 2 as discussed below.
Loaded to 20.

Components numbered 212 and 215 indicate that the application file 214 and extension function DLM file 216 were compiled from source code modules. One of the application files 214 is the main program 213. The software resident in the memory 220 includes a command execution routine 221, an executable file 226 for extension function definitions, an include file 225, and core primitive functions 222, 223,
It is 224. These components are further discussed in connection with FIG.

The method of FIG. 2 is for use on a multiprocessing computer system that includes means for communication between processors. Accordingly, it can best be understood by reference to FIG. 3, which is a block diagram of such a system. The system is host processor system 3
10 and a Graffino Kubu mouth senosa subsystem 320. The graphics processor 320 is configured such that the graphics processor 321 runs in parallel with the host processor 311 to calculate and process graphics information, while the host processor 311 can continue processing other processing tasks. is desirable.

The host processor 311 is Intel's 80286
It is g-tsu that is optimized for peripheral control such as and 80386 Brosenosa. Although these processors are used with DOS-based personal computer systems, the invention is not limited to DOS operating systems. In fact, the methods and mechanisms described herein can be implemented using a variety of processors and operating systems. Memory 210 associated with host computer 311 may include random access memory (RAM) so that it is accessible to the programs that direct its processing.

The graphics processor 321 is designed for graphics processing and is programmable.

An example of such a processor is the Texas Instruments 34010 graphics processor, which includes:
The processor is a 32-bit microprocessor with an expanded instruction set for graphics processing, along with hardware for display device control and refresh operations. The memory 220 includes a RAM memory, so that
The graphics processor 321 can store in the same memory a program that instructs how to process graphics information.

The communication means between the two processors is path 3.
30 and a communication bath sofa 323. pass 33
0 is bidirectional and provides data paths and control lines. The communication bath sofa 323 is accessible by both processor systems 310 and 320 and is accessible by the fifth
The diagram will be explained in detail. It is also possible to create other hardware with 1,000 communication stages, in which case the primary requirements are that each of the bus sets IJ-311 and 321 can access the communication buffer 323, and that the same bus sofa 323 can access the communication buffer 323. , a message data space for handshaking between processors, an identification space for identifying the function being called, and a data space for passing command arguments and additional data. The configuration shown in FIG. 3 is only one of many ways to enable processor-to-processor communication, and other means can easily be developed. Furthermore, although FIG. 3 shows a two-processor system 310, 320 with separate memories 210 and 220, the communication means may be a shared memory.

The multiprocessor system of FIG. 3 includes a variety of standard peripherals, particularly a display 340, mass memory 350, and human power devices 36 such as a keyboard and mouse.
Works with 0. The host system path 3 between these human output devices and other host system 3 1 0 parts
I/O circuitry 313 is used to communicate information in a suitable manner via 14. Human powered device 360 allows a user to interact with host brothel system 310 . Display 340 is connected to graph ink processor 321 via well-known control and human output techniques.

Referring again to FIG. 2, the above method downloads an extension function from the DLM file 216 to the graphics subsystem 320, calls the extension function from the main program 213, and passes the arguments of the function to the host system 31.
It consists of the basic steps of passing from 0 to subsystem 320 and executing the extension function. Core primitive functions are loaded into graph ink subsystem 320 before main program 213 calls functions that reside within subsystem 320. This allows loading and linking to be performed by the graphics processor 321 and allows certain basic graphics tasks to be called by the extension functions.

Since the method of FIG. 2 does not need to be performed until one application programmer is to be executed, method 2 will be referred to as the runtime method. However, it should be understood that the above application program can be re-executed without having to load and link the extension functions again.

Thus, in step 22, the extension function DLM 216 is loaded into graphics memory 220 and linked with any other code it calls. This is achieved by a core function, Dynamics, Noclinker 224. The linker 224 performs the loading and linking steps described above with respect to FIG.

In particular, the loading and linking of stenob 22 causes extension function DLM 216 to be loaded into memory 220 and linked to other extension functions and core primitive functions at runtime, allowing executable file 226 to be formatted. The Dynalinker 224 uses the symbol table file that is part of the include file 225 to create an executable file 226 that contains the extended functions and identifies the functions to the rest of the system. One of the features of the present invention is that extension functions can be developed on host system 310 as code modules 215, compiled into object files 216, and downloaded to graphinok system 320.

In step 232, the currently executable file 226
An extension function of the form is called from the main program 213 running on the host system 3.0. Main program 213 is an executable file derived from object file 214.

In step 24, arguments of extension function 226 are passed from host system 310 to subsystem 320. To run Stenop 24, a host system 310 is provided with a communication driver 211 and a graph ink system 32.
0 is supplied with a command execution program 221. The details of the communication driver 211 will be explained below with respect to FIGS. are doing. Command execution program 221 is also described below with respect to FIG. The functions of both the communication driver 211 and the command execution program 221 include either the bucket method or the direct method of passing arguments, or both.

In the SteSob 25, the GraphInk subsystem 310 is used to perform the expansion function 226. If extension function 22
If 6 calls a core application primitive function 223, step 25 will involve executing that primitive function.

Stenobu 26 uses graphics subsystem 320 to load core primitive functions 222 , 223 , 224 into subsystem 320 . The above functions are always callable. Core primitive functions can be grouped into two basic function types: system primitives 222 and application primitives 223. System primitive functions 222 include functions for performing operations such as subsystem initialization, output, memory management, communication, and expansion. The latter type of system primitive function, the extension function, is
It includes a special program that is used in connection with loading and linking extension functions and is commanded separately as the dynamic linker 224. The application primitive function 223 is called and used from the main program 213 after being linked by the method shown in FIG. A specific example of the implementation of core primitive functions 222, 223, 224 can be found in the publication entitled "TIGA-340 Interface User Guide" (published by Texas Instruments Inc.).

FIG. 4 shows a series of software programs loaded into two different processors, such as processors 311 and 321 of FIG. 3 having memories 210 and 220. Although this discussion is directed to the use of stasok groups, other embodiments of the invention could use structures other than one stanok. Its essential feature is that an area of memory appears identical to both processors 311 and 321. The above structure could also be two shared memories. The shared nature of memory and memory contents allows function calls to be easily communicated and understood by both processors 311 and 321.

In general, FIG. 4 shows a first processor system 31
0 and linked with the application interface library 217
14 application programs are shown. The host system 310 simultaneously has a communication driver 211 and one stanok 4.
It is equipped with 14. Extension function definition 226 is loaded into memory 220 of graphics system 320 and accessed by command execution routine 221.

In addition, the graphics system 320 is 1 star sok 423
It is equipped with As described with reference to FIG. 3, communication buffer 323 provides space for passing data between processors. Argument handler 44
1a and 441b are used in connection with the Paquesoto form of the extension function.

The host graphics interface of the present invention is comprised of five basic parts: an application interface 417, a communications driver 211, a command execution routine 221, and a core primitive function used to install extension functions. If the paquesoto form of function definition is used, the fifth component of the interface will be the argument handler as shown as 441a and 441b.

The application interface 217 consists of a header file and an application interface library. Hesoda file defines core and extension functions 2
23, 226.

They simultaneously remap core and extension function calls to the appropriate entry point calls.

These entry point calls can be of the direct or packet type, depending on the parameter types passed to the function, as described above with respect to Susotep 12.

Application interface libraries are linked with application object files to form executable application files. The application interface library provides a means for application programs to pass information between communication drivers 211. The first function call made by an application is an initialization function. This action informs the communication driver 211 already resident in memory to pass the starting point memory of the population point JASOB table. This table is a list of addresses for each communication entry point provided by communication driver 211. Once the application interface 217 learns of the jump table access, it can jump to the appropriate entry point function called by the application.

The communication driver 211 is an application program 2
12 and sends it to the communication hub 323. The same Basofa 323 is the Graph Ink System 320.
accessible. The communication driver 211 is a terminal/stay resident (TSR) that runs on the host system 310.
) program, but TSR configuration is not necessarily a necessary feature. Communication driver 211 is specific to the graphics system 310 hardware, but can also be modified for different hardware by making the interface portable.

A characteristic of the communication driver 211 is that it has the ability to queue several command sequences, allowing a non-allocated buffering system. The basic form of the communication bus sofa 323 used by the communication driver 211 is shown in FIG.

The basic areas are a command bus sofa 510 and a data buffer 520, which are used in conjunction with the handshake routines executed by the communication driver 211. The predefined messages used to communicate between the post and the graphics hardware are:

GSP Communication messages between hosts GSP IDLE=0. GSP is waiting for commands.

GSP BUSr=1; GSP is executing a command.

G S P FINISIIED = 2; G S
P completed the command.

GSP tlNINIT =3. GSP has not been initialized.

GSI) Communication message HST between hosts
IDLE=0; Host is waiting for csp.

HST CMD = 1; The host is in the set-associate command ready state.

HST fllT=3: Host is expecting GSP initialization.

The -INIT command above is used during driver initialization.

Referring again to FIG. 5, message fields are used to process commands as follows.

(1) The host places the parameters of the function being called in the data bus sofa. At the same time, write the command identifier of this function into the command identification field. This identifier is either the direct method or bucket method, the module number corresponding to the DLM containing the function being called,
A function number identifying the appropriate function in the DLM is used to specify the type of population point call being executed. The host then inserts the I{ S T C M D message into the Message field.

(2) GSP executes the command by placing GSP BUSY in the GSP message field.

+31GSP is COM in the host message field
Clear MAND PENDING and enter CSP FINISIE in the GSP message field.
(4) The host checks the CSP FINISIIED message, clears it, and then reads some return Jib parameters or reuses the buffer.

The handshake is performed using two words.

One of the words is for the message from the host, and the other is for the message from the GSP. Host l. serves to clear messages from the GSP, and GSP clears host messages. This ensures a complete handshake without the need to exchange messages of the ``message acknowledgment'' or ``acknowledgment'' type messages. Because memory is used, the system is not limited to the number of command queues that can be active at one time.

Referring again to FIG. 4, command execution routine 221 is generally a software program that receives data from host system 310 and instructs graph ink processor 321 to perform graph ink processing. In the normal case, the command execution routine 221 uses the RA. It resides in M and is loaded after the software, but this is not a requirement. Similar to the communication driver 211, the command execution routine 221
It is possible to modify the interface so that it can connect to different hardware systems.

The command execution routine 221 runs on the graphics system 310 as a slave to the communication driver 211 and handles the GSP side of the host GSP hasidic shaking, receiving commands sent by the host and determining whether they are Pakesoto commands or direct commands. determines whether it is a legal command and calls the function called by it. For great mode commands, the command execution routine 221 encrypts the global pointer of parameter data for the function and calls the function. In the case of a packet command, the command execution routine 221 calls the argument handler 44lb.

The hunter 441b uses the same global data pointers as the direct method to rearrange the data as described above. Core primitive functions and assembly a3fi functions can be called in the same way.

The argument handler program included in the argument handlers 441a and 441b is a program that passes special arguments.
By removing the arguments from the host system 310's stanok 414 and passing them to the graphics system 320, and reassembling them after they have been passed, the graphics system 320's stanok 423 is created in a high-level format. To be able to run rank im tasks. In the embodiment of FIG. 4, the argument handlers reside on systems 310 and 320 and are designed for unidirectional communication. However, it should be understood that argument handlers can also be made symmetrical, thereby allowing two-way parameter exchange. Each argument hunter would then be able to both reassemble the buckets into one stanok and decompose them from the stanok. Furthermore, in the case of an integrated multiprocessor system, there could be one argument handler for all processors in the system. In Figure 4,
Argument handler 441a is linked to communication driver 211 and interacts with stack 414. Argument handler 441b
is linked to command execution routine 221 and communicates with stack 423.

For programming convenience, the interface can also include certain include files to avoid repeated definitions. These include files can be divided into two groups: That is, (1) files contained within source files designed to run on host system 3]0;
2) A file wrapped within a source file that runs on the GraphInk system 320. A first group of include files is part of the application interface 412, and a second group is included in the Graphinok system 32 of FIG.
Used to construct 0.

The include files of the host system 310 are as follows.

extend. l+ Call the extended primitive function.

graphics. h Define the data type used in the bucket method.

type4s. h For structure definitions used with respect to interfaces.

The include files 225 for the GraphInk system 320 are as follows.

gspcxtend. h External declaration of extended primitive functions gspglobals. b External declaration of all global variables gspregs. h graphics system register definition gspgraphics. h External declaration communication driver 211 and command execution routine 22 for all core primitive functions
As indicated above with respect to 1, a feature of the invention is that it is hardware dependent. This feature is achieved in part by an inquiry function that is part of the core primitive functions 224 and does not require modification of the communication driver 211 or command execution routine 221. The above functions allow application programs to disconnect from the graphics system 320 and restore information such as bint pixel depth, horizontal and vertical resolution, and the amount of random access memory on the graphics system. can. The application program can then scale its output to fit any display resolution. Table A contains two functions, geLconfig and set-co
One example of this hardware dependent feature is using nfig. The function gelconfig restores a structure containing all board and mode specific information. selco
The nfig function sets the graphics mode selected by the index passed to the default graphics mode. In that case, the board will have the following set-con
It remains until a call to fig is made.

Looking at table A for selconfig, if gra
If the phicsmode argument is valid, the function sets the new graphics mode and sets the appropriate GS
Initialize P Regisc. If the iniLdra-flag is true, the function initializes the drawing environment.

"Core primitive functions" are basic functions that are permanently installed in the subprocessor system and available for loading at all times. These core primitives can be grouped into two basic functional types: system primitives and aggregation primitives. System primitives include functions that perform operations such as subsystem initialization, output, memory management, communication, and expansion. The latter type of system primitive function, an extension function, is used in connection with the method of the invention and will be discussed in more detail below.

A general purpose primitive function, if linked using the present invention, is called and utilized by an application program running on the host.

Although the following description of the present invention is primarily directed to the C programming language, the programming for implementing the present invention is not specific to the C language and is described in the text. Programming structures and functions can be easily translated into any high-level language. The actual languages and programs required to implement the invention will depend on the particular system on which the invention is implemented. The particular program is believed to be within the ability of a programmer of ordinary skill in the art after reviewing the present invention.

The premise of the present invention is that a subprocessor system is best utilized when it has extension functions that can be loaded, linked, and used independently of its core primitive functions. According to this premise, the present invention can provide a method of incorporating extension functions with programming of other multiprocessor systems. The above method can implement a software mechanism that dynamically links various functions used in one application program, regardless of when or where the functions are coded.

FIG. 6 illustrates the method of the present invention from the perspective of a programmer who desires to develop extension functions for a subsystem processor. These extension functions consist of a group of functions that are ultimately called within an application program to perform certain tasks for the user. Basically, the Stesob creates a set of extension functions and an address reference section for each function. Linking an extension function with a section reference creates a load module that is partially linked into existing code, allowing references to be left to other code to be decomposed at runtime. .

Regarding the linking and loading steps of the present invention, the following description relates to processes and structures common to software programming to perform these tasks. In particular, it is assumed that the linker creates object files in a common object file format, a format well known in the art. This formatter 1 favors modular programming in which each module has small blocks of code and data called sections. A section is the smallest relocatable unit of an object file and will eventually occupy contiguous space in memory into which it is loaded.

The COFF format allows extension functions to be written in one of a number of high-level languages, or in assembler language. However, it should be understood that COFF is only one form of object formanote that is sufficient to create a relocatable, partially linked function module.

In step 111, a module of program code including extended functions is created. Typically, this set of functions will perform the specified task of a particular application program, whatever function is needed. In step 11, an extension function is coded, which can be executed in any form that the extension function can be called from an application program running on the host and executed by a subprocessor. Such a series of methods can utilize as a primary requirement that the function definition allows the actual parameters of the function to be passed from the host to the subprocessor, and that any return value can be returned to the host.

Examples of such methods are the Paquesoto method and the Direct Access method, both of which are described in co-pending applications. ，(
``Software Partitioning in Multiprocessor Systems'', ``Extended Software Functions for Multiprocessor Systems'') After functions are defined, they are collected and compiled or assembled into a fixed file such as a set of common object files. Linked to a loadable code of the form. One example of the results of Stesopl1 is ■yfuncs. A file called obj, +wy-funcl and Ily-func2.
Contains two functions.

An advantage of the present invention is that modules of extension functions can be created by the same programmer who creates the application programs that use them. Therefore, a module to be loaded and used during the execution of a particular application need only contain the functions required by that application. Furthermore, the method of calling the function and parameterizing it can be selected by the programmer according to any special techniques required for passing parameters between processors.

In step 112, a reference section is created and address references are declared for each extension function in the module created in step 11l. An example of SteSob112 is the following programming, my-fun
Two functions are cited: cl and my-func2.

;External citation゜globl-my-funcl+ -my-func
2; Start section declaration ・sect ”.EXT' ・long 劃y-funcl ：Number of commands in the module O long-my-func2 ：Number of commands in the module 1 ・text ：The number of end section commands is specified in the specific instruction Declare a function in the root module that should be defined in the root module.This provides a means of referencing the function.In particular, the command number of one function can be included in a function call in the application program that calls the function. The cited section can be compiled or assembled into, for example, ext.obj.
A common object format file such as 1 is generated.

In the STEP 113, the module created in the STEP 111 is partially linked with the section created in step 112 to form one load module. Although this linking step separates reference values between functions within a module, it should be understood that the module may include functions that reference or are referenced by functions outside the module. If an external citation exists, the link is only partial and the citation is unresolved.

Partially linked files must have relocation information and symbolic information. Some linking is related to the formation of output sections and not to their distribution. All allocations, bindings, and memory directives are performed at runtime on the next link.

An example of partial linking is when a module has a function that calls a core primitive function. The unresolved quotation is outside of the module already stored within the subprocessor system, and the quotation function has no address for it. An essential feature of the linker used in step 113 is that it allows calls to functions to be made that are unresolvable until runtime. Figure 2,
As described below with respect to FIGS. 3 and 4, when a function is loaded into the memory of the subprocessor system,
These citations will be resolved. The dynamic linker resolves the call by inserting the address into the code.

The following is an example of a command for running Stenop 113 using a computer with one phosphor.

In that case, the two functions defined in step 111 and the section created in step 112 are to be linked. As an example, the linker is invoked with the following command:

link LOAD. MOD ayfuncs. o
bj ext. objThe ooze is LOAD. MUD
Step 1 with a relocatable load module entitled
This is a combination of object modules created by 11 and 112.

The load module can then be used in a series of different ways. That is one of the advantages of the present invention. For example, modules can be supplied to other modules, and modules can be linked into the main program or loaded into subsystems to interact with core primitives. Instead, the same user can use load modules to develop application programs for multiprocessor systems. Thus, as shown in FIG. 4, the next step may be l14a to load the module into the subsystem, or step 114b to link the module to the application program. From the end user's perspective, the load module resides in the user's host system memory in a partially linked state and is ultimately downloaded to the subprocessor system and specified as described below with respect to Figure 2. can be used with other application programs.

Figures 2, 3, and 7 illustrate the second aspect of the invention, a method for using a computer to load and dynamically link extension functions into a multiprocessor system. The above linking is unreliable in the sense that the addresses of other functions that the extension function calls are unknown when the extension function is created. These addresses remain unknown until the application program is run.

The steps of the dynamic download method of the present invention are shown in FIG. Generally speaking, the above method connects host processor system 310 to sub-processor system 320.
The process consists of loading a set of extension functions into a file and linking any unresolved extension function citations.

First, in the steps 141-43, the linker 224 stores the two files it needs, namely the symbol table file 225 and the previously linked object file 216 currently in the memory 210.
- Check that the loaded module 215 exists.

The symbol table file 225 is maintained by the symbol table function in the core primitive function B 222 and stores symbol information representing the functions already loaded into the memory 220 of the subprocessor system 320 and the associated memory address for each function. do. Thus, if previously created load modules are used, they need to be loaded and their symbols and addresses placed in the symbol table file 225.

Thus, prior to performing the method of the present invention, symbol table file 225 represents functions external to load module 215. That is, they are load modules 215
Not defined within. An example of a symbol table function that performs this task is the following C language function. inL create. ．． ．． symbol-file(
name) char far ” name ; However, name is the path name of the file containing the function.

The symbols and their respective absolute addresses are stored such that they can be accessed during subsequent invocations of the loader. To ensure the integrity of the symbol table file 225, the dynamic linker 224 makes a restricted call to the command execution routine 221, which uses special core system primitives to access subprocessor system memory. 220 and the status of the previously installed module. The purpose of this SteSob is to determine whether a discrepancy exists between such modules and the module symbols in the symbol table file 225. If present, symbol table file 225 is adjusted accordingly.

If not, an error message is communicated to the user.

At step 144, linker 224 obtains the required memory size for the desired load module object file 216. The linker calls a special allocation function from the core system primitives to obtain a memory block large enough to store the load module. An example command representing such an allocation function is as follows.

long alloc (size) long size; however, long size is the size of the module expressed in bytes. This function allocates a block of subprocessor system memory 220 of the specified size and restores a pointer.

In steps 145-46, dynamic linker 2
24 performs its primary task of combining object files to be executed by sub processor system 320 into executable image file 226. Dynamiso linker 224 is executable file 22
6, the object file 216 is loaded into the memory 220 and external references are resolved. In doing so, the above linking force
and a load file 216 as input. In particular, the linker 224 relocates the desired COFF section into the subsystem's memory map. In order to resolve references to previously unresolved external functions, that is, functions that were not defined within the load module 215, the dynamic linker 224 uses the symbol table file 225.
to find the symbol representing that function. after that,
Dynamisolinker 224 replaces references in load module 216 with the address of the referenced function. In this manner, dynamic linker 224 links all extension functions listed in the cited section of load module 216 to other code loaded within subprocessor system 320. Similarly, the dynamic linker 224 transfers symbols representing functions defined in the load modules 2 1 6 to the symbol table file 22.
By adding "ζ" to "5", the subsequently installed load module can access the load module 216.

In general, the programming method for linking step 146 uses programming techniques similar to those of other dynamic linking tools used in single processor systems. Needless to say, those systems do not require the extra task of correlating two processor systems together as is done by the present invention. After load module 216 has been loaded into memory 220 in step 147, dynamic linker 224 utilizes information in the reference section of the load module to enable functions within the module to be called by application program 212. . In particular, the linker 224 constructs a table (not shown) representing extended function addresses used by the command execution routine 221.

In step 148, the linker 224 determines whether there are any functions currently loaded into the memory 220 that are not needed by the application program. If present, these functions are discarded from active memory. Finally, in step 149, the dynamic linker 224 returns the module identifier to the application program. The module identifier is used when the application program 212 calls extended functions, and calls those functions. As an example, the module identifier may be the same as the number of modules in the reference section discussed with respect to FIG. Stesob 148 is useful when one or more modules are to be loaded onto subprocessor system 320.

The linking shown in FIG. 2 is part of the installation process, during which the user uses a computer to call an installation procedure which, in turn, preferably calls the linker 224. . An example of an installation command is the following function written in C language.

int installm(1++-nan+e)c
har for “lm-nan+e; However, lm-
name is the load module name. Following the steps above, this function installs any load module specified by the load module name and restores the module identifier.

Once the load module 216 is downloaded and linked, runtime processing of the multiprocessor system calls for the use of certain types of parameter passing techniques between the two processor systems. As discussed above with respect to FIG. 1, this can be done at the programming stage with special function definitions and calls designed so that argument data and return data are transferred between the processor systems and understood by both processors 311 and 321. can.

As mentioned above, one or more load modules 216 can be loaded, each receiving its own module identification number. By programming the dynamic linker 224, an identifier that identifies both the module and the extension functions within the module can be restored. One example method to enable identification is to give each load module 215 a module number according to the order in which it is installed. This identifier is used whenever a function within the module is to be called from the program by connecting the function number, as given in step 112 of Figure 6, to the module identifier. . In the case of the C language, this can be done with a per-focus OR operator. The linking will then include all load modules.

In an alternative embodiment of the invention, interrupt service routines are added to the multiprocessor system for use by application programs rather than extension functions. The method shown in FIG. 1 is essentially the same except that the load module stores the interrupt service routine. The latter is
Called as soon as an interrupt is received via the subsystem's interrupt handler. In step 12, a reference section is created containing two populations for all interrupt service routines in the module. These populations specify address references to interrupt service routines and the number of interrupts for that routine.

For example, if two routines, ++y-infl and my-inf2, are stored in the temp11 module, the section declaration would be as follows.

;External reference・globLmy-infl, -IIIy-inf2
;Start section declaration・secf ".ISR";ong -stop y-infl ong -my-infl ong 1;number of interrupts 1 0ng -s+y-inf2 ong 2;number of interrupts 2 ・text i Add end section interrupt service routine The associated load time method is also essentially the same as that described above with respect to FIG. Another additional consideration is that the priority information associated with each routine can be retrieved by accessing the module's destination list.

Thus, interrupt service routines chained to the same interrupt level can be specially accessed or referenced.

Regarding the above description, the following items are disclosed.

l. A method used in a multi-processor system that includes both a host processor system and a graphics processor system and for extending functions called by a main program running on a host and executable by the graphics processor system. , create a subprogram to be executed by the above graphics processor, define the above subprogram so that its argument can be passed to the above graphics processor system at runtime, and perform the following for the subprogram in the above main program: declare a call containing the parameters used by the subprogram, compile and run the subprogram on the graphics processor system, load the subprogram into the graphics processor system, load the subprogram into the graphics processor system, load the subprogram into the graphics processor system, load the subprogram into the graphics processor system, Linking to other code loaded on the processor system.

2. In a method using a multiprocessor computer system comprising a host processor system and a graphic processor system to execute extended functions called by a main program running on the host computer and executed by the graphic processor. , Load the extension function into the graphics processor system, call the extension function from the main program, pass the argument of the extension function from the host system to the graphinoku system, and execute the extension function by the graphics processor. Said method comprising steps of carrying out.

3. A programmable host processor in a multiprocessor computer system in which execution of one software program on a first processor allows the program to call specified extension functions to be executed by a second processor. and a memory accessible by the host processor, a programmable graph ink processor, and a memory accessible by the graphic processor, wherein the host processor and the graphic processor are programmed by a software interface, The system wherein the extension function is dynamically downloaded to the graph ink processor memory and executable by the graph ink processor.

4. In a software interface for use with a multiprocessor computer system comprising a host processor system and a graphics processor system and executing extension functions called by a main program running on the host system and executed by a graphics processor, A linker that downloads and links the extension function to other code headers loaded on the graphics processor system, and a command that receives arguments from the host system, identifies the extension function, and calls the extension function. an execution routine, and a set of tools that combine the command execution routine and a linker, and the interface dynamically downloads extension functions and receives their arguments from the host processor system. 5. A method for adding an extension function to be loaded into the memory of a subsystem processor in a multiprocessor system comprising a host processor and a subprocessor, comprising: programming a load module comprising at least one function to be executed by the subprocessor; Create a citation section for the above module that contains relocatable address citations to the load module, and partially link the above load module so that all internal citations are resolved and external citations are left unresolved so that the load module The method further comprises the steps of: enabling complete linking at runtime.

6. In a method used in a multiprocessor system in which an extension function to be executed by a subsystem processor is loaded so that the same function can be called from an application program running on a host processor system, allocating memory for a load module containing the definition of the extension function, loading the load module into the subprocessor system, and linking the load module with other code to be loaded into the subprocessor system. The above method, which is more powerful than the above step, causes unresolved citations of the above load module to be resolved by.

7. a programmable host processor; a memory accessible by the host processor; The sub-processor downloads the extension function loaded into the memory of the host processor to the memory of the second processor, and dynamically links the extension function to other code loaded on the sub-processor. said system programmed to do so.

8. Used in multiprocessor systems to link extension functions to be executed by a subsystem processor to other code in the subsystem processor during loading of an application program running on a host processor system. 2. An entry point that receives a call to start execution in response to the loading of the application program described above, an instruction that acquires the memory size of the load module that includes the extension function, and the above-mentioned host. an instruction for relocating the load module from the memory of the subprocessor system into the memory of the subprocessor system; and an instruction for resolving unresolved references to functions external to the load module; and is constructed into a syntax and statement executable by the subsystem processor.

9. An interface used with a multiprocessor computer system having a host processor system and a graphics processor system allows extension functions to be developed on the host system or another system and then loaded into the graphics processor system. ．． The above interface is made up of software resident on the host system side and the graphics system side, and operates at runtime so that the above functions can be called from the main program running on the host. The function's arguments are passed to the graphics system so that the function is executed by the graphics processor.

[Brief explanation of drawings]

FIG. 1 is a flow diagram illustrating the steps in extending the functionality of the GraphInk subsystem; FIG. 2 is a flow diagram illustrating the steps for using a computer system having a host processor and a GraphInk processor; FIG. Figure 4 is a diagram showing a software interface used with the multiprocessor system of Figure 3; Figure 5 is a diagram showing the software interface used with the multiprocessor system of Figure 3; Figure 6 shows the structure of a communication buffer used for communication between graphics processors; Figure 6 shows the steps for creating a module that stores extension functions that are also used in subprocessor systems. FIG. 3 is a diagram illustrating the steps of loading a function from a first processor to a second processor and linking unresolved references to Guinamisoku; 212...Application program, 211...
- General f3 dryer, 216... Object file, 215... Extension function, 233... Core application primitive function, 224... Dynamiso linker, 2
25... Include file, 222... Core system primitive function, 423... Stack, 323...
Basofa ● Table AI get-config syntax typedef struct { summer ong drsp-pHch ; shorL d
isp-vres ; short dispJres
；short screen-wide ；short
screenJigh: short disp-
psize ; long pixelLmask ; short palet-gun-depLh il
on paleLsize ; short pa
let-inset; short nu Rinichi pa
ges; short nun-offscrn-a
reas; long wksp-addr; long wksp-pitch:} MODE
INFO ; typedcf struct { long comm-buff-size ; shor
short curve
nt-mode Slong program-mem
-start ;1oB progra+i-mem-
end ;long display-meal-st
art ;long display-mem-end
;long stack-size ;long shared-sew-size :cha
r for “shared-host-addr;
PTR shared-gsp-addr ;MODE
INFO tmode;)coLiverXG;void get-config (config)C
ONFIG far” config; The file size in the above structure definition is as follows. Must not overflow. This is useful for instructions that do not check the size of the data downloaded to the graphics processor.Extended mode numbers for graphics boards that switch between different display settings Table A2 curren lmode: Number of modes corresponding to the current operation mode program-mem-start: Program memory start address program-mem-end: Program memory end address display-meIII-start: Display memory start address display-meIII-start: Display memory start address display-meIII-start: Display memory start address End address stack-size: Default stack size sh
'are-mem-size: Size in bytes of shared memory available to the application to use shareJost-addr: If share-m
If eIll-size is non-zero, it is the starting address in host memory of shared memory. share4sp-addr+ if share-+a
If em-size is non-zero, it is the starting address of the shared memory GSP memory. djsp-pitch: display pitch, i.e. bisodic display of the line-to-line difference between two scanning lines disp-vres: vertical resolution of scanning lines dispJr
es: horizontal resolution of pixels screen-wt
de: Width and height of the monitor (in millimeters) screenJight: disp-psfze: Pixel size pixel
s+ask: Mask of bits used for one pixel. It will usually contain a value of 2 to the power of (dis-psize-1). Indicates that all bits of pixel data are valid. pallet-gun-depth: Number of bits per gun in Valesotopalelsize: Number of population in pallet pa Ie
For most systems, this field will be zero. However, for systems that store palettes in the frame buffer, this is the offset from the start of the scan line to the first pixel data. Table A3 nun-pages: Number of display pages in multiple buffer system num-offscreen: Number of available off-screen memory blocks. If non-zero, it is used to allocate space for off-screen arrays. The above array has another function (geloffscreen
．． ) from the GPS. wksp-addr: Starting linear address in memory of off-screen workspace area wksp-pitch: Pinch of off-screen workbase area. If pitch is 0, no off-screen workspace is allocated. Set-contig syntax int seLconf)g (graphics-m
ode+ init-draw) short grab
hics-mode; short inildraw
; Figure 4 Figure 5 Figure 6 Figure 7

Claims (1)

[Claims] (1) A method used in a multiprocessor system that includes both a host processor system and a graphics processor system, and for expanding functions called by a main program running on the host and executable by the graphics processor, comprising: Create a subprogram that is executed by , define the above subprogram so that its arguments can be passed to the above graphics processor system at runtime, and specify the parameters used by the subprogram for the subsystem within the above main program. compiling and executing said subprogram on said graphics processor system, loading said subprocessor onto said graphics processor system, and causing said subprogram to be loaded on said graphics processor system; Said method comprising the steps of linking to.