Electrical computers and digital processing systems: processing – Architecture based instruction processing
Reexamination Certificate
1998-02-18
2001-01-09
Coleman, Eric (Department: 2783)
Electrical computers and digital processing systems: processing
Architecture based instruction processing
C709S241000
Reexamination Certificate
active
06173391
ABSTRACT:
FIELD OF INVENTION
This invention relates to computer program architecture, and more particularly relates to a program architecture in which program modules are not controlled by another module.
BACKGROUND OF THE INVENTION
Conventional computer program architecture consists of a main program and a plurality of program modules. The main program typically controls and coordinates the operation of the program modules.
FIG. 1
is a schematic diagram of a program
100
having such an architecture. In
FIG. 1
, a main program
102
contains a plurality of statements, such as
104
and
106
. Some of the statements could be CALL statements, such as statements
108
and
110
. These two CALL statements, when executed, will invoke program modules
120
and
130
. Main program
102
may contain a LOOP statement which causes main program
102
to execute continuously in a loop. Main program
102
also contains a STOP statement for terminating the program. It should be appreciated that program
100
could be written in different programming languages, and the precise syntax of the statements and program structure could vary with the programming languages.
Program
100
contains a plurality of program modules, such as modules
120
and
130
, called by main program
102
. Module
120
contains a plurality of statements, such as statements
122
and
124
. It could also contain a plurality of CALL statements, such as statement
126
. This statement, when executed, will invoke another module
140
. Finally, module
120
contains a RETURN statement.
When CALL statement
108
is executed, main program
102
jumps to module
120
. Statements
122
,
124
and the rest of the program are executed. Upon executing the RETURN statement in module
120
, program
100
returns to statement
106
, which is the statement following CALL statement
108
. At this time, the control of program
100
is returned to main program
102
. Main program
102
continues to execute.
The structure of all the modules is similar to that of module
120
. Similarly, the jump-return mechanism, described above, is carried out by all the CALL statements in program
100
. Consequently, they will not be further described in this specification.
In order to carry out this jump-return mechanism, the return addresses of the CALL statements need to be saved in RAM (typically in a memory structure called a stack). Other essential state information of the computer prior to jumping to the called module, such as values of registers, may also be saved if there is a need to do so (e.g., when jumping to an interrupt service routine). Thus, when main program
102
calls module
120
, the contents of these registers may also be pushed (i.e., saved) in the stack. Similarly, when module
120
calls module
140
, the return address of module
120
also needs to be saved. The contents of appropriate registers may need to be pushed in the stack. Thus, the size of the stack could be large when a large number of CALL statements are executed.
When a RETURN statement is executed, the return address is used to return to the calling program. The saved information is also retrieved.
Typically, a program in the above described conventional architecture contains many CALL statements and many modules. These modules could call other modules (e.g., module
120
can call module
140
), thereby forming a chain of CALL statements. The precise history of this chain needs to be preserved so that the last called module can return to the main program. One of the problems of the conventional architecture is that the time to travel the chain could be very long. As pointed out above, each time a CALL statement is invoked, certain amount of state information needs to be saved, resulting in overhead in execution. Each time a RETURN statement is executed, the saved information needs to be restored, again requiring overhead in execution. As a result, the execution speed of programs written using conventional architecture is slow.
The following are some of the characteristics of the conventional architecture: (a) there is a controlling (“boss”) program, e.g., main program
102
, (b) all the linkage information (e.g., return address and registers) needs to be preserved when one part of the program (a calling program such as main program
102
or some of the modules) transfers execution to another (the called program), and (c) the linkage information is used to return control and information to the calling program. This architecture could be called a “boss” architecture. The calling module can be considered a master while the called module can be considered a slave executing commands issued by the master and then reporting results to the master.
Recently, other programming architectures have been developed. However, they are also based on the boss architecture. One example is object-oriented programming. This method allows codes to be reused and applications developed relatively rapidly. However, the applications still have a controlling body which adds tremendous overhead.
Advances in program architecture have also been made in operating environments. One example is an interprocess communication protocol called dynamic data exchange (DDE) used in Microsoft's MS Windows environment. DDE uses a shared memory to exchange data between processes and a protocol to synchronize the passing of data. The heart of DDE protocol is the DDE message. A process (client) can ask another process (server) to perform a service. Specifically, the client issues a WM_DDE_EXECUTE message to post a command to the server by storing a command string in a global memory block and passing to the server a handle to the global memory block. The server subsequently returns a WM_DDE_ACK message to the client. If the server successfully executes the command, the WM_DDE_ACK message would return a TRUE value to a DDEACK structure member labelled “fAck.” If the command is not successfully executed, the server posts a WM_DDE_ACK message with “fAck” set to FALSE. When the client receives the WM_DDE_ACK message from the server, it deletes the command string from global memory and proceeds to take appropriate actions accordingly.
It is clear that interprocess communication via DDE has many characteristics of the conventional architecture shown in FIG.
1
. Specifically, the preservation of linkage information and the return of control to the client are important aspects of DDE. While the architecture of
FIG. 1
stores the content of a few registers and the return address in each interprocess communication, DDE uses elaborate commands and data structure. As a result, DDE is even less efficient than the architecture of FIG.
1
.
Another example of new developments in operating environment is an architecture used in MS Windows called OLE (Object Linking and Embedding). This architecture allows one application (e.g., a word processor program) to be linked to one or more applications (e.g., a spreadsheet program). In the terminology of OLE, applications can be classified as client applications and server applications. MS Windows uses a “registration database” to maintain a collection of information about OLE applications and file extensions for MS Windows applications. All communication between applications is handled by OLE. Specifically, OLE applications communicate through the use of three dynamic-link libraries: OLECLI.DLL, OLESRV.DLL, and SHELL.DLL. The SHELL.DLL enables applications to communicate with the registration database. The OLECLI.DLL is the OLE client library and the OLESRV.DLL is the server library. The OLE server and client libraries communicate with each other through DDE messages. The typical path of communication for an OLE function includes the call of the function, DDE messages between OLE libraries, and disseminating information to the client and server applications.
In one example, when the OLESRV.DLL library receives notification from the OLECLI.DLL library that a client application needs an object, the OLESRV.DLL library calls appropriate server methods. For example, OLESRV.DLL calls a
Nakajima Ichiro
Shoji Wataru
Tabuchi Daisuke
Chan H. C.
Coleman Eric
Sofmap Future Design Co., Ltd.
LandOfFree
Bossless architecture and digital cell technology for... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Bossless architecture and digital cell technology for..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Bossless architecture and digital cell technology for... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2496141