JP3051438B2 - How to give enhanced graphics capabilities - Google Patents

Description

Description: FIELD OF THE INVENTION The present invention relates generally to computer processing, and more particularly to a software interface for a system having both a host processor and a graphics processor.

2. Description of the Related Art Computer systems using graphic displays today have a different set of architectures. Some systems include a host processor and a display controller. These are essentially hardwired bitmap systems,
It is required that the host processor performs all graphics processing. However, the disadvantage of such a system is that
As the demands placed on graphics, such as resolution, increase, the processing burden on the host processor also increases, resulting in reduced processing speed.

As an alternative to the display controller, other systems delegate the responsibility of graphics processing to the graphics processing subsystem. Some such systems rely on the hardware performing the graphics function exclusively. Other graphics processing subsystems use programmable graphics processors to allow programmers to add functionality.

While the graphics processor subsystem allows for high resolution and fast execution, many disadvantages of such a system, whether hardwired or programmable, are that it is not easy to extend them. It is. Even subsystems with programmable processors have difficulty integrating the host system with its application programs, and for this reason they are essentially fixed function systems.
Since such systems strive to be as versatile as possible, their functionality comes at the expense of efficiency in order to add too much functionality to the subsystem, thus reducing the so-called "reincarnation" effect. Tend to have. Another problem with systems that have a fixed set of features or are difficult to scale is that they cannot keep pace with the graphics software for which new graphics algorithms are constantly being developed. .

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

Many standards, such as CGA, EGA, and VGA, are directed toward a single processor system rather than a graphics sub-processor system, and they have succeeded in interfacing software and graphics hardware. However, providing an interface between the host and the graphics system has not been successful.

Therefore, there is a need for a graphics subsystem interface that can provide scalability without sacrificing efficiency. In addition, mechanisms for achieving scalability need to provide an interface that allows both application programmers and hardware manufacturers to target their products. The interface must be at a sufficiently high level to facilitate standardization, but at a low enough level to facilitate processing speed.

[Problems to be Solved by the Invention] [Means for Solving the Problems] According to one aspect of the present invention, a function executed by a graphic processor subsystem but called from a main program running on a host processor system is described. How to extend. The basic steps of the above method are to create a subprogram implemented by the graphics processor, define the subprogram so that its arguments can be passed at runtime, and compile or assemble the subprogram for the graphics processor. Loading the subprogram into the graphics processor and linking the same subprogram to the previously loaded function.

In another aspect, the invention relates to a method of using a graphics subsystem in a host computer system. The method provides a set of primitive core functions using a graphics subsystem, downloads extended functions to a graphics subsystem using a host system, and passes arguments from the host system to the subsystem using a software interface. It consists of the basic steps of passing and further executing the extension and core functions using the graphics subsystem.

From a hardware standpoint, the present invention is a multiplex that executes a single software program on a first processor so that the program can call a designated function to be executed by a second processor. Processing computer system. The system comprises a programmable host processor system and a programmable graphics processor system, which uses a software interface that allows extended functions to be downloaded and executed on the graphics processor.

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

A technical advantage of the present invention is that it makes the graphics subsystem efficient and easily scalable.

Execution speed is optimized because software developers can create custom sets of graphic functions that best fit their applications. Another advantage of the present invention is that it can standardize the methods used to extend the functionality of the graphics subsystem. The present invention provides an interface to both hardware manufacturers and software developers for their products.

Embodiment The hardware environment operated by the present invention is, in general terms, a multi-processing computer system having at least two processors, a host processor and a graphics processor. Applications for such systems are computer-aided design (CAD), desktop publishing, image processing, and high-resolution graphics processing such as presentation graphics. The hardware aspects of the present invention will be described in detail with reference to FIG.

One of the advantages of the present invention is that the main software program, which is scratched in one language, can be run on the host system, but can call the named functions to be executed by the graphics processor. Therefore, implicitly, the processor used in the present invention can be programmed in a high-level language, which can be the same language for both processors. Thus, each processor interacts with its own instruction set and compiler to create the processor's low-level language.

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

The core primitive functions are always available from the graphic processor. These core primitives include a few basic graphics utility functions, but also provide functions for system initialization, graphics attribute control, memory management, screen clear, cursor manipulation, communication, and expansion. . Extension functions provide graphics functions that are loaded as needed and used by application programs.

The following description of the software aspects of the present invention:
It mainly targets programs written in C language. However, the programming environment in which the present invention operates is not specific to the C language, and the programming structure and functionality described in the text can be easily translated into any high-level language.

That particular implementation is considered to be within the capabilities of a programmer of ordinary skill in the art, upon review of this specification. The present disclosure is provided to implement the present 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 assembled rather than compiled. Therefore, "assembly" can be replaced with "compile" in this explanation.

The "users" of the present invention can be various persons who provide various parts of one multiprocessing system. For example, the user may be a software developer who wants to add an extension function to the application or driver being created for use on the system. Alternatively, the programmer may simply provide an extension function for use by another programmer. Alternatively, a hardware manufacturer, such as a board manufacturer, can program the functions for the graphics system. Further, the user may be a person who actually executes a program using the interface. Further, depending on the calculation method and the nature of the program, the user may be other software running on the computer.

