Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/30—Creation or generation of source code
  • G06F8/34—Graphical or visual programming
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/70—Software maintenance or management
  • G06F8/71—Version control; Configuration management

Definitions

• source code files are placed into a directory hierarchy. Different subdirectories may correspond to different software "components.” Each “component” in the directory hierarchy, whether it be a true software component or a "hardware component,” meaning software supporting the needs of a particular hardware device, may be defined further by one or more “features" stored in lower level subdirectories so that one or more features may comprise each component and there may also be “sub-features” stored in yet lower level subdirectories.
• One or more source code files may reside in each feature subdirectory. Each component and each feature is further described by an information file that is placed into its corresponding subdirectory defining what type of platform (server, notebook, etc.) a feature is intended for, what class it is assigned to, etc.
• Fig. 20 illustrates an outline of the portion of data shown in Fig. 19 that is selected and fed into the product make routine 900 shown in Figs. 8 and 34 to govern the building of the finished product
• Fig. 21 illustrates an exemplary set of product configuration commands contained in the product configuration data file "platform. cfg" 2100 shown in Fig. ii;
• Fig. 23 illustrates the contents of an exemplary feature include file "feature.inc" 2300 (Fig. 11), these contents being generated automatically by the product make routine 900 (Fig. 11) and more particularly generated by the build feature include file routine 950 (Figs. 9A and 35);
• Fig. 42 presents a block diagram that illustrates the use of the product compent linker 3600 to customize single items taken from a table.
• the make utility sensing more commands in the product make file 2500, continues to read commands from this file 2500, to select additional component subdirectories, and to call upon itself to execute component make commands found in makefiles associated with each additional component, as was just explained, until finally all the component source code files have been compiled or assembled and linked.
• the new source tree entry 312 is used when the source code library tree has never before been processed, thereby making it unnecessary to perform steps such as steps 956 and 904 in Figs. 9A and 9B that check for whether existing special files need to be corrected (since it is likely no such files exist).
• the step 402 calls for a scan of the entire tree (Fig. 4).
• the configure product entry 702 into the configurator 700 is then taken which, at step 604, calls for access to the data in the database 1800 (Fig. 6) and then configures the product in step 3000 (see Fig. 30 for details).
• a report is generated for the designer, and the product configuration state data 1900 is written out to disk storage.
• the INF file includes ASCII text containing attributes used for browsing the software project and controlling the compilation process.
• BaseClass is used to identify that two features have the same interface and provide the same basis functionality. Normally no final software product may contain two features having the same BaseClass.
• the database is searched for each caller to see if the version is compatible with the callee.
• the version is considered compatible if the major version number of caller and callee are the same and the callee minor version number is greater than or equal to the caller version number.
• This information can be displayed, output to a file, etc. so that the designer is informed of any potential incompatibility.
• the originally called routine can be optionally branched to from within the intercept routine using the EXTJMP and EXTCALL macros.
• the linking utility will perform this by using the fix-up information in the intermediate libraries to correctly link the branch instruction to the original routine.
• the originally called routine can be optionally removed if the intercept routine never calls it and no other piece of code in the final binary image would reference it.
• files can be listed in a makefile, batch file, or command line application, like it is done for the creation of object libraries.
• a centralized list can list the library files of a project.
• the resolution of external references to public declarations can be done at alternate phases of development and build. It can done dynamically during edit of a source code file for real-time feedback to the developer, or it can be done after individual file compilation, using compilation output to provide public and reference information.
• the listing of object modules to compile and link can be done form a batch file, or a list input for command line link execution.
• the configurator procedure 700 creates the configuration state data, defining the configuration of the finished product, using information drawn from the database 1800 and information drawn from the product configuration file "platform. cfg" 2100.
• the configurator 700 which in the preferred embodiment is written in C++, maintains this information in a C++ RAM data structure of classes (in the C programming sense of the word class) as is shown in Fig. 32.
• any number of product configurations 3202 may be stored in this RAM data structure.
• Each such product configuration may be linked to any number of classes 3204 (in the sense of the present invention), components 3206, and features 3208.
• each may be linked to any number of dependencies 3216 ("include”s, “option”s, macros, and functions, where functions include lists, labels, function calls, and strings) as well as any number of interfaces 3218 (anything that can be publicly (between components) or privately (access limited to parents and siblings) referenced, such as procedures).
• dependencies 3216 include
• optional include lists, labels, function calls, and strings
• interfaces 3218 anything that can be publicly (between components) or privately (access limited to parents and siblings) referenced, such as procedures.
• the EXTCALL macro 1318 calls the external procedure DELAY assigned to the class TIMER using its declaration in the PUBEXT macro 1312. Since this procedure is defined in a seperately linked component, the reference to it will be fixed up by the Product Component Linker (Fig. 36).
• the EXTCALL macro is described in Section 1.1 of the Line-by-line Description of Macros.
• the END_PROC macro 1320 ends the procedure opened by the PUBLICJPROC macro 1316. It is described in Section 3.3 of the Line-by-line Description of Macros.
• a Uses command is an optional command that is used to identify the location of shared code used by an object being described.
• the build tools may use this command to identify the file as a dependency in the MAKEFILE created for the object.
• Use of shared files is restricted.
• objects may only use files that identify themselves as shared using, for example, a PRIVATE_PROC or PRTVATE_ ⁇ NCLUDE command with the 'Shared' attribute.
• an object may only use shared source files that are in sibling directories, or immediate children of upstream directory nodes.
• the Uses command includes a FilePath field that provides the relative path and filename of the shared file to be used by the object.
• Figs. 19 and 20 are symbolic representations of the data structures contained within the configuration state data 1900, organized similarly to the database shown in Fig. 18.
• Three components - component A 1902, component B 1904, an component C 1906 are shown, each provided with a "select” or “unselect” flag symbolically represented by a voting square with or without an "X” to indicate whether a given component is selected or not selected for inclusion in the finished product 1106.
• the flags 1922 and 1930 for the components A and B are shown with "X”s indicating that these components are currently part of the finished product 1106.
• the flag 1928 for the component B is shown without an "X", indicating that either by default, or because of system designer intervention, this component has not been selected.
• the module is marked (in the BIOS. SCR file 3812) for mirrored placement into the desired regions.
• the linker 3600 will select a location that resides at the same address within those regions.
• step 3610 the point at which the references and definitions are actually associated and eventually linked together.
• Fig. 38 this is where, in the context of the present invention, the final choice is made to link a given call to one procedure or to another, for example; and because the process is done by the product component linker 3600 under the direct control of the macros 3806 (through the intermediary of the external and public sectors 3802 and 3804).
• system-designer-designated "intercept” externals (a substitute procedure that is to "intercept” and take over the functions of a procedure called by the source code), identified as such by the macro-generated "call” information, are linked up to the intercepting references in preference over whatever reference would have been utilized otherwise.
• a ROM stack appears as follows in assembler source code, and is generated by the macro CREATE_ROM_STACK: returnAddr:
• the LIST_ENTRY macro (Section 5.5 in the Line-by-Line Description of Macros) in this code fragment 3710 specifies and preserves the data for a list entry, the name of the entry, its sort priority (a number used to sort list entries with the same sort key) and sort key.
• the LIST_END macro 3712 (Section 5.4 in the Line-by-Line Description of Macros) ends the list entries begun by the LIST_START macro 3708 and allows multiple list entries to be specified.
• the code fragment of source code file C 3714 illustrates that multiple list entries can be specified in different source code filess that may be a parts of different components.
• the offset of the entry can be determined after the list has been sorted by multiplying the entry's index by the size 3707 of the entry. This produces the distance of the entry from the beginning of the segment.
• the computed offset value is used, along with a pointer to the list segment object.
• the segment value of the entry will be identical for all entries in the list and is determined when the list segment is placed into destined region.
• the database is used for real-time evaluation of error conditions arising during the development process.
• Current state of the art development systems do similar error checking only during the build process.
• This invention accomplishes these tasks prior to the build process in an efficient, real-time environment where the user receives immediate feedback (in most cases ⁇ 1 sec) on standard personal computer systems (Pentium 400 MHz) if an error occurs.
• the errors that can be identified include 1) unresolved dependencies, 2) calls that violate access levels such as a call from one component to a private procedure in another component. 3) Calls to procedures that are outside of the appropriate program segments (Appendix G).
• Information is also available from the configuration to provide filter searches to only include the subset of the source code library that is part of a product. For example, to search for a displayed string, it is less useful to see all instances of that string in the source code library than to see the instances actually used by the product. Reports can be generated giving the developer information such as 1) Features without hard dependencies (optional features), 2)public interfaces available, 3) options and the set values and default values, 4) Features using specified code segments, and many others.
• the OPTEXT macro declares a reference to an option from another component or feature that was declared in the component or feature's information file. Its parameters are name and an optional component name.
• the name parameter is made up of a class name, zero or more subclass names and the actual option name, seperated by periods.
• the OPTCHK macro tests the specified option (which must have been declared with a preceding OPTEXT macro) with the specified condition and value. If true, the traecodetext is executed; otherwise the falsecodetext is executed.
• Its parameters are optionname, condition keyword, value, traecodetext and an optional falsecodetext.
• the optionname parameter is made up of a class name, zero or more subclass names and the actual option name, seperated by periods.
• the condition keyword is one of LE, LT, GE, GT, NE or EQ with the usual and customary meaning.
• the value parameter is a constant.
• the traecodetext parameter contains code to be executed if the condition is true and the optional falsecodetext parameter contains code to be executed if the condition is false.
• the EXTJMP macro is implemented by invoking the BRANCH_HANDLER macro with the appropriate parameters.
• the BRANCH_HANDLER macro is used to call a public or private procedure.
• the backslash ( ⁇ ) at the end of the first line specifies line continuation.
• Its parameters are: externName (required) - Name of external procedure to be called in dot notation, e.g. "class.subclass.procedure”; branchlnstraction (required) - A call or jmp; optionalCode - Optional code to assemble, typically a jump on the carry flag set by the called procedure; register - Register containing return address offset; and component - May be used to specify the name of the component in which the procedure is defined when multiple components define the same procedureName.
• the PUBEXT macro is used by the present invention to declare the name of the public procedure that will be referenced by an Exit macro.
• the PUBEXT macro name and its parameters are scanned from the source file by the present invention.
• the information from this macro and the Entry Definition macro is used to generate a global macro variable for the procedure name in the feature include file produced by the present invention and included in each source code file that indicates what code, if any, the Exit macro should generate.
• the PUBEXT macro is used to declare an external reference to a public procedure or label. Usage: "PUBEXT memctrl.shadow.set, 1.0, OPTIONAL". Its parameters are: name - Name of procedure or label in dot notation, e.g.
• the list entry data enclosed by this listEntrySegment is merged into a single listEntrySegment when the source code files containing these segment declarations are compiled, linked, and processed by the product component linker.
• the listEntrySegment in each object file is merged into a single listEntrySegment when the object files are linked to form the component .EXE file.
• the list entry data in the listEntrySegment of each component .EXE file is merged and sorted by the BIOS Component Linker to generate a sorted list in the final ROM image with the list header specified by the LIST_CREATE macro that created the list.
• MASTER END MACRO The MASTER JiND macro ends the definition of a master index. It must appear following a MASTER_START macro call.
• the SAVEJvlASTERJNFO macro saves the keyName specified by its parameter in the special segment opened by the preceeding MASTERJSTART macro call. 6. Include Macros
• Each List must be created, once, by the owning component/feature, usign the LIST_CREATE macro (page 10). If the list is sorted using a Master Index, the Master Index file is also part of the owning component. If two Lists are created with the same name, the Binary Linker will generate an error. IST_CREATE evnodes , 1.0 , devNode istStruct

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computer Security & Cryptography (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (3)

Publications (2)

Family

ID=24118600

Family Applications (1)

Country Status (5)

Families Citing this family (10)

Citations (3)

Family Cites Families (3)

• 2001
  • 2001-03-20 EP EP01922536A patent/EP1266284A4/en not_active Withdrawn
  • 2001-03-20 JP JP2002501178A patent/JP2003535415A/ja active Pending
  • 2001-03-20 AU AU2001249327A patent/AU2001249327A1/en not_active Abandoned
  • 2001-03-20 CN CNA018094716A patent/CN1957328A/zh active Pending
  • 2001-03-20 WO PCT/US2001/009094 patent/WO2001093031A1/en not_active Application Discontinuation

Patent Citations (3)

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events