WO2007040510A2 - Parallel computing operating system and meta-operating system - Google Patents

Abstract

An operating system and operating meta-system for hyper-computers, such as computers equipped with a programmable gate IC, providing a translation system between the assembly languages of the hyper-encoders and the languages advanced programming. This operating meta-system finds application in machines for parallel processing and grid processing, as well as in the development of a "GridNet" set consisting of a MetaGrid system and a HyperNet system. Other applications include but are not limited to virtual reality, gaming, telecommunications and web browsing platforms. The computer-readable media contain instructions that are executed by a machine to cause the machine to implement the operating meta-system and other applications for hyper-computers.

Description

Parallel Computing Operating System and Meta-Qperating System

FIELD OF THE DISCLOSURE

[0001] The present disclosure relates to computer operating systems and meta-operating systems, and in particular to operating systems and meta-operating systems for special-purpose or general- purpose parallel computers, including, but not necessarily limited to,

supercomputers, cluster computers, remote grid computers, symmetric

multi-processing computers, multi-core or cell computers, nano- computers, molecular computers, genetic computers, optical computers, quantum computers, and HyperComputers™ that have a field-programmable gate array.

BACKGROUND

[0002] 0. The GridNet™

[0003] 0a. Overview

[0004] The GridNet™ incorporates hardware such as Grids and

HyperComputers™, and software such as Globus and "dot NET". The

GridNet™ includes, but is not necessarily limited to, two moieties, The MetaGrid™ and The HyperNet™. These moieties combine in The

GridNet™ to provide a digital business medium. The GridNet™ is

suitable as a replacement for the rapidly-aging Internet. Users and administrators alike may experience a sense of power and control over

i »

their own Internet-connected computer systems. Top-level GridNet™ classes may reside under the Environment::GridNet FX-OS™ code hierarchy.

[0005] 0b. The MetaGrid™

[0006] The MetaGrid™ may be thought of as the world-wide

aggregate of all "Grid" computing systems. The MetaGrid™ itself consists of (currently disparate) Grid computing networks, and categorically includes, but is not necessarily limited to, all Super Computer, Cluster, Server, and Personal Computing hardware. Grid computing networks are generally managed by "GridWare" components, in the form of software such as Globus™, Avaki™, and

Sun's Grid Engine™. However, The MetaGrid™ just as readily includes an SGI Super Computer running Irix, a Linux cluster running NPACI ROCKS, or a personal computer running Windows or Apple's OSX. All previous-existing security authentication mechanisms remain in place -

no unauthorized resource access should be enabled by installation of a MetaGrid™ system.

[0007] Individual component classes for such MetaGrid™ systems

reside under the Computer::SoftHardWare FX-OS™ hierarchy. Examples

are Computer::SoftHardWare::Grid::Globus and

Computer::SoftHardWare:: - Grid::Avaki. >

[0008] The component classes may contain not only the

corresponding GridWare command/parameter architectures, but may also include customized scripts for simplicity and transparency of MetaGrid™ access.