For the purposes of the present invention, a subprogram that a user wishes to add to a multiprocessing system will be referred to as an "extended function". The system that executes the main program will be referred to as a “host processor system” or “host system”. At that time, the processor is referred to as a “host processor”.
The system on which the extension functions are executed is a "graphics processing system", the processor of which is referred to as a "graphics processor" or a "graphics system processor" (GSP).

FIG. 1 is a block diagram illustrating the basic steps of creating an extension function for use with a multiprocessor system, the system including a host processor and a graphics processor. Using this method,
One programmer can create graphic functions that are not included in the core primitive functions. These extension functions are built into the Dynamic Load Module (DLM) and used by the end user, who typically downloads them to the graphics system at 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 sub-processor suitable for execution by the graphics processor, define the sub-program so that its arguments can be passed during execution, compile for the graphics processor, and Is linked to form a DLM. Finally, the DLM is downloaded to the graphics processor, where it is linked to existing sub-processor functions and core primitives.

In step 11, the programmer develops a subprogram having at least one, usually a set of functions, suitable for execution by a graphics processor. These functions can be written in a high-level language or an assembler language. One of the features of the present invention is that the extension function is described in the same language as the main program, and can be compiled or unseated for a graphic processor.
Function constants are used throughout the text, as well as other computer programming used to implement the invention.
Let's call it the "code".

In step 12, the subprogram is defined such that the subprogram arguments can be passed to the graphics processor during runtime. Step 13 is related to step 12 in that the invocation of the subprogram in the main program must be expressed in a form understandable by the definition of step 12. There are at least two different ways to perform steps 12 and 13. These methods are described in "Software Partitioning in Multiprocessor Processors" (US Pat. No. 5,216,095).
US Patent No. 6,098,056) and "Extended software call system for functions on other processors by means of communication buffers"
No. 5,404,519). U.S. Pat. No. 5,216,095 describes a packet method for adding extension functions to a multiprocessor system, and U.S. Pat.
No. 519 describes the direct method.

The packet method is designed so that the graphics system can be extended to minimize the amount of programming effort on the part of the user. According to this method, a function written in a high-level language such as the C language can be called from a running main program on a host system and executed by a graphic system. In fact, as described in the above-mentioned U.S. Pat. No. 5,216,095, the packet method allows one user to move a function running on a host system to a graphics system and call it with the same parameters. Can be. In the packet method, function arguments are sent in packets describing the size and type of data to be sent.

The direct method does not place arguments on the stack unlike the packet method. The function is called by the graphics subsystem with one argument. The above argument is a pointer to the communication buffer, where the host downloads the function argument. The function includes an additional load, which directs the graphics processor to get the parameters from the buffer and match them with local variables. The above function is called from the main program using the direct entry point method. The entry point determines the format of the function arguments and the return condition. These direct entry points are detailed in U.S. Patent No. 5,216,095. Step 14 compiles the subprogram for the graphics processor. If the subprogram is written in an assembler language for a graphic processor, it goes without saying that step 14 assembles the code. Compiling and assembling techniques are well known.

Steps 15-17 call for a partial link and load of the subprogram. The execution of these steps will be described later with reference to FIG. 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 will be referred to as "dynamic downloading" in the text.

Step 15 partially links the subprograms to form a DLM, according to the methodology of the load time linker described below with reference to FIG. This partial linking step resolves all references to variables and functions within the subprogram. Those variables and functions externally referenced by the subprogram remain unresolved. Step 16 loads the DLM into the graphics system. It is desirable that the loading be performed during runtime so that the application program can be marketed separately from the hardware used with it. Step 17 completes the linking of the DLM and resolves all external reference variables and functions residing in the sub-processor system. These resident functions will typically be core primitive functions, but may be other extension functions loaded by the method of the present invention. During the software development phase, steps 16 and 17 can be performed on a special test graphics subsystem, rather than on the graphics subsystem where the application will ultimately be used. Nevertheless, the test system is assumed to comprise a graphics processor and an emulation, and the method is basically the same.
End-users should also be aware that steps 16 and 17
Can also be performed.

FIG. 2 illustrates a second aspect of the present invention, a method of using a graphics subsystem in a host computer system. FIG. 2 is in the form of a system flow diagram, wherein the steps of the method are associated with the software programs that execute them. As a whole, FIG.
Is composed of software resident in the host memory 210 and the graphics memory 220 together. The software resident in memory 210 is a communication driver 211, an application program object file 214, and an extended function object file 216, the latter being loaded into graphic memory 220 as discussed below. Two
Components numbered 12 and 215 indicate that the application file 214 and extension function DLM file 216 have been compiled from source code modules. One of the application files 214 is a main program 213. The software resident in the memory 220
A command execution routine 221, an executable file 226 for defining an extended function, an include file 225, and core primitive functions 222, 223, and 224. These components are further described in connection with FIG.

