Bios having macro/effector pairs for hardware initialization

Details Bios having macro/effector pairs for hardware initialization Bios having macro/effector pairs for hardware initialization

2000-02-29

2004-08-31

Lee, Thomas (Department: 2115)

Electrical computers and digital processing systems: support

Digital data processing system initialization or configuration

Loading initialization program

C713S001000, C711S103000

Reexamination Certificate

active

06785806

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Field of the Invention
The invention generally relates to methods for programming and more particularly relates to programming a BIOS (Basic Input/Output System) or in a system with highly restricted system resources.
2. Description of the Related Art
When a computer system starts up, typically it first runs instructions on the processor(s) which are stored in a BIOS (Basic Input/Output System). These instructions may initialize the system and may help the system determine how it is configured and how it may operate. Due to the state of the system at the time, the instructions in the BIOS are typically restricted to instructions that can be run solely on the processor. The system may have random access memory installed, but that fact needs to be discovered by the processor before the random access memory may be used, so until the presence and configuration of random access memory has been established, the processor must not execute instructions that use random access memory. As a result, code written in high-level languages such as C may not be used to directly implement the instructions in the BIOS until memory is configured for proper system operation. In particular, no code which uses a stack for passing procedure/function calls and arguments may be used, as a stack is typically allocated in system memory. The only memory available is that in the BIOS (which is usually FLASH ROM and therefore unsuitable for temporary storage) and memory contained within the processor (typically registers). Furthermore, the memory used is relatively expensive, so the more of it that is used, the more expensive the system becomes.
This startup environment is highly restricted as described, but also does not demand sophisticated programs. The contents of the BIOS are fairly simple routines for determining if memory (such as random access memory) is included in the system, where any included memory is in the physical addressing space, what other peripheral devices are attached to the system, and whether any malfunctions are occurring. Unfortunately, if there is a problem in the BIOS code itself, that is very difficult to find, as the traditional debugging techniques such as observing messages on a screen from embedded parts of code or reading a file containing a step-by-step description of what processing occurs are not available when running BIOS code under startup conditions. Traditional debugging techniques require system resources that the BIOS code must initialize, and those system resources may not be used without first undergoing initialization. If a BIOS in a system that is out in the public fails, chances are that either the system will fail to start properly, leaving it wholly nonfunctional, or it will have some sort of intermittent error due to a relatively minor bug in the BIOS which only affects a non-critical portion of the system. In either case, those attempting to isolate and fix the error will often have tremendous difficulty isolating the error.
The BIOS code is typically written in assembly language, written at a low enough level that an assembler may easily convert it to native instructions for a processor (machine language). At this level, code is typically written such that if a procedure or function call is specified, rather than having the code jump to the procedure or function, the code for the procedure or function is inserted at the point where the procedure or function call was specified. This results in duplicated procedure or function code and larger than necessary code size. It also makes debugging the code difficult, as it does not exactly correspond to what was written prior to assembly of the code. Furthermore, much of the code may be devoted to moving operands into specific registers for purposes of the procedure or function execution, then moving the operands back to where the operands came from. Moreover, these operands are often parameters that are not varied within the procedure or function, they are simply necessary as reference values for the execution of the procedure or function.
One alternative to this coding scheme is use of a table of function calls which may be executed sequentially. In that case, the function calls are not replaced by the actual function code, so debugging is somewhat easier. However, tables typically must have all entries identical in size, which means that each entry must have a place for the information necessary in all other entries. This results in a table wherein most of the entries use only a small portion of the total memory allocated to each entry, and therefore results in significantly larger than desired code. Furthermore, the developer of the table is in a position to make many simple mistakes due to the complexity of maintaining a large and unwieldy table of entries. Additionally, some sort of engine must be written to sequence through the table, and that engine will require even more code to implement.
SUMMARY OF THE INVENTION
The invention, in one embodiment, is an apparatus. The apparatus includes an effector having executable code. The apparatus also includes a macro having a reference to the effector.


REFERENCES:
patent: 4928237 (1990-05-01), Bealkowski et al.
patent: 5113512 (1992-05-01), Miki et al.
patent: 5247659 (1993-09-01), Curran et al.
patent: 5355489 (1994-10-01), Bealkowski et al.
patent: 5519843 (1996-05-01), Moran et al.
patent: 5615331 (1997-03-01), Toorians et al.
patent: 5768568 (1998-06-01), Inui et al.
patent: 5835594 (1998-11-01), Albrecht et al.
patent: 5930504 (1998-11-01), Gabel
patent: 5860083 (1999-01-01), Sukegawa
patent: 5937434 (1999-08-01), Hasbun et al.
patent: 5974546 (1999-10-01), Anderson
patent: 6018806 (2000-01-01), Cortopassi et al.
patent: 6026402 (2000-02-01), Vossen et al.
patent: 6032239 (2000-02-01), Beelitz
patent: 6101601 (2000-08-01), Matthews et al.
patent: 6119131 (2000-09-01), Cabrera et al.
patent: 6138239 (2000-10-01), Veil
patent: 6148441 (2000-11-01), Woodward
patent: 6185678 (2001-02-01), Arbaugh et al.
patent: 6192471 (2001-02-01), Pearce et al.
patent: 6256031 (2001-07-01), Meijer et al.
patent: 6308264 (2001-10-01), Rickey
patent: 6308265 (2001-10-01), Miller
patent: 6378128 (2002-04-01), Edelstein et al.
patent: 6392925 (2002-05-01), Jha et al.
patent: 6401202 (2002-06-01), Abgrall
patent: 6401208 (2002-06-01), Davis et al.
patent: 6418449 (2002-07-01), Chen et al.
patent: 6430481 (2002-08-01), Lovelace, II et al.
patent: 6446201 (2002-09-01), Gunther
patent: 6510512 (2003-01-01), Alexander
patent: 6629192 (2003-09-01), Schaefer et al.
patent: 411039152 (1999-02-01), None
patent: 411306007 (1999-11-01), None
“Computer Address Resolution Across 64K Boundaries”, IBM TDB, Jan. 1988, vol. 30, p. 113.
Dirk Desmet, “Efficient Assembly Code Generation for Digital Signal Processors Starting from a Data Flowgraph”, IEEE 1993, pp. 45-48.
Jerry Jex,Flash Memory BIOS for PC and Notebook Computers, May 9-10, 1991, pp. 692-695.

Affiliated with

Also associated with

Rating

Bios having macro/effector pairs for hardware initialization does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Bios having macro/effector pairs for hardware initialization, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Bios having macro/effector pairs for hardware initialization will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3280813