[0009J Oc. The HyperNet™

The HyperNet™ includes, but is not necessarily limited to, the worldwide aggregate of all "Network" data systems. The HyperNet™ may be

composed of all world data networks (as opposed to the computing networks of the MetaGrid™), and includes the World-Wide Web, The Internet, lntemet-2, and private intranets. Data networks may generally be managed by open-standards protocols and libraries such as TCP/IP

(including IPv4, IPv6, IPv9, and future versions), UDP, ICMP, or "DotGNU". However, The HyperNet™ may also include not-so-open protocol networks such as those managed by Apple's SmallTalk, a corporate virtual private network (VPN), or Microsoft's .NET platform. Like The MetaGrid™, The HyperNet™ preferably does not allow unauthorized users to gain access to previously-unavailable sensitive or

personal data. In fact, the additional security measures provided by individual GridNet™ systems should stand to significantly improve the security of networked computers.

[0010] Od. Compatibility

[0011] Software products of the present disclosure are intended

to be compatible with all major GridNet™ components. Avaki, Apple,

Microsoft, and others provide non-standard GridNet™ components. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The detailed description that follows makes reference to the noted drawings, by way of non-limiting examples of specific embodiments, in which reference numerals represent the same parts throughout the several views of the drawings, and in which:

[0013] Figure 1 is schematic flow chart of user function logic of an exemplary specific embodiment of an operating system or metaoperating system described herein.

[0014] Figure 2 is a schematic flow chart of an exemplary specific embodiment of software logic of an operating system or metaoperating system described herein.

[0015] Figure 3 is a diagrammatic representation of a machine in the form of a computer system within which a set of instructions, when executed, may cause the machine to perform any one or more of the methodologies discussed herein.

DETAILED DESCRIPTION

[0016] In view of the foregoing, the present disclosure, through

one or more various aspects, embodiments and/or specific features or sub-components, is thus intended to bring out one or more of the

advantages that will be evident from the description. The present

description makes frequent reference to FX-OS™. It is understood,

however, that FX-OS™ is merely an example of an illustrative specific embodiment while the present disclosure is directed broadly to parallel operating systems and meta-operating systems within the scope of the

disclosure. The terminology, examples, drawings and embodiments, therefore, are not intended to limit the scope of the claims.

[0017] 1. The FX-OS™ Architecture

[0018] Ia. Overview

[0019] Supercomputers, cluster computers, remote grid computers, symmetric multi-processing computers, multi-core or cell computers, nano-computers, molecular computers, genetic computers, optical computers, quantum computers, and HyperComputers™ are advanced parallel-processing computers, or computer networks, which have processors, such as Field-

Programmable Gate Array ("FPGA") micro-chips, to execute programmed instructions or operations. Special-purpose parallel computers may be designed to perform a pre-programmed set of

tasks, whereas general-purpose parallel computers may be designed to perform any programmed set of tasks. Also, general-purpose

parallel computers may be programmed to act as special-purpose parallel computers. Additionally, two or more serial computers may be

networked and programmed to operate in parallel. Accordingly,

parallel computer, or parallel computer system, may refer to any one

or more of the following: special purpose parallel computer; general

purpose parallel computer; one or more computer, any one of which at any time has the capability of performing parallel operations; and serial computers configured and programmed to perform operations in parallel.

[0020] Programs, including operating systems and metaoperating systems, that instruct a computer to perform an operation,

may be stored and distributed on a machine-readable media ("MRM") defined to include any kind of computer memory to store data and programming instructions, such as floppy disks, conventional hard disks, CD-ROMs, Flash ROMS, nonvolatile ROM, RAM, storage media, and signals containing instructions.

[0021] In accordance with various embodiments of the present disclosure, and as described in greater detail later in the present disclosure, the methods described herein are intended for operation as software programs running on a computer processor. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other

hardware devices can likewise be constructed to implement the methods described herein. Furthermore, alternative software implementations including, but not limited to, distributed processing or

component/object distributed processing, parallel processing, or virtual

machine processing can also be constructed to implement the

methods described herein. [0022] FX-OS™ provides α metα-operαting system to accommodate and utilize future GridNet™ computing platforms. FX-

OS™ may reside on top of a *NIX Operating System, incorporating its advanced security and authentication features. FX-OS™ provides a

natively programmable Operating System for Supercomputers, Clusters, Grids, and any other parallel computer hardware, already incorporating both the PThreads and Message Passing Interface (MPI) parallelization libraries. In addition to parallel computers, those skilled in the art will recognize that embodiments described in the present

disclosure may also be adapted for use with general purpose computers, such as the familiar PC or Macintosh^® computers. Accordingly, it is understood that the term "operating system" refers not only a conventional operating system but also to a meta-operating system, particularly in the claims, except where, in the specification, one or the other meaning is evident from the context.

[0023] l b. WOOP™

[0024] FX-OS™ may be at least partially written in a new dialect

of the Perl programming language, Will's Object-Operating Perl, known

as "WOOP™." WOOP™ provides a novel "over-modeling" design, giving

FX-OS™ a powerful execution architecture. Hundreds of CPML's™ (WOOP™ Classes) are built to provide as many hierarchal services as

possible, within a solid software architecture of Computers (including

Languages), Interfaces, and Environments. From "Procedural" computer programming, "Object-Oriented" programming evolved greatly during the 1990's. The effect of the

Object-Oriented paradigm on software engineering was two-sided: a greater sense of software's architectural structure was gained, while some took the concept too far and lost track of the Procedural programming roots of Object-Orientaion's heart. The classic, textbook example of Object-Orientation's negative side effects is that of the

GNU "Hurd."

[0025] Richard M. Stallman's GNU Project built the operating system utilities used by GNU/ϋnux today. However, the GNU Hurd was meant to provide an Object-Oriented, non-Linux kernel, which it has

yet to fulfill. Apparently, for a project such as a *NIX kernel, old- fashioned Procedural programming may work best. Fortunately, software engineering has now evolved past the Object-Oriented style of programming.

[0026] From Object-Oriented computer programming, at least

two further major styles were developed, with numerous sub-styles

flourishing and expiring across the Internet every day. Two new important programming styles are known as "Service-Oriented" and

"Object-Operating". Like most any other programming styles, Service-

Orientation and Object-Operation can be made to inter-operate with

one another at the library or protocol levels. [0027J Service-Oriented programming is being pioneered by, among others, Dr. Michael W. Sobolewski, currently of Texas Tech University. Service-Oriented architecture emphasizes extremely high- level GridNet™ "Services" and their relation to local operating systems. The Service-Oriented architecture has played a role in the

development of advanced GridNet™ technologies such as "Virtual Grids" and Dr. Sobolewski's SORCER™ platform.

[0028] Object-Operating software engineering may be used to develop Object-Operating architecture, which emphasizes a

comprehensive mixture of low, medium, and high-level CPML's (WOOP™ Classes), and incorporates high degrees of self-knowledge and multi-purpose functionality into FX-OS™ class hierarchies. Object- Operating architecture may be used in the development of advanced GridNet™ technologies such as The Hyper-Lafor™, SequenceL™, META™, PREKRC™, and FX-OS™ as a whole.

[0029] 1 c. The PREKRC™ Language

[0030] Specific embodiments of FX-OS™ may include several computer programming languages. One such language is the

Predicate Recursion Extensive Knowledge Representation Calculus

("PREKRC™"). PREKRC™ is an advanced programming language developed for use in FX-OS™ to represent complex GridWare and *NIX

command parameter structures. PREKRC™ may also be used for various internal FX-OS™ knowledge representation schemes. [0031] PREKRC™ defines "Data Member" and "Method" links for recursively nested CPML object instances. Using the special "_PREKRC_" keyword, the PREKRC™ interpreter knows when to

recurse itself while parsing source code. PREKRC™ resides under the Computer::Language::PREKRC FX-OS™ hierarchy. Much of PREKRC's™ functionality may be contained within the

Computer::Language::PREKRC::Parser CPML

[0032] As mentioned above, PREKRC™ may be used in several

FX-OS™ sub-systems. Examples are the Globus™ and Avaki™ GridNet™ compatibility, FX-OS™ online pricing categorization, and Unix command/parameter representation. Such FX-OS™ uses of PREKRC™ currently utilize several different versions of the PREKRC™ interpreter.

[0033] Id. JSSIM™

[0034] Figure 1 is schematic flow chart of user function logic of an exemplary operating system or meta-operating system of the present disclosure. A User enters the World Wide Web through web portal 1 10. WOOP 120 up-translates software objects 130 through Project ORBIT

Translation 140. Viva™ 150 mediates between HyperComputer™ 160

and ORBIT™ 140. The two-way arrows of Fig. 1 indicate a user function dynamic exchange in both directions for each element.

[0035] Specific embodiments of FX-OS™ may include a Web-

based graphical user interface. The appearance of the "Web shell",

JSSIM™, or the "JavaScript Scalable ImageMapper", may be fully configurable via custom "SkinSets" and menus. The user interface may be built using standard CGI, XML, and JavaScript methods. JSSIM™ is

built using a combination of the Perl and JavaScript computer programming languages known as JavaPerlScript™. The JSSIM user interface is dynamically and automatically generated by JavaPerlScript™ and other FX-OS™ sub-components.

[0036] JSSIM™ resides, preferably, under the

Computer::Language::JavaPerlScript,

Computer::Language::JavaScript::Generator::JSSIM and

Computer::Language::XML::Generator::JSSIM FX-OS™ hierarchies. JSSIM™ accepts customized SkinSet configuration files, via the Perl "AppConfig" library. The AppConfig SkinSet files may be handled by XML::Generator::JSSIM::Configurator. A JavaScript image map may be created by JavaScript::Generator::JSSIM::lmageMap, which itself may be embedded within XML::Getιerator::JSSIM. The actual JSSIM™ JavaScript functions are dynamically generated by JavaScript::Generator::JSSIM::Functions and

JavaScript::Generator::JSSIM::PostFunctions. All of this may be further nested within a borderless frame-set, itself automatically generated by

several different members of the XML::Generator::JSSIM hieracrhy.

SkinSet and user commands may be passed through JSSIM™ and FX-

OS™ via hidden HTML form parameters. JSSIM™ provides a basis upon which to build FX-OS™ Web interfaces. [0037] 2. StαrBridge HyperComputers™

[0038] 2α. Overview

[0039] StαrBridge Systems of Midvαle, Utah a manufacturer of computing hardware, known as HyperComputers™. Three interconnected components power the HyperComputer™ systems: the

FPGA micro-chips, the HyperComputer™ hardware architecture, and the Viva™ assembly language. HyperComputers™ are recognized by those skilled in the art to be significantly faster than any other computing platform.

[0040] 2b. FPGA Micro-Chips

[0041] FPGA's, or Field-Programmable Gate Array micro-chips,

are the hardware heart of the HyperComputer™ systems. Instead of today's one-at-a-time serial micro-chips (Intel Pentium™, AMD Athlon™, Motorola PowerPC™, etc.), FPGA all-at-once parallel micro¬

chips are dynamically reconfigurable on a single-logic-gate level. Rather than utilize only a fraction of its available logic gate array, FPGA chips change themselves thousands of times per second to maximize

use of ALL its available logic gates. FPGA's will physically adapt their

own hardware architecture to each and every individual algorithm

they are given to execute, providing processing speeds (easily) millions

or billions of times faster than Intel or AMD-style serial micro-chips. Before StarBridge, FPGA's had never been used as parallelized

computer processors, and were only found in highly specialized, industry-specific field testing equipment (thus the name "Field"

Programmable Gate Array). StarBridge HyperComputer™ systems use

FPGA chips manufactured by Xilinx, Inc., the world's leading manufacturer of FPGA technologies.

[0042] 2c. The HyperComputer™ Architecture

[0043] StarBridge Systems, Inc. has developed self-similar FPGA hardware architecture. Known as a "HyperComputer™", the FPGA architecture uses design theories found in nature's beautiful fractal mathematics patterns. Generated by iteratively computed solutions to complex number equations involving the domain of imaginary numbers, fractals are generally represented as astoundingly intricate graphical sets of self-repeating, recursive geometric designs. Each piece of a fractal can be viewed as a smaller (or larger) scaled version of some other piece of itself. Thus, fractals are considered to be similar

to themselves or "self-similar". In the same way, the HyperComputer™ architecture may be designed as nested, self-similar FPGA scheduling

and execution hardware.

[0044] In other words, the HyperComputer™ architecture may be

thought of as a fractal computer, because parts of the

HyperComputer™ hardware are self-similar to other parts of itself. By its

very nature, the fractal HyperComputer™ architecture is both

extremely elegant and powerful.

[0045] 2d. The Viva™ Assembly Language [0046] StαrBridge Systems has also developed the

HyperComputer™ assembly language known as Viva™. Prior to

adoption by StarBridge, FPGA's were not used as general purpose processors and had neither an architecture (HyperComputers™, see above), nor a natively parallel binary-level programming language (Viva™).

[0047] Previously, when used only in custom field testing equipment, an FPGA was programmable using only the older hardware representation languages of Verilog or VHDL. For every

individual hardware design a VHDL or Verilog source was required, and there was no mechanism for automated, parallel reconfiguration.

[0048] With the Viva™ assembly language, FPGA architecture

(HyperComputer™) now has the ability to be programmed with reconfigurable, parallel algorithms. That is, FPGA architecture is reprogrammable on-the-fly. Using Viva's™ graphical hardware visualization, individual core libraries may be programmed into the

HyperComputer™ hardware. Although only a l's-and-0's assembly language, Viva™ is a versatile and capable software solution for low-

level FPGA programming. When Viva™ is combined with the high-level

computer languages of FX-OS™, a complete GridNet™ /

HyperComputer™ programming system may be created.

[0049] 3. Hyper-Source™ Applications [0050] FX-OS™ facilitates program execution on Super Computer,

Cluster, and Grid computer systems. To extend the functionality of FX- OS™ to include support for the StarBridge HyperComputing™ platform, a sequentially-implemented line of FX-OS™ software components is contemplated. Hyper-Source™ applications are contemplated to include: The Hyper-Lator™, The Hyper-Engine™, The Hyper-WWW™,

Hyper-VR™, and The Hyper-Phόn™. In addition, a 3-D video game application may be run with The Hyper-Engine™ on the Hyper-WWW™. [0051] 4. The Hyper-Lator™

[0052] 4a. Overview

[0053] Figure 2 is a schematic flow chart of software logic of an exemplary operating system of the present disclosure. An FX-OS™ component may be a translation system for the HyperComputer™ hardware, known as The Hyper-Lator™. The Hyper-Lator™ may utilize StarBridge's Viva™ assembly language, in combination with additional

FX-OS™ programming languages, such as SequenceL™ and META™. With the PREKRC™ language for GridNet™ compatibility, a four- language translation system may be provided. The system allows brief

and elegant solutions to be implemented in higher-level languages to

then be translated downward into the low-level language Viva™. The

Hyper-Lator™ may also be referred to herein as Project ORBIT™ (the

"Operative Resource Batch Intellect Translation" system"). [0054] As depicted by Figure 2, there are four primary components of The Hyper-Lator™: SequenceL™ to META™ Abstraction (upward translation) 210, Viva™ CPML modeling 220, META™ to Viva™

object lnstraction (downward translation) 230, and Viva™ object to

Viva™ source Generation 240. Each of the four components is discussed in further detail below.

[0055] 4b. The SequenceL™ Language & META™ Abstraction 1 10

SequenceL™ is a computer programming language originally

designed and created by Dr. Daniel E. Cooke, currently of Texas Tech University. SequenceL™ is a high-level, functional language with a specialized programming grammar and execution strategy capable of Automated, Natural Parallelization.

[0056] Before FX-OS™, no production-grade implementation of

SequenceL™ existed. Now, with FX-OS™, SequenceL™ may use customized granularity execution optimizations, previously unavailable

anywhere. All data manipulation in SequenceL™ is performed within a special memory table, known as a "Tableau."

[0057] Al! operation/operand "Sequences" residing within a

Tableau may be executed in parallel. Sequencers™ specialized

execution strategy is comprised of three main algorithmic bodies:

Consume, Simplify, Produce (CSP). Although Consume and Produce

are full algorithms of themselves, within each Simplify step are three

sub-steps: Normalize, Transpose, and Distribute (NTD). With this special execution strategy, much, if not all, of the complexity in representing a specific algorithm's solution is removed. Accordingly, Sequence!.™ is ideal for use in a highly-distributed and massively parallelized

computational environment, such as The GridNet™ with HyperComputer™ hardware running FX-OS™. FX-OS™ Sequence!.™ Evaluators already exist for Supercomputer, Grid, and Cluster systems.

Much of Sequence!.™ resides under the Computer::Language::Se- quenceL and Math::Chunk FX-OS™ hierarchies.

SequenceL::Parser::YYPar-ser and SequenceL::Lexer::YYLexer converts pure SequenceL™ source code into live WOOP™ objects, preceded by an optional PreParser.

[0058] All Operation and Constant CPML's generated by the

Lexer and Parser originate from the Math::Chunk hierarchy. This YYParser may be written from a customized SequenceL™ grammar. SequenceL::lnterpreter may then select a Granulator, select an Evaluator, and relegate its Tableau to be evaluated.

[0059] SequenceL::Evaluator contains the "CSP ()" method, as

well as the actual "consume()" method called by CSP().

SequenceL::Evaluator also contains the "NTD()" method, possibly

called during the Simplify algorithmic body. The

Math::Chunk::Operation CPML's contain the "transpose()" and

"distributed" methods. The "simplifyO" and "produce()" methods exist in multiple forms, as per their ownership by one of several possible Evaluator CPML's.

[0060] SequenceLiEvaluatoπ±ocakSequential provides a real

Evaluator, but does not actually execute on multi-processor systems. SequenceL::Evaluator::Local::Threaded does utilize multi-processor

systems. The Perl PThreads library is used by this SequenceL™ Evaluator, which is designed to work on any shared-memory system, from dual- or quad-chip desktop workstations to SGI, IBM, and Cray Supercomputers.

[0061] Additionally, SequenceL::Evaluator::Remote::GridNet will execute on non-local systems via the distribution mechanism of the SequenceL::Evaluator::Remote::Shipper. The Shipper::MPI CPML

automates remote algorithm and data transmission via one of several possible "ship()" methods, such as over a networked file-system or through network sockets. The Shipper::MPI CPML then calls an externally-written FX-OS™ "Shipper Script", contained within

"mpi_shipper.pl". The Shipper Script knows how to recognize if it is a Parent or Child compute node, such as may be found in a Linux Cluster

or a computational Grid network. The Shipper Script receives its

configuration from the Shipper::MPI CPML, and recursively calls a new

copy of the SequenceL™ Interpreter to execute on the remote

compute node. [0062] Multi-Level Parallelisms are intrinsic to the SequenceL™ implementation architecture, as nested outputs are automatically collated, stitched back together, and returned to their Parent node. Note that entire Grids, Supercomputers, and Clusters may each be considered only a single computational node as far as the Shipper::MPI

CPML is concerned. The execution architecture is powerful, combining all forms of parallel distribution into a single, Automatic, Natural computer programming interface through FX-OS™.

[0063] Because the Viva™ language provides a parallel

distribution mechanism, it may be a relatively straightforward, albeit complex, task to implement HyperComputer™ compatibility into FX- OS™. The first step of The Hyper-Lator™ execution path abstracts live SequenceL™ objects into their equivalent META™ counterparts. Each individual SequenceL™ Function, Operation, and Operand may be

natively translatable into a META™ object because both languages are built using component CPML's residing under the Math::Chunk hierarchy. Actual "abstractf)" methods are contained within the individual Math::Chunk CPML's.

[0064] On-the-fly embodiments of the "SequenceL™ to META™

abstraction" are contemplated to enable not only compilation onto

the HyperComputer™ hardware, but even real-time HyperComputer™ interpretation of freshly-written FX-OS™ parallel code, potentially quite useful for testing, debugging, and rapidly prototyping parallel FX-OS™ applications.

[0065] 4c. WOOP™ Viva™ CPML Model

[0066] The second part 120 of The Hyper-Lator™ provides a CPML model of the major programming components in the Viva™ assembly language. Like SequenceL™ and META™, a WOOP™ model of Viva™ includes CPML's from the Math::Chunk hierarchy. This allows live META™

objects to be directly translated into a form of pseudo-Viva™ code. An advantage of this approach is that it enables a deep understanding of the algorithmic architecture implicit in assembly programs written using

Viva™.

[0067] Much of the WOOP's™ Viva™ model resides under

Computer::Lan-guage::Viva and, as mentioned above, Math::Chunk, as well. The Viva™ model hierarchy may contain CPML's representation central Viva™ components such as CoreLib™, along with pre-written Viva™ assembly libraries such as a hand-made encryption or compression algorithm. The Computer::Language::Viva hierarchy may

be populated with Viva™ components to enable simultaneous co-

development of the lnstraction and code Generation portions of The

Hyper-Lator™.

[0068] 4d. The META™ Language & Viva™ lnstraction

[0069] Another FX-OS™ programming language is the Modular

Extendable Translation Algorithms ("META"™). META™ provides the Metα language that provides an architecture of Abstraction (upward translation) and lnstraction (downward translation) methods for potentially any set of languages, both natural and computer. META™ focuses, for instance, on the representation of automatically parallelized meta-algorithms in specific embodiments of FX-OS™.

[0070] lnstraction methods for the Viva™ language as a core component of The Hyper-Lator™ are applicable to SequenceL™ source code. Using META™, direct translation / compilation of SequenceL™ and future parallel architectures are, for the first time,

now possible.

10071] Additionally, the present disclosure contemplates that

META™ may act as an intermediate, language-independent "pseudo¬

code" representation mechanism.

[0072] Most of META™ resides under: the

Computer::Language::META and Math::Chunk FX-OS™ hierarchies. The

software architecture of META™ provides generalized components commonly found throughout the wide variety of today's many types of

programming languages. The "common components" include Interpreters, Parsers, Lexers, Functions, Methods, Variables,

DataMembers, Operations, Operands, Constants, Keywords, Tokens, and so forth. A good, well-implemented example of one such common

component is found in Computer::Language::META::Sym-bolTable. [0073] SequenceL™ does not use α one-time, Sequencer- specific Symbol Table, but instead uses a specially configured instance of META's™ Symbol Table. The architectural nature of META™ requires its extendablilty for future language incorporation. As mentioned above, the actual "abstractQ" and "instractQ" methods are contained

within the individual Math::Chunk Operation and Operand CPML's. The third part 130 of The Hyper-Lator™ uses lnstraction methods to translate from live META™ objects (see 4b, above) down to the WOOP™ Viva™ model (see 4c, above). The "lnstraction step" will take place after at least one initial SequenceL™ interpretation (necessary to pre-determine parallelized algorithm structures), "On-the-fly" (during actual SequenceL™ interpretation) embodiments, however, are contemplated as mentioned above.

[0074] 4e. Viva™ Source Code Generation

[0075] The fourth component 140 of The Hyper-Lator™ involves the generation of actual Viva™ source code. Much Hyper-Lator™ component 140 may be handled by "generate()" methods found

within many of the individual CPML's created by the WOOP™ Viva™

model (from 4c above). An algorithm's WOOP™ Viva™ model would

systematically "generate ()" its corresponding portions of actual,

proprietary format Viva™ source code. The form of these "generate()" methods is reminiscent of older compiler systems built to generate stαndαrd-formαt sequential assembly code for x86 or other simple hardware architectures.

[0076] Algorithm training, granularity function discovery, and

alternative parallelisms are all possible candidates for optimizing FX-OS

™ components written using The Hyper-Lator™.

[0077J 5. The Hyper-Engine™

[0078] 5a. Overview

[0079] The "Hyper-Engine™" provides FX-OS's™ 3-D rendering system. All 3-D graphics systems generally fall into two categories:

"rasterization" engines, and "ray tracing" engines. Rasterization engines can be quite fast, yet render images that, upon scaling, reveal blocky pixelization, and often feature cartoonish graphics. Rasterization engines are used in today's video games to provide real-time, responsive 3-D gaming environments.

[0080] Ray tracing engines (such as Renderman^®, POVray^®, and

Virtualight®) provide "hyper-realistic" scene quality and resolution,

often indistinguishable from an actual, 3-D physical environment. Ray tracing, however, involves extremely computationally complex

rendering algorithms, often requiring days or weeks on modem

Supercomputer systems to produce a single still-frame in a complex

ray-traced environment.

[0081] High-resolution, complex ray tracing is currently limited to

those with great financial resources, such as Hollywood movie studios, routinely purchasing time at Supercomputer facilities to render cinematic quality 3-D special effects.

[0082] 5b. TrayRacer™

[0083] Due to previously unavailable processing requirements, no current graphics system is capable of large scale, real-time ray tracing.

Fortunately, FX-OS™ contains a fully-integrated 3-D ray tracing engine, known as "TrayRacer™". there-writing the computational kernel of TrayRacer™ using The Hyper-Lator™ translation system provides a realtime, high-resolution ray tracing engine. .Executing directly on the

HyperComputer™ hardware. The Hyper-Engine™ is a general-purpose 3-D rendering algorithm that runs natively on StarBridge computer systems. The Hyper-Engine™ provides the basis for FX-OS™ Virtual Reality applications, including video games, scientific models, and

industrial R&D.

[0084] The central rendering architecture of TrayRacer™ has

been implemented for The Hyper-Engine™. Most of the TrayRacer™ software modules reside under the Computer::Model::TrayRacer, Energy::Light, Math::Geometric, and Math::Chυnk::Constant::Vector

FX-OS™ hierarchies. The primary "render()" method may be contained

within the Computer::Model::TrayRacer module itself, along with

"determine_color()", "find_soonest_inter-section(}", and other key

rendering functions. Individual "intersectQ" methods are contained within each member of the Math::Geometric::Shape, FX-OS™

hierarchy.

[0085] "Cross products", "normalization", and other basic matrix manipulations are handled under the Math::Chunk::Constant::Vector hierarchy. Light component and colour magnitudes are stored inside members of Energy::Light::Colour and Energy::Light::Source. The central

"render()" function may be re-written using The Hyper-Lator™.

Additionally, individual "intersectf)" and "special effects" methods embodiments are contemplated for Hyper-Lator™ re-implementation.

Specific embodiments of the Hyper-Engine™ provide stereo-scopic rendering capabilities, for use on "real 3-D" display mechanisms, most notably and importantly VR glasses or goggles. This may be achieved, for example, by simply modeling two TrayRacer::Camera objects, like a human's two eyes, instead of only one. Further alternative

embodiments use FX-OS™ for optional glove or suit interface peripherals, to provide realistic "gloves and goggles Virtual Reality"

experience.

[0086] 6. The TimeLords™ Trilogy

[0087] 6a. Overview

[0088] An application of the 3-D rendering capabilities of the

present disclosure provides a series of online, massively multiplayer

"time-travel" video games, known as "The TimeLords™ Trilogy". A

combination of the ever-increasingly popularized action/adventure and strategy/fantasy gaming genres, The TimeLords™ Trilogy will immerse the player in a fully-interactive, photo-realistic VR environment, spanning across a broad range of 3-D "Game Worlds". These Game Worlds include both historical settings such as "Ancient Egypt" & "The Wild West"; modern-day settings such as the commercial "Space Race" & special-combat service in "The War on Terror"; and

futuristic settings such as "Lunar Colonization" & "Mankind's Greatest Discovery: Hyper-Galactic Travel".

[0089] 6b. Game Setup

[0090] FX-OS™ users who wish to play one of The TimeLords™ VR games may subscribe to a Gaming Subscription Service and create a

TimeLords™ "avatar" character to represent themselves in the online Game Worlds. Players must abide by the "Laws of Time Travel", may pursue and arrest members of World Crime League™ opposition teams, and may access the advanced assistance of TimeLord™

Central's artificial intelligence persona, known as "HORUS™".

[0091] 6c. Game-Play

[0092] Competition in the TimeLords™ Game Worlds is multi¬

dimensional: players may spend their time fighting or gambling in one

particular Game World, participate in sub-storyline "Time Quests",

engage in direct battle with the World Crime League™, or forge un-

chartered gaming territory with their own online game teams and

home-spun, inventive plot twists. Ultimately, TimeLords™ game play is open-ended and ever-evolving. As more players purchase accounts with the FX-OS™ Gaming Subscription Service, new team alliances and rivalries emerge, and new game-wide championship teams rise and fall from dominance as Game Leader. Interaction between TimeLords™ Game Worlds and The Hyper-WWW™ is also contemplated, where popular websites such as Google™ and eBay™ become a real part of the imaginary TimeLords™ game-play. .

[0093] 6d. Design and Implementation

[0094] Technical development of The TimeLords™ Trilogy video

games relies upon the real-time ray tracing abilities of The Hyper- Engine™. To enable high-frame rate online game delivery to users with moderate- to low-bandwidth Internet connections, FX-OS™ invokes real-time image codecs utilizing the amazing abilities of Wavelet-based compression algorithms. VR video Wavelet compression occurs in parallel on the HyperComputer™ hardware, and may be contained under the Math::Chunk::Operation::Codec FX-OS™ code hierarchy.

[0095] On the user end, Wavelet decompression takes place in a

Java interface applet through the FX-OS™ Web-based online interface. TimeLords™ Game World models, including buildings, craft,

and environmental components, reside under the Complex::Location

FX-OS™ hierarchy. Game World and avatar models may be created

using 3-D modeling suites such as Blender™ or 3D Studio Max™. Models may then be exported using one of several possible 3-D file formats, to be imported directly into The Hyper-Engine™ rendering system. 10096] 7. The Hyper-WWW™

[0097] 7a. Overview

[0098] The Hyper-Engine™ provides a unique new way to

interface with the World-Wide Web, known as "The Hyper-WWW™". Like older concepts such as VRML websites, The Hyper-WWW™ may not only be a medium for viewing new types of 3-D Web content, but also

a method for viewing and interacting with existing Web content. Initially, The Hyper-WWW™ converts key search engines. Web portals, and commercial websites, such as Google™, Yahoo!™, and Amazon™ to HyperComputing™ aplications. Using The Hyper-Engine™, custom VR interfaces for each website may be created; examples range from a "virtual auction block" for eBay™, to "virtual bookshelves" for Amazon™. A popular interface may be the "virtual shopping mall",

featuring not only JC Penney and Sears, but also a department-store style environment for Google™ itself.

[0099] 7b. Example: Google™

[0100] Google™ is a top-level, generalized search engine. Its VR

interface through The Hyper-WWW™ remains generic - similar to its

traditional interface. A Google™ VR interface as simple as a 3-D

Google™ logo accepting voice-commanded search patterns, which could return a 3-D roster of the top search results, is contemplated. More advanced Google™ interfaces incorporate automatic page rendering for search results not yet fully converted to work natively with

The Hyper-WWW™ VR system. The Hyper-WWW™'s Google™ enables a "location" at the above-mentioned "virtual shopping mall", complete with a "virtual concierge" to personally assist the user in his or her particular search for online Web content.

[0101] 7c. Unifying Interface

[0102] Like TimeLord's™ Game Worlds, individual conversion jobs for existing websites moving onto The Hyper-WWW™ reside mostly under the Complex::Location FX-OS™ hierarchy. Also, 3-D models for The Hyper-WWW™ are generated in the same way as any others using

The Hyper-Engine™: by using a 3-D graphics suite like Blender™. [0103] 8. Hyper-VR™

[0104] Hyper-VR™ itself may not be a single Hyper-Source™

application, but rather an entire sub-suite of software application. Like The Hyper-WWW™ and TimeLords™ video games, much of the 3^rd

party Hyper-VR™ applications may reside under the "Complex" FX-

OS™ hierarchy. Other embodiments include heads-up display methods, holographic projection, and "3-D printing" textured-surface

solid-matter model production. These and other emerging scientific

applications may be used in conjunction with any number of 3rd-party

Hyper-VR™ FX-OS™ software products.

[0105] 9. The Hyper-Phόn™ [0106] The Hyper-Phόn™ provides α cellular/satellite telephone incorporating FX-OS™ and personal HyperComputer™ hardware into its internal manufacture. The Hyper-Phόn™ provides broadband Internet/GridNet™, personal digital assistant (PDA) features, and a

built-in digital video camera. The Hyper-Phόn™ runs FX-OS™ and embedded Linux on HyperComputer™ hardware. Users may purchase portable gloves, goggles, and other peripheral devices utilizing technology such as the Bluetooth™ wireless standard. Models of The

Hyper-Phόn™ incorporate a second built-in digital video camera, enabling 3-D image capture. Utilizing The Hyper-Phόn™ with wireless gloves & goggles, and the dual-camera 3-D video system, users access full Virtual Reality video conferencing capabilities. Each user's 3-D image may be captured in real-time by their own Hyper- Phόn™. Users

meet in a "virtual boardroom" or other digital meeting environment, and speak and gesture to each other face-to-face, as it were, through their wireless glove and goggle peripherals.

[0107] Figure 3 is a diagrammatic representation of a machine in

the form of a computer system 300 within which a set of instructions,

when executed, may cause the machine to perform any one or more

of the methodologies discussed herein. In some embodiments, the

machine operates as a standalone device. In some embodiments, the

machine may be connected (e.g., using a network) to other machines.

In a networked deployment, the machine may operate in the capacity of α server or α client user machine in server-client user network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may comprise a server computer, a client user computer, a personal computer (PC), a tablet PC, a set- top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a mobile device, a palmtop computer, a laptop computer, a desktop computer, a personal digital assistant, a communications device, a

wireless telephone, a land-line telephone, a control system, a camera, a scanner, a facsimile machine, a printer, a pager, a personal trusted device, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. It will be understood that a device of the present disclosure includes broadly any electronic device that provides voice, video or data communication. Further, while a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines

that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein..

10108] The computer system 300 may include a processor 302

(e.g., a central processing unit (CPU), a graphics processing unit (GPU),

or both), a main memory 304 and a static memory 306, which communicate with each other via a bus 308. The computer system 300 may further include a video display unit 310 (e.g., a liquid crystal display (LCD), a flat panel, a solid state display, or a cathode ray tube (CRT)). The computer system 300 may include an input device 312

(e.g., a keyboard), a cursor control device 314 (e.g., a mouse), a disk drive unit 316, a signal generation device 318 (e.g., a speaker or remote control) and a network interface device 320.

[0109] The disk drive unit 316 may include a machine-readable

medium 322 on which is stored one or more sets of instructions (e.g., software 324) embodying any one or more of the methodologies or functions described herein, including those methods illustrated in herein above. The instructions 324 may also reside, completely or at least partially, within the main memory 304, the static memory 306, and/or within the processor 302 during execution thereof by the computer

system 300. The main memory 304 and the processor 302 also may constitute machine-readable media. Dedicated hardware implementations including, but not limited to, application specific integrated circuits, programmable logic arrays and other hardware

devices can likewise be constructed to implement the methods described herein. Applications that may include the apparatus and

systems of various embodiments broadly include a variety of electronic and computer systems. Some embodiments implement functions in

two or more specific interconnected hardware modules or devices

with related control and data signals communicated between and through the modules, or as portions of an application-specific integrated circuit. Thus, the example system is applicable to software, firmware, and hardware implementations.

[0110] In accordance with various embodiments of the present disclosure, the methods described herein are intended for operation as

software programs running on a computer processor. Furthermore, software implementations can include, but not limited to, distributed processing or component/object distributed processing, parallel processing, or virtual machine processing can also be constructed to

implement the methods described herein.

[0111] The present disclosure contemplates a machine readable medium containing instructions 324, or that which receives and executes instructions 324 from a propagated signal so that a device connected to a network environment 326 can send or receive voice, video or data, and to communicate over the network 326 using the instructions 324. The instructions 324 may further be transmitted or received over a network 326 via the network interface device 320.

[0112] While the machine-readable medium 322 is shown in an

example embodiment to be a single medium, the term "machine-

readable medium" should be taken to include a single medium or

multiple media (e.g., a centralized or distributed database, and/or

associated caches and servers) that store the one or more sets of

instructions. The term "machine-readable medium" shall also be taken

to include any medium that is capable of storing, encoding or carrying α set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to: solid-state memories such as a memory card or other package that houses one or more read-only (non-volatile) memories, random access memories, or other re-writable (volatile) memories; magneto-optical or optical medium such as a disk or tape; and carrier wave signals such as a signal embodying computer instructions in a transmission medium;

and/or a digital file attachment to e-mail or other self-contained information archive or set of archives is considered a distribution medium equivalent to a tangible storage medium. Accordingly, the disclosure is considered to include any one or more of a machine- readable medium or a distribution medium, as listed herein and including art-recognized equivalents and successor media, in which

the software implementations herein are stored.

[0113] The illustrations of embodiments described herein are intended to provide a general understanding of the structure of various

embodiments, and they are not intended to serve as a complete

description of all the elements and features of apparatus and systems

that might make use of the structures described herein. Many other

embodiments will be apparent to those of skill in the art upon reviewing the above description. Other embodiments may be utilized and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this

disclosure. Figures are merely representational and may not be drawn to scale. Certain proportions thereof may be exaggerated, while others may be minimized. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

[0114] Although the present specification describes components and functions implemented in the embodiments with reference to particular standards and protocols, the disclosure is not limited to such standards and protocols. Each of the standards for Internet and other packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP)