The method of FIG. 2 is for use on a multi-processing computer system that includes communication means between processors. Therefore, it can best be understood by referring to FIG. 3, which is a block diagram of such a system. The system is a host processor system 310
And a graphics processor subsystem 320. Preferably, the graphics system 320 is configured so that the graphics processor 321 runs in parallel with the host processor 311 to calculate and process graphic information, while the host processor 311 can continue processing other processing tasks.

Host processor 311 is Intel 80286 and 8038
It is usually optimized for peripheral control such as six processors. While 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 may be implemented using various processors and operating systems. The memory 210 associated with the host computer 311 is a random access memory (RAM)
Is provided, the memory can be made accessible to a program instructing the processing.

Graphics processor 321 is designed for graphics processing and is programmable. One example of such a processor is the Texas Instruments 34010.
A graphics processor, which extends the set of graphics processing instructions, along with hardware for display device control and refresh operations.
It is a bit microprocessor. The memory 220 includes a RAM memory so that the graphic processor 321 can be used.
Can store a program for instructing how to process graphic information in the same memory.

The communication means between the two processors is a bus
This is realized by 330 and the communication buffer 323. Bus 330 is bidirectional and provides data paths and control lines.
The communication buffer 323 is used for both processor systems 310 and 32
0 and is described in detail with respect to FIG. Other heartware fabrication of the communication means is also possible, in which case the primary requirement is that each processor 31
1 and 321 can access the communication buffer 323, which is used for message data for handshaking between processors, identification space for identifying the function being called, command arguments and additional data. In a data space for passing The form shown in FIG. 3 is only one of many means for enabling communication between processors, and other means can be easily developed. Further, while 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 peripheral operations, specifically, a display 340,
0, and works with input devices 360 such as keyboards and mice. An I / O circuit 313 is used to communicate information between these input / output devices and the other host system 310 via the host system bus 314 in an appropriate manner. Input device 360 allows a user to interact with host processor system 310. The display 340 is connected to the graphics processor 32 through well-known control and input / output techniques.
Connected to 1.

Referring again to FIG. 2, the above method is used for DLM file 2
A basic step configuration that downloads an extension function from 16 to the graphics subsystem 320, calls the extension function from the main program 213, passes arguments of the function from the host system 310 to the subsystem 320, and executes the extension function Is done. The core primitive functions are loaded into the graphics subsystem 320 before the main program 213 calls a function resident in the subsystem 320.
This allows loading and linking to be performed by the graphics processor 321 and
Extension functions allow you to call certain basic graphic tasks.

Since the method of FIG. 2 does not need to be performed until one application program is executed, the method 2 is referred to as a runtime method. However, it should be understood that the application program can be re-executed without loading and linking the extension function again.

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

In particular, the extension function by loading and linking in step 22
DLM 216 is loaded into memory 220 and linked to other extension functions and core primitives at run time to form executable 226. The dynamic linker 224 uses a symbol table file that is part of the include file 225 to create an executable file 226 containing the extended functions and identify functions for the rest of the system. One of the features of the present invention is that an extension function can be developed on the host system 310 as a code module 215, compiled into an object file 216, and downloaded to the graphics system 320.

In step 23, an extension function in the form of a currently executable file 226 is called from the main program 213 running on the host system 310. Main program 2
13 is an executable file derived from the object file 214.

In step 24, the argument of the extension function 226 is set to the host system 3
Passed from 10 to subsystem 320. To perform step 24, the host system 310 is provided with a communication driver 211 and the graphics system 320 is provided with a command execution program 221. The details of the communication driver 211 will be described below with reference to FIGS. 4 and 5, but in short,
The communication driver 211 stores a program used for communicating between the host system 310 and the graphic system 320. In addition, the 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 packet method or the direct method of passing an argument, or both. In step 25, the extension function 226 is executed using the graphics subsystem 310. If the extension function 226 calls the core application primitive 223, step 25 will involve the execution of that primitive.

In step 26, the core primitive functions 222, 223, 224 are loaded into the subsystem 320 using the graphics subsystem 320. The above functions are always callable. Core primitive functions can be grouped into two basic function types: system primitive functions 222 and application primitive programs 223. The system primitive functions 222 include functions for executing processes such as subsystem initialization, output, memory management, communication, and extension. The latter type of system primitive function, the extension function, loads the extension function,
It includes a special program that is used in connection with linking and that separately orders as dynamic linker 224. The application primitive function 223 is called from the main program 213 and used after being linked by the method of FIG. Specific examples of implementations of the core primitive functions 222, 223, 224 can be found in a publication entitled "TOGA-340 Interface User Guide" (Texas Instruments).

FIG. 4 shows the processor 31 of FIG.
FIG. 4 shows a series of software plans loaded on two different processors, such as 1 and 321. FIG. Although this discussion is directed to using stacks, other embodiments of the present invention could use structures other than the I-stack. Its essential feature is that an area of memory looks identical to both processors 311 and 321. The above structure could also be a single shared memory. Due to the commonality of memory and memory contents,
The function call can be easily updated by both processors 311 and 321 and can be understood.

In general, FIG.
Shows an application program in an executable code format 214 that is loaded into the application program and linked with the application interface library 217. Host system 310
Has a communication driver 211 and a stack 414 at the same time. The extended function definition 226 is loaded into the memory 220 of the graphic system 320 and accessed by the command execution routine 221. The graphic system 320
Has one stack 423. As described with respect to FIG. 3, the communication buffer 323 provides space for passing data between processors. The argument handlers 441a and 441b are used in connection with the packet form of the extension function.

The host graphic interface of the present invention includes an application interface 417 and a communication driver 2
11; a command execution routine 221; and five basic parts of a core primitive function used to install an extension function. If a function-defined packet form is used, the fifth component of the interface will be an argument handler as shown as 441a and 441b.

The application interface 217 includes a header file and an application interface library. The header file defines the core and extension functions.
See 3,226. They also remap core and extension function calls to appropriate entry point calls at the same time. These entry point calls may be of the direct or packet type, depending on the parameter type passed to the function, as described above with respect to step 12.

The application interface library is linked with the application object file,
Form an executable application file. The application interface library provides a means for application programs to pass information between communication drivers 211. The first function call made by the application is an initialization action. This action informs the communication driver 211 already resident in the memory that it will pass through the entry point memory of the entry point jump table. This table is a list of addresses of each communication entry point provided by the communication driver 211. Once the application interface 217 knows about the jump table access, it can jump to the appropriate entry point function called by the application.

The communication driver 211 is the application program 212
And sends it to the communication buffer 323.
The buffer 323 can access the graphic system 320. The communication driver 211 is preferably a terminal and stay resident (TSR) program that runs on the host system 310, but the TSR configuration is not a necessary feature. The communication driver 211 is specific to the hardware of the graphics system 310, but can 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 some command sequences, enabling an unallocated buffering system. The basic form of the communication buffer 323 used by the communication driver 211 is
As shown in FIG. The basic areas are a command buffer 510 and a data buffer 520, which are used together with a handshake routine executed by the communication driver 211. The predefined messages used to communicate between the host and the graphics hardware are as follows:

GSP_Host communication message GSP_IDLE −0; GSP is waiting for a command.

 GSP_BUSY = 1; GSP is executing a command.

 GSP_FINISHED = 2; GSP has completed the command.

 GSP_UNINIT = 3; GSP has not been initialized.

Communication message between GSP_host HST_LDLE = 0; host is waiting for GSP.

HST_CMD = 1; host is ready for setup command.

 HST_INIT = 3; Host is expecting GSP initialization.

 The _INIT command is used during the initial stage of the driver.

Referring again to FIG. 5, the command is processed as follows using the message field.

(1) The host places the parameters of the function being called in the data buffer. At the same time, the command identifier of this function is written into the command identification field. This identifier identifies the type of entry point call being performed using either the direct method or the packet method, the module number corresponding to the DLM containing the function being called, and the function number identifying the appropriate function in the DLM. specify. After that, this host is HST_CM
Set the D message in the message field.

(2) The GSP sets GSP_BUSY in the GSP message field and executes the command.

(3) GSP is COMMAND_P in the host message field.
Clear ENDING and set the GSP_FINISHED message in the GSP message field field.

(4) The host checks the GSP_FINISHED message, clears it, and then reads some return parameters or reuses the buffer.

The handshake is performed using two words. One word is for messages from the host and the other is for messages from the GSP. The host clears the message from the GSP, and the GSP clears the host message. This allows a complete hadshake to be confirmed without having to exchange messages of the type "message acknowledgment" or "acknowledgement". 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, the command execution routine
A software program 221 receives data from the host system 310 as a whole and instructs the graphic processor 321 to execute graphic processing. Normally, the command execution routine 221 is stored in the memory 220
Resident in RAM and loaded after power up,
This is not a requirement. Like the communication driver 211, the command execution routine 221 can be modified so that the interface can be port-connected to different hardware systems.

The command execution routine 221 runs on the graphics system 310 as a slave to the communication driver 211,
The GSP side of the host GSP hasidic shaking is processed to receive commands sent by the host, determine whether they are packet or direct commands, and invoke the called function accordingly. In the case of the direct mode command, the command execution routine 221
Set up a global pointer to the parameter data for the function and call the function. In the case of a packet command, the command execution routine 221 calls the argument handler 441b. The handler 441b rearranges the data as described above using the same global data pointer as the direct method. Core primitive functions and assembly language functions can be called in the same way.

The argument handler programs included in the argument handlers 441a and 441b are programs that pass special arguments, remove the arguments from the stack 414 of the host system 310, pass them to the graphics system 320, and pass them to the graphics system 320 after they are passed. Performs a runtime task that allows the bus to be rebuilt into the stack 423 of the graphics system 320 in a high-level language format. In the embodiment of FIG. 4, the argument handler resides on systems 310 and 320 and is designed for one-way communication.
However, it should be understood that bi-directional parameter exchange may be possible by making the argument handlers symmetrical. Each argument handler could then perform both reassembling and pushing packets onto the stack and parsing them from the stack. Further, in the case of an integrated multiprocessor system, there could be one argument handler for all processors in the system. Thus, in FIG. 4, the argument handler 441a
Linked to 1 and communicates with stack 414. Argument handler
441b is linked to command execution routine 221 and communicates with stack 423.

For programming convenience, the interface can be provided with certain include files to avoid repetitive definitions. These include files can be divided into two groups:
(1) files included in a source file designed to run on the host system 310;
(2) A file included in a source file that runs on the graphic system 320. The first group of include files is part of the application interface 412 and the second group is used to build the graphics system 320 of FIG. The include files of the host system 310 are as follows.

 extend.h Calls an extension primitive function.

graphics.b Defines the data type used for the packet method.

typedefs.h For structure definitions used for interfaces.

Include file 2 for graphics system 320
25 is as follows.

gspextend.h External declaration of extended primitive functions gspglobals.h External declaration of all global variables gspregs.h Definition of graphic system registers gspgraphics.h External declaration of all core primitive functions The communication driver 211 and command execution routine 221 are shown above As such, a feature of the present invention is that it is hardware dependent. This feature is partially realized by the inquiry function which is a part of the core primitive function 224, and the communication driver 211 and the command execution routine 221
Does not require qualification. By the above inquiry function,
Application program is graphic system 32
Find the configuration of 0. In response to the inquiry function, the graphics system 320 returns information such as pixel depth in bit representation, horizontal and vertical resolutions, and the amount of random access memory on the graphics system. The application program can then scale its output to fit any display resolution.

Table A is an example of this hardware dependent feature using two functions, get_config and set_config. Function ge
t_config returns a structural variable containing all information specific to the graphics system 320 and mode. The set_config function sets the graphics mode selected by the index passed to the default graphics mode. In that case, the graphics system 320 sets the next set_con
Remains until a call to fig is made. set_confi
For g, if the graphics_mode argument is valid, the function sets up a new graphics mode and initializes the appropriate GSP registers. If the init_draw plug is true, the function initializes the drawing environment.

A "core primitive function" is a basic function that is permanently installed in a sub-processor system and is always available for loading. These core primitive functions can be grouped into two basic function types: system primitive functions and application primitive functions. System primitive functions include functions that perform processes such as subsystem initialization, output, memory management, communication, and expansion. Extension functions, which are the latter type of system primitive, are used in connection with the method of the present invention and will be discussed in more detail below.
An application primitive is called and used by an application program running on a host if it is linked using the present invention.

Although the following description of the present invention is primarily directed to the C programming language, the programming for practicing the present invention is not specific to the C language,
The programming structures and functions described in the text 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. That particular program is considered to be within the capabilities of a programmer of ordinary skill in the art after reviewing the present invention.

The premise of the present invention is that a sub-processor system can be best utilized if it has load, link, and available extension functions independent of its core primitive functions. In accordance with this premise, the present invention can provide a method for incorporating extension functions with programming of other multiprocessor systems. The above method
Regardless of when and where the functions are coded, software americanism can be implemented that dynamically links the various functions used in an application program.

FIG. 6 illustrates the method of the present invention from the perspective of a programmer wanting to develop an extension function for a subsystem processor. These extension functions are constituted by a group of functions that are finally called in the application program and execute a certain task for the user. Basically, the steps create 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 can be partially linked to existing code, leaving the reference to other code that will be resolved at runtime. .

With respect to the link and load steps of the present invention, the following description relates to processes and structures common to software programming that perform these tasks. In particular,
It is envisioned that the linker creates object files in a common object file format, a format well known in the art. This format favors modular programming, where each module has small blocks of code and data called sections. One section is the smallest relocatable unit of one object file,
Eventually, it will occupy adjacent space in the memory where 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 format sufficient to create relocatable, partially linked function modules.

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

Examples of such methods for adding extension functions to a multiprocessor system are the packet method described in US Pat. No. 5,216,095 and the direct method described in US Pat. No. 5,404,519.

After the functions are defined, they are collected, compiled or assembled and linked into a form of loadable code, such as a series of common object files.
One example of the result of step 111 is a file called myfuncs.obj, which contains two functions, my_func1 and my_func2.

An advantage of the present invention is that the modules of the extension functions can be created by the same programmer who creates the application programs that use them.
Thus, a module to be loaded and used during the execution of a particular application need only include 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 technique that is reliant on the path of parameters between processors.

In step 112, a reference section is created, and an address reference is declared for each extension function in the module created in step 111. Steps
An example of 112 is the following programming, where my-func1 and my-fu
Refers to two functions of nc2.

External reference The number of commands declares a function in the load module to be defined in a specific instruction. This provides a means to refer to the function. In particular, the command number of a function can be embedded in a function call in an application program that calls that function. The reference section is assembled or assembled, for example, ext.ob
A common object format file such as j. is generated.

In step 113, the module created in step 111 and the section created in step 112 are partially linked to form one load module. This module may include a function that has a reference value in the module. This link step resolves reference values between such functions in the module. The module may also include functions that reference or are referenced by functions outside the module. If such external references exist, their linking is only partial and these external references will be unresolved. Partially linked files must have relocation and symbol information. Some linking concerns the formation of the output section, not the distribution. Allocation, binding, and memory directives are all 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. An unresolved reference is outside of a module already stored in the sub-processor system, and the reference function does not have an address for it. An essential feature of the linker used in step 113 is that it can have calls to functions that cannot be resolved until runtime. These calls are resolved when the function is loaded into the memory of the sub-processor system, as described below with respect to FIGS. 2, 3, and 4. The dynamic linker resolves calls by inserting addresses into the code.

The following is an example of a command for executing step 113 using a computer that is unique to the linker.
In that case, the two functions defined in step 111,
The section created in step 112 is to be linked. As an example, the linker is invoked with the following command:

Iink LOAD MOD myfuns.obj ext.obj The result is a relocatable load module entitled LOAD.MOD, which is a combination of the object modules created in steps 111 and 112.

Thereafter, the load module can be used in a series of different ways. That is one of the advantages of the present invention. For example,
Modules are supplied to other modules, and modules can be linked into the main program or loaded into subsystems and linked with core primitive functions. Instead, the same user can use the load module to develop an application program for a multiprocessor system. Thus, as shown in FIG. 4, the next step is 114a, where the module can be loaded into the subsystem or step 114b can be linked to the application program. From an end-user perspective,
The load module resides, partially linked, in the user's host system memory and is ultimately downloaded to the sub-processor system and can be used with a particular application program, as described below with respect to FIG. .

FIGS. 2, 3, and 7 illustrate a second aspect of the present invention, a method of using a computer to load and dynamically link extension functions in a multiprocessor system. The above linking is dynamic in the sense that the addresses of other functions called by the extension function when the extension function is created are unknown. These addresses are in an unknown state until the application program runs.

The steps of the dynamic download method of the present invention include:
As shown in FIG. In general, the method comprises loading the host processor system 310 into the sub-processor system 320 with a set of extension functions, and then linking references to the unresolved extension functions.

First, in steps 141-143, the dynamic linker 22
4 checks that there are two files it needs: a symbol table file 225 and a load module 215 currently stored in memory 210, such as an object file 216 linked earlier. . The symbol table file 225 is maintained by the symbol table function in the core primitive
It stores the functions already loaded in the memory 220 of 320 and the symbolic information representing the memory addresses associated with each function. Thus, if previously created load modules are used, they are loaded and their symbols and addresses are stored in the symbol table file 22.
Need to be placed within 5. 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 not defined in the load module 215. An example of a symbol table function that performs this task is the following C language function:

int create_symhol_file (name) char far ^* name; where name is the path name of the file containing the function. The symbols and their respective absolute addresses are stored in such a way that they can be accessed during subsequent calls to the loader.

In order to ensure the integrity of the symbol table file 225, the dynamic linker 224 executes a restricted call to the command execution routine 221 and executes the routine 2
21 queries the status of the modules installed in the sub-processor system memory 220 using a special core system primitive function. The purpose of this step is to determine if there is a divergence between such a module and the module symbol in the symbol table file 225. If present, the symbol table file 225 is adjusted accordingly. If not, an error message is communicated to the user.

In step 144, the dynamic 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 primitive function to obtain a large memory block large enough to store the load module. An example of a command expressing such an assignment function is as follows.

long alloc (size) long size: where long size is the size of the module in bytes. This function allocates a block of sub-processor system memory 220 of the specified size and returns the pointer.

In steps 145-146, the dynamic linker 224
Performs its primary task of combining the object files executed by sub-processor system 320 into executable image file 226. When the dynamic linker 224 creates the executable file 226, it loads the object file 216 into the memory 220,
Resolve external references. In doing so, the linker loads the load file 216 along with the application source file 223.
As input. In particular, the dynamic linker 224 relocates the desired COFF section into the subsystem memory map. To resolve references to previously unresolved external functions, ie, functions not defined in the load module 215, the dynamic linker 224 refers to the symbol table file 225 to find a symbol representing the function. Thereafter, the dynamic linker 224 replaces the reference in the load module 216 with the address of the referenced function. In this manner, the dynamic linker 224 links all extension functions listed in the reference section of the load module 216 with other code loaded in the sub-processor system 320. Similarly, the dynamic linker 224 adds symbols representing the functions defined in the load module 216 to the symbol table file 225 so that subsequently installed load modules can access the load module 216. .

In general, the programming method linking step 146 uses a programming technique similar to that of other dynamic link tools used in the case of a one processor system. Of course, those systems do not require the extra task of associating two processor systems as performed by the present invention.

After the load module 216 has been loaded into the memory 220 at step 147, the dynamic linker 224 utilizes the information in the reference section of the load module to allow the functions in the module to be called from the application program 212. . In particular, the dynamic linker 224 builds a table (not shown) representing the extended function address used by the command execution routine 221.

In step 148, the dynamic linker 224 now
It is determined whether any functions not needed by the application program are loaded into the memory 220. If present, these functions are discarded from active memory.

Finally, in step 149, the dynamic linker 2
24 returns the module identifier to the application program. The module identifier is used when calling an extension function from the application program 212, and calls those functions. By way of example, the module identifier may be the same as the number of modules in the reference section discussed with respect to FIG. Step 148 is useful when one or more modules are to be loaded on sub-processor system 320.

The dynamic linking shown in FIG. 2 is part of the installation process during which the user invokes the installation procedure using a computer, which in turn preferably invokes the dynamic linker 224. An example of an installation instruction is the following function written in C language.

int install_lm (lm_name) char for ^* lm_mame: where lm_name is the name of the load module. Following the above steps, this function installs any load module specified by the load module name and returns the module identifier.

Once the load module 216 has been downloaded and linked, the run-time processing of the multi-processor system calls for the use of a certain type of parameter path approach between the two processor systems. As described above with respect to FIG. 1, this can be done in the programming phase 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.

As described above, one or more load modules 216 can be loaded, each of which receives its own module identification number. By programming the dynamic linker 224, an identifier that identifies both a module and an extension function in the same module can be returned. One example of a method that allows identification is to assign a module number to each load module 215 according to the order in which it is installed. This identifier is used by connecting the function number as given in step 112 of FIG. 6 to the module identifier whenever a function in the module is to be called from the program. In the case of the C language, this can be done with a bitwise OR operator. Then the linking will include all load modules.

In an alternative embodiment of the present invention, instead of an extension function, an interrupt service routine used by the application program is added to the multiprocessor system. The method shown in FIG. 1 is essentially the same, except that the load module stores an 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 entry points for all interrupt service routines in the module. These entry points specify the address reference to the interrupt service routine and the number of interrupts in that routine. For example, if two routines my_inf1 and my_inf2 are stored in the module in step 11, the section declaration would be as follows:

The load time method associated with adding an interrupt service routine is also essentially the same as described above with respect to FIG. Another extra consideration is that the priority information associated with each routine can be retrieved by accessing the module's priority list. Thus, interrupt service routines cascaded to the same interrupt level can be specifically accessed or referenced.

 The following items are disclosed with respect to the above description.

1. A method comprising a host processor system and a graphic processor system for use in a multiprocessor system for extending functions executable by the graphic processor that are called by a main program running on a host, the method being executed by the graphic processor. A subprogram in the main program that contains the parameters used by the subprogram in the main program by defining the subprogram so that its arguments can be passed to the graphics processor system at runtime. And compile the subprogram and execute it on the graphic processor system. Loads to, linking the subprogram to other code that is loaded onto the graphics processor system, said method consisting step.

2. A method of using a multi-processor computer system, comprising a host processor system and a graphics processor system, for executing an extended function called by a main program running on the host computer and executed by a graphics processor, comprising: Loading to a graphics processor system, calling the extension function from the main program, passing arguments of the extension function from the host system to the graphics system, and executing the extension function by the graphics processor. .

3. In a multiprocessor computer system, wherein a single software program is executed on a first processor so that the program can call a designated extension function to be executed by a second processor. A memory accessible by the host processor, a programmable graphic processor, and a memory accessible by the graphic processor, wherein the host processor and the graphic processor are programmed by a software interface, and the extended function is executed by the interface. The system dynamically downloaded to the graphics processor memory and executable by the graphics processor; Temu.

4. A software interface for use with a multi-processor computer system that includes a host processor system and a graphics processor system and executes an extended function that is called by a main program running on the host system and executed by the graphic processor, the software interface comprising: A linker that dynamically downloads and links to other code loaded on the graphics processor system, receives an argument from the host system, identifies the extension function, and executes a command execution routine that calls the extension function; A set of tools in which the command execution routine and the linker are integrated, before dynamically downloading extension functions and receiving their arguments from the host processor system Interface.

5. A method for adding an extension function to be loaded into a 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 reference section of the module, including a relocatable address reference to the load module, and partially link the load module to resolve all internal references and leave external references unresolved. Said method comprising the steps of allowing a load module to be fully linked at runtime.

6. A method used in a multi-processor system to load an extended function to be executed by a subsystem processor so that the function can be called from an application program running on a host processor system. Assigning the load module to the load module containing the definition of the extension function, loading the load module into the sub-processor system, and linking the load module to another code to be loaded into the sub-processor system. Said method comprising: resolving a resolution reference.

7. In a multiprocessor computer system in which the extended functions are loaded and linked to a subprocessor system so that the functions can be used with an application program running on the host processor system, the multiprocessor computer system is accessible by the programmable host processor and the host processor. memory,
Wherein the sub-processor downloads an 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. The system programmed to:

8. A dynamic linker programming mechanism used in a multiprocessor system for linking extension functions to be executed by a subsystem processor during loading of an application program running on a host processor system with other codes of the subsystem processor. An entry point for receiving a call for starting execution in response to loading of the application program; an instruction for acquiring a memory size of a load module including the extension function; and a memory from the host to the memory of the sub-processor system. An instruction for relocating the load module; and an instruction for resolving an unresolved reference to a function outside the load module, wherein the entry point and the instruction are executable by the subsystem processor. Said mechanism composed into one syntax and sentence.

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 interface is made up of software resident on the host system side and the graphic system side, and can be operated at run time so that the functions can be called from a main program running on the host. The function arguments are passed to the graphics system so that the function is executed by the graphics processor.

[Brief description of the drawings]

FIG. 1 is a flow diagram showing the stages of extending the functionality of the graphics subsystem, FIG. 2 is a flow diagram showing the steps of using a computer system having a host processor and a graphics processor, FIG. FIG. 4 is a block diagram of a multiprocessor computer system having a graphics processor, FIG. 4 is a block diagram showing a software interface used with the microprocessor system of FIG. 3, FIG. 5 is a communication diagram between the host processor and the graphics processor. FIG. 6 shows the structure of a communication buffer used for the sub-processor system, FIG. 6 shows the steps of creating a module for storing an extension function used together with the sub-processor system, and FIG. From the processor Loads to 2 processors, shows the step of linking the unresolved references dynamically. [Description of Signs] 212 Application program 211 Communication driver 216 Object file 215 Extended function 224 Dynamic linker 233 Core application primitive function 225 Include file 222 Core system primitive function 423 …… Stack 323 …… Buffer.

Continued on the front page (72) Inventor William S. Eagle United States of America 77478 Sugarland North Media River Circle 1418 (72) Inventor Douglas Sea Crawford United States of America 77479 Sugarland Pembroke Street 11 (72) Inventor Michael Dee Assal United States Texas 77479 Sugarland West Langcrest Place 3207 (72) Inventor Graham Short United States Texas 77479 Sugarland Grants Lake 2808 Apartment 404 (72) Inventor James G Littleton United States Texas 77099 Houston Boca Court 10303 (72) Invented Jerry Earl Van Arkan Texas United States 77478 Sugarland Fernhill 13563 (56) Flat 1-240923 (JP, A) Computer Language Vol. 6, No. 5 p59-74 May 1989 Michael Draganza "Dynamic Link Libraries Under Windows" NIKKEI BYTE FEBRUARY 1987 p168-182 Carrell R. Killble Jr. “TMS34010: A high-speed graphics engine capable of bit addressing using a graphics system processor pipeline” (58) Fields investigated (Int. Cl. ⁷ , DB name) G06F 15/177 670 G06F 15/16 620 G06T 11/00 INSPEC (DIALOG) JICST file (JOIS) WPI (DIALOG)

Claims (3)

(57) [Claims] 1. A method for providing enhanced graphics capabilities for execution by a multiprocessor system, the method comprising:
The multiprocessor system includes a host processor system for executing a main application program and a graphic processor system for executing a graphic program including a core primitive graphic function.
Converting the executable form of the subprogram into a subprogram in an executable form by the graphic processor system, and partially linking the executable form of the subprogram to resolve an internal reference; Storing the program in the host processor system; downloading the executable form of the partially linked subprogram from the host processor system to the graphic processor system via a communication driver; A graphic processor system, receiving the downloaded subprogram; and resolving the external reference in response to downloading and receiving the subprogram. Linking the core primitive graphics functions loaded into the graphics processor system via a linker running on the graphics processor system; storing the downloaded and linked subprograms in a memory of the graphics processor system; Calling an extended graphics function from the main application program executed in the system, transmitting the extended function call from the host processor system to the graphic processor system via a communication driver, and calling each of the extended function calls from the host processor system Receiving at the graphics processor system via the instruction executive, executing the downloaded and linked subprogram Wherein performing said extended graphics capabilities in the graphics processor system. 2. A method for providing enhanced graphics capabilities for execution by a multiprocessor system, the method comprising:
The method, comprising: a host processor system for executing a main application program; and a graphics processor system for executing a graphics program including a core primitive graphics function, wherein the multi-processor system has at least one Storing the main application program having a call in the host processor system, storing the executable form of the partially linked subprogram in the host processor system, and storing the executable form in the partially linked subprogram Has at least one call to the core primitive graphics function and resides in a subprogram in a form executable by the graphics processor system; Downloading the partially linked subprogram in the executable form from the host processor system to the graphics processor system via a communication driver, via the instruction executive, Receiving, in the graphics processor system, the downloaded subprogram; executing the downloaded subprogram in the graphics processor system to resolve external references in response to downloading and receiving the subprogram; Linking the core primitive graphic function loaded into the graphic processor system via the linker, and downloading and linking the downloaded subprogram to the graphic processor system. Calling an extended graphics function from the main application program executed in the host processor system, transmitting the extended function call from the host processor system to the graphic processor system via a communication driver, Executing the enhanced graphics function on the graphics processor system by receiving the enhanced function call from the host processor system via the instruction executive at the graphics processor system and executing the downloaded and linked subprogram A method comprising: 3. A method for loading and linking a memory of a sub-processor used in a multiprocessor system having a sub-processor including a separately accessible memory and a host processor, wherein the extended function is the sub-processor. A method for executing by a processor so that the functions can be called from an application program executed by the host processor, wherein the host processor stores a program module including a definition of an extended function to be executed by a sub-processor. And all calls by the extension to other ones of the extension in the load module are resolved by providing a memory address of the called function; Determining the size of the memory required to store the program module in a memory accessible by a processor; allocating memory of the sub-processor for the program module in the sub-processor; Downloading from the host processor to the sub-processor, wherein in the sub-processor, in response to downloading and receiving the program module, the read-out by the extended function is stored in another memory of the sub-processor. The method characterized by linking to.