represent examples of the state of the art. Such standards are periodically superseded by faster or more efficient equivalents having essentially the same functions. Accordingly, replacement standards and protocols having the same functions are considered equivalents.

[0115] Although specific embodiments have been illustrated and

described herein, it should be appreciated that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any

and all adaptations or variations of various embodiments.

Combinations of the above embodiments, and other embodiments not specifically described herein, will be apparent to those of skill in the

art upon reviewing the above description. 10116] The Abstract of the Disclosure is provided to comply with

37 C. F. R. § 1.72(b), requiring an abstract that will allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In addition, in the foregoing Detailed

Description, it can be seen that various features are grouped together in a single embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than

are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment.

[0117] Although the present description makes reference to

several exemplary embodiments, it is understood that the words that have been used are words of description and illustration, rather than

words of limitation. Changes may be made within the purview of the

appended claims, as presently stated and as amended, without departing from the scope and spirit of the disclosure in all its aspects.

Although the description makes reference to particular means,

materials and embodiments, the disclosure is not intended to be limited

to the particulars disclosed; rather, the disclosure extends to all functionally equivalent technologies, structures, methods and uses such as are within the scope of the appended claims.

Claims

I claim:

1. A GridNθt, the GridNet comprising: a MetaGrid; and

a HyperNet.

2. The GridNet of claim 1 , wherein the MetaGrid comprises a global computer software network upon which communicates, executes,

translates, interprets, compiles, or assembles a heterogeneous grid of either serial or parallel computer hardware.

3. The GridNet™ of claim 1, wherein the HyperNet™ comprises a global computer hardware grid upon which communicates, executes,

translates, interprets, compiles, or assembles a heterogeneous network of either serial or parallel computer software.

4. A machine-readable medium having instructions stored therein that, when executed by a machine, cause the machine to provide an operating system for a parallel computer, the parallel computer

optionally comprising at least one pre-loaded low-level computer

programming language that encodes instructions executed by the parallel computer.

5. The machine-readable medium of claim 4, wherein the

operating system comprises:

at least one a low-level computer programming language

that encodes instructions executed by the parallel computer; α communication, execution, translation, interpretation, compilation, or assembly system that mediates between at least one higher-level computer programming language and at least one low-

level computer programming language; and at least one higher-level computer programming tor programming the parallel computer, wherein the higher-level program is executed by at least one low-level computer programming language as mediated by the communication, execution, translation, interpretation, compilation, or assembly system so that the parallel computer performs a programmed operation.

6. The machine-readable medium of claim 5, wherein the operating system comprises FX-OS.

7. The machine-readable medium of claim 5, wherein at least one

low-level computer programming language comprises Viva™.

8. The machine-readable medium of claim 5, wherein the communication, execution, translation, interpretation, compilation, or

assembly system comprises ORBIT.

9. The machine-readable medium of claim 5, wherein the

communication, execution, translation, interpretation, compilation, or

assembly system further comprises a Hyper-Lator.

10. The machine-readable medium of claim 5, wherein at least one

higher-level computer programming language comprises WOOP™.

1 1. The mαchine-reαdαble medium of claim 5, wherein at least one higher-level computer programming language or languages further comprises SequenceL

12. The machine-readable medium of claim 5, wherein at least one

higher-level computer programming language or languages further comprises PREKRC.

13. The machine-readable medium of claim 5, wherein at least one higher-level computer programming language or languages further comprises META.

14. The machine-readable medium of claim 5, wherein the parallel computer comprises a supercomputer of at least one set of at least two micro-chips operating in parallel.

15. The machine-readable medium of claim 5, wherein the parallel computer further comprises a cluster computer of at least one set of at least two computers operating in parallel.

16. The machine-readable medium of claim 5, wherein the parallel computer further comprises a remote grid computer of at least one set of at least two remote computers operating in parallel.

17. The machine-readable medium of claim 5, wherein the parallel

computer further comprises a symmetric multi-processing computer of

at least one set of at least two micro-chips operating in parallel.

18. The machine-readable medium of claim 5, wherein the parallel computer further comprises a multi-core or cell computer of at least one set of at least two micro-chip computational cores operating in parallel.

19. The machine-readable medium of claim 5, wherein the parallel computer further comprises a nano-computer.

20. The machine-readable medium of claim 5, wherein the parallel computer further comprises a molecular computer.

21. The machine-readable medium of claim 5, wherein the parallel computer further comprises a genetic computer.

22. The machine-readable medium of claim 5, wherein the parallel computer further comprises an optical computer.

23. The machine-readable medium of claim 5, wherein the parallel

computer further comprises a HyperComputer.

24. The machine-readable medium of claim 23, wherein the

HyperComputer comprises a field-programmable gate array microchip.

25. The machine-readable medium of claim 23, wherein the

HyperComputer further comprises a fractal architecture.

26. The machine-readable medium of claim 5, wherein the

instructions further cause the machine to provide a user interface with

the parallel computer.

27. The machine-readable medium of claim 26, wherein the user

interface is automatically or dynamically generated.

28. The machine-readable medium of claim 26, wherein the user interface is remotely accessible.

29. The machine-readable medium of claim 26, wherein the user interface is command-line or text-based.

30. The machine-readable medium of claim 26, wherein the user interface is graphical.

31. The machine-readable medium of claim 26, wherein the user interface is 3-dimensional.

32. The machine-readable medium of claim 26, wherein the user interface is Web-based or accessible through a Web browser.

33. A machine-readable medium having instructions stored therein that, when executed by a machine, cause the machine to provide an FX-OS 3-dimensional digital graphics rendering system, the system

comprising TrayRacer.

34. The machine-readable medium of claim 33, wherein the 3- dirmensional graphics rendering system further comprises a Hyper- Engine.

35. The machine-readable medium of claim 33 that, when executed

by a machine, cause the machine to provide an FX-OS digital gaming

system, the system comprising a Hyper-Engine.

36. The machine-readable medium of claim 33, wherein the gaming

system supports multi-player online or Web-based gaming.

37. A mαchine-reαdαble medium having instructions stored therein that, when executed by a machine, cause the machine to provide a World Wide Web browser, wherein the browser supports FX-OS.

38. A machine-readable medium having instructions stored therein that, when executed by a machine, cause the machine to provide a virtual reality environment, wherein the environment supports FX-OS.

39. The machine-readable medium of claim 38, wherein the virtual reality environment comprises a Hyper-WWW.

40. The machine-readable medium of claim 38, wherein the virtual reality environment further comprises a Hyper-VR.

41. A telecommunications terminal, the terminal comprising a

machine-readable medium having instructions stored therein that, when executed by a machine, cause the machine to perform telecommunications functions, wherein the machine-readable medium supports FX-OS.

42. The machine-readable medium of claim 41, wherein the telecommunications terminal comprises a Hyper-Phόn.

43. A machine-readable medium having instructions stored therein

that, when executed by a machine, cause the machine to run FX-OS.

44. The machine-readable medium of claim 43, wherein the medium

comprises a solid state medium.

45. The machine-readable medium of claim 43, wherein the medium

comprises a magnetic medium.

46. The mαchine-reαdαble medium of claim 43, wherein the medium comprises an optical medium.

47. The machine-readable medium of claim 43, wherein the medium comprises a propagated signal.

48. A programmable machine capable of parallel processing, the machine comprising a machine-readable medium having instructions stored therein that, when executed by the machine, cause the machine to run FX-OS.