STEX FCX Reality Compilers [ FCX Programing Language ] - For Dynamic System Programing
Reality Compilers are a Special Type of Compiler that can can be used to Facilitate
Building of Robust, Complex and General Purpose Software systems like - Next Generation
Operating Systems, Network Protocols, Games Development, Enterprise Control Systems
& Realistic Artificial Intelligence Systems. The FCX compiler uses a High Level
programing Language called FCX. The Reality Compiler is Based on the Principle foundation
of "Intelligent Design" to Create a High Performance Robust Software Systems for
a Variety of Proprietary Platforms like Power - AIX / X86 Windows, SPARC - Solaris
etc. These Compilers ease Software Development/Game Development processes and enable
Cross Platform porting of Software - "Write Once, Run on any System". The Compilers
May Fulfil the Following Intelligent Design Properties:
- Visual Intutive Programing with a Number of Programing Models.
- Object Life Cycle Model - Used to create,destroy and Clone Objects.
- Object Data Model Programing - Consists of Object Data Points and [ 1] Primitive
Datatypes like Int, Float, String, Boolean, Date time etc. 2] Abstract Datatypes
like: Array, Linked List, Lists, Stacks, Queues, Trees, Indexes. It may Include
Other special Data Types that allow easy System Software Development.
- Freescaling Structured Object List[] - Objects with Multiple columns and Dynamic
Column datastore. [ Freescaling Data without creation of an additional object record
]
- 3D Array Object Data type - To Store Custom Datapoints like X,Y,Z Pixel coordinates,
Lighting, Colour etc.
- Object Pattern Data Type[], String Pattern Data Type [] - To Store Patterns of Data.
- Time Stamp Datatype[] - a Dynamic Array of Time Stamps that are auto generated and
Cannot be changed.
- Object State Stamp[] - Can be used to save the state of the current Object in a
Dynamic List or File. A list of Object States may be used for Analysis. It May also
be Incorporated into the Object Patterns Data Type for a variety of applications.
- Virtual Fabric Memory Address [ Main Memory | Flash Memory | Hard Disk | External
Card ] - Used to Set Memory address of Objects in a Particular Disk Medium
- Geographical Location[], Space Coordinates[],
- CPU Core [] - For Parallelizing Operations &, Energy [] - To detect Battery
energy Levels for Process optimizations
- Object Reference DataType[] - Is a File Pointer that can be used to Reference Objects
and store them in Special Graph Data Structures or other Data Structures like Linked
Lists.
- File Data Type[] - Used to Read or Create a Physical File on the Virtual Fabric
Memory. These Files may Store Objects of a Custom Data Structure type and read Objects
of a Custom Data structure - E.g. Like the Freescaling Object. This also allows
creation, Modification and Storage of Open Standard File Structures.
- File Reference Data Type[] are Used as Physical File Pointers that may be stored
as Linked Lists, Maintained in Transaction Logs and Indexed.
3D Array Data Type is used to set Object Structural/Design Boundary Points using
the X,Y,Z Coordinates. The Polygons, Colours, Textures, Shading & Lighting Functions
may be applied on the Data Points. Application areas for this this Data type is
- Game Object Programing - Which May be Dynamically Transformed through Structural
Transformation Functions.
- Operating System Windowing Manager.
- Interactive Movie Programing.
- CAD - CAM - 3D Design Objects for Electronic for 3D Prototype Printing or Machining.
Patterns Data Types are [ 5,6,7,8,9,X Variable ] Data Point Patterns of [ Dimensions
like - String of Words, Object Columns ] and are called Pattern Strings. A Strings
of Words [Text] may be stored as Pattern string inside a Pattern List, with an Unique
Pattern Identifier and this UniQue Identifier may be attached to a Complex Object
Record as a Pattern Dimension for Facilitating a Pattern search. Indexes of Pattern
Data Types may be created for these Pattern Dimensions or Normal Object Dimensions
for High Performance Search Queries of Complex Contexts & Synthetic Data. Pattern
Indexes/Lists may be build at Two Levels or Multiple Levels, with each Having a
Different Number of constituent Data Points. Pattern Matches could be of the Type:
- Exact Pattern Match
- Synonym Pattern Match
- In Synonym Pattern Matches the Entire Input string is converted to a String of Representative
Synonyms before creation of a Synonym based Pattern. When Searches are conducted
for a Pattern we May use Both the types of Patterns for Finding a Record Match.
Note: These Pattern Matching Technique can be used to Map A Natural Language Pattern
to the FCX Object Relational Patterns for Fluid natural Language Processing in Realistic
Artificial Intelligence Interactives. Internal Mechanisms may include Converting
a Natural Language String to an Object Pattern of Synonym ID's where a Synonym ID
is an Unique Synonym ID representing a of Pattern of Synonyms of Words. The object
Pattern of Synonym ID's is mapped to Pattern of Synthetic Contexts in the FCX object
Relational World. Note: String of Words may be stored as a Single Pattern or an
ObjectSet of Multiple Patterns.
Pattern Based Data Points can be used to Store a set Latitude Longitude Datapoints
that Consitutes a Road. This Can Provide Accurate Point to Point Map Navigation
and Alternate Traffic Routes when, Integrated to Artificial Intelligence Interactives.
[ Note: Data Points can be collected by Driving a Car through a Particular Road
]
Data Types like Time Stamp[] May be Used to Store The Multipoint Process Time stamps,
e.g. Aicraft Landing Times at a Specific Airport or delivery Time of a Parcel. Delays
may also be stored as Time Stamps and Ultimately as pattern Datatypes and These
Patterns could be used to spot Delays in a Process or Low Load Factors of in an
Aircraft route.
Virtual Memory Address Data Types can be used to Create Tiers of Memory Within a
Program. It Can be used to create and Manage Lists of Free Memory Blocks, that may
be used for Purposes like Automatic Memory Management Processes and additionally
for Physical File Storage & IO on Disks.
Geographical Memory Addresses may be used to Store Latitude Longitude and Height
of an Object. Space Data Type may be used to store XYZ Central Reference Space Point
of an Object - used for applications like Graphic Object Positioning on Screens
depending on a Form Factor. An Object may use a 3D Array of XYZ space Points to
create a 3D Object Data Structure. Other Application specific Dimensions like Pixel
Colour, Lighting may be used in conjuction with the Space Points[] in a 3D array.
CPU cores and Battery Energy are used for Parallel Processes allocations and VIKM
type intelligent Process Scheduling and Energy Conservation.
- Object Function Model [ Explicitly Distinct Implicitly Coherent Factorized
Intelligent Design Functions ]. E.g. Design[ ], Execution [ ] etc, External Physics
Engines/Libraries [ ]. Note: EDIC Functions may be [ Public ] or [ Private ]. E.g.
A player Has the Ability to Initiate Action Functions like "Shoot [ ]" at enemy
which is classified as an Execution Function - Execution.Shoot[ ].
- Object Relationship Model - This design principle allows creation of Object-Object
& Object-System Hierarchial relationships, and is represented in the system
by an Object relational Graph Data structure. The Graphs are created during Program
Compilation but are dynamically processed and kept "upto date" to allow "High Context"
Object State Updates taking place in the system. Note: State Updates are Handled
by Object State Management Functions. E.g. In the context of a game - weapons are
child Objects to a Parent Player. When a Player drops a weapon, the player Object's
Weapons State is updated by accesing the object through the object graph.
Objects with No Relationships [ Neutral Relationships ] are also maintained in the
Object Graph. E.g. Collision Physics between two Objects with neutral relations.
Priority attributes are Priorities attached to the Object Variables [ Dimensions
], to allow sequential ordering of Object Graphs, which would facilitate instant
State Updates of objects, depending on the Priority Dimensions. E.g. In a Game Scenario,
if Priority is Set on the "Space" dimension, and a Blast/Collision Occurs, the Nearest
Objects to the blast/collision would need a State Update [ Collision physics ].
This would be possible through traversal of Object Graphs which are Sorted by Space
or Distance and represent the actual Objects in memory.
- Relations between Objects are Created by attaching Intelligent Metadata to them.
This Process is termed Intelligent Object Life Cycle.
- All Objects and MetaData Attributes Have Names and an Identificaltion Code.
- The Objects are of the Type -- [ Simple Object | Complex Object | Simple Process
| Complex Process | Intermediate System | Complete System | Organism ]
- Objects have Relationship Metadata associated between them -- [ Parent-Main | Child-Sub
| Partner | Opponent | Friend | Neutral ]. Default Relation is "Null".
- The Objects have additional Metadata - [ Private | Public ].
- The Objects have "Multiple" Type Metadata Points associated with the Objects - Simple
8 Point Matrix or 8 by 8 Intelligent Design matrix consisting of Types like [ Design
] [ Structure ] [ Data ] [ Storage ] [ Risk ] [ Enablers/Resource ] [ Optimization
] [ Exceptions ] [ Rules ] [ Boundaries ] [ None/Null ].
- They may have Inbuilt Object Lifecycle/State Level 2 Metadata types [ Medium, Measurement,
Lifespan, Current Iteration, Current or Previous State, Priority, Parallel Tasks/Threads,
Views, Current Location [From], Current Location [To], Created Time, End Time, Complexity
Mode of Object/Process, Size or Scale of Object ]
- The Objects have additional Level 2.A Metadata like -- [ 1] Primitive Datatypes
like Int, Float, String etc. 2] Abstract Datatypes like: Array, Linked List, Stacks,
Queues, Lists, Freescaling XML Data List 3] Undetermined 4] Null 5] Custom Enumerations
like:
- Size: Small | Medium | Large.
- Duration Task: [ Short | Medium | Long | Unknown | Continuous ]
- FileTypes:Program Registry, Directory, File
- Current Location: From [ X,Y,Z ] to [ A,B,C ] Coordinate or File Location [ X to
Y ] Memory address or Parking Bay 1 to 2. From and Two Locations may also be the
same.
- Transaction: Voice, Realworld Handshake, Online
- Internal Storage: BIOS Memory, HardDisk, Main Memory, HighSpeed Cache
- External Storage - USB|CD|DVD|Omega Drive or Physical World Storage: Storage Shop1,
Shop2, Godown etc
- Mode of Object/Process: Simple Functions | Standard Functions | Complex Functions
| Trail & Error Functions etc ]. Note: an Object be a Complex Process consisting
of Multiple Transaction Functions or Multiple Complex Functions.
- Size or Scale: [ Very large | Large | Medium | Small ] -
E.g. Large Gas Turbines, Mid sized Gas Turbines | Small gas Turbines
E.g. Large Video File | Mid Size Video file | Small Video File
- Priority: System | Very High Priority | High Priority | Medium Priority | Low priority
- State: OnSchedule | Delayed | Exception | Active[ Unknown]. Note: Detailed Custom
State of a process may be obtained by writing Execution.State[] functions that collect
datapoints to show detailed state.
- Objects may have Optional Customizable Level 3 Metadata called Domains -- [ Homosapiens
| Animal Species | Aviation | Computing Hardware | Software | Operating System Memory
Management etc. ]
- The Metadata attached to objects are Synthetic Intelligent Data Collection/Patterns
to convey a Sharp Context about the Object. The Context Synthesis happens by Combining
Attributes aross levels of MetaData like [ Organism + Opponent + Private + Lifespan
+ Virtual Computer Game Player ]. Additional MetaData May be Added as Datapoints
to the Object as per Requirement of the system E.g. Body Damage or Energy Levels
etc.
- All MetaData Values may be Stored as Enumeration OPcodes, therefore they would,
Occupy Very Little Memory and Database Space. It may be Noted that the Objects are
in memory Objects, however access to the Objects and State Changes are Facilitated
through the Object Graphs [ Pointers to the Objects ]
- Imperative programing Model - They are essentially Object State Management
Techniques to allow Cascaded Triggered State change of Related Objects in a Systems
using "Object Relational Graphs". The object graphs are continuous functions that
reorder themselves to maintain an ordered list of High Context Object Pointers.
This allows Predictable "Paths" for State change of nearby objects by another Related
Object. E.g When a System Event occurs, High Context Objects are affected but other
Objects remain unaffected. In the Example of a Game Play -When One Player explodes
a Bomb, the Bomb Explosion Event may affect the State of Nearby Objects, while distant
Objects may Remain unaffected.
The Object Relational graphs may be generated from the relationship Metadata data
values & and are Continuously sorted according to Dimension Priorities, so as
to Facilitate an action/state updates of High Context related Object Variables.
This Programing Paradigm is called Programing with Side Effects, where "ONLY" a
small set of "Related cascading Objects" undergo state Change, when triggered by
an object/system event, thus forcing nearby related objects to undergo state change.
The state change of "Objects" or "Processes" or the "Entire system" may finally
translate to a change in system behaviour on the graphics screen.
Note: Object Lifecycle Functions are used for creation, destruction and duplication
of Multiple Objects, while State Functions are used to control realtime "States"
of objects. Every Object May Have a Function marked with a Attribute [ Event ] and
may have Conditional rules of State Data, which helps in Triggering Events. When
The State of an Object is Changed in a Manner, that it matches the Conditional rules
of State change described in the [ Event ] attributed function - a sequence of cascading
state change functions may be triggered into nearby related objects. This Happens
as a Sequence Chain in a Sequential manner, so that no deadlock conditions arise.
This implies that State updates of objects through object Relational graphs are
sequential processes instead of parallel processes, however Functions within the
object, that trigger a state change, may be executed in parallel. In principle,
this resembles a Sequence of parallel tasks. [ It is similar to the Physics principle
of Nuclear Fission ].
Note: Whenever the Object State Data Changes, the Functions attributed as [ Event
] are checked for an Event Triggering Boundary Condition. If Conditions are Valid
an Event is Triggered.
In principle this Compilation technique leads us to create Dynamic software Systems
where, the Quantum state of a System evolves gradually or varies, based on the actions
of Individual Constituent Objects or Players of the system. This dynamic system
has no Fixed Final outcome or state. The Immediate Next "States" of the System are
however predictable based on the Current Action of the objects or Actors of the
System.
Example: A Component Storage Unit may Have the Capacity of 100 Components. When
a Component is removed from the Storage Unit the Number of Total Components is checked
and if low in number, an event may be triggered to to another Related Parent Storage
to supply it with Further Components. On Unavailibility of Components, a Process
Exception May be raised and Recorded into Dynamic Exception Handling Stack Data
Structure. The Flow of Exceptions across processes would enable Systems to Point
at the Error Source, so as to enable corrective Action. Exception Flows may be [
Intra Process or Inter Process ]. Example : Manufacturing Exception May lead to
a Component Storage Exception and this may further lead to a Supply Chain Exception.
These Patterns of Exceptions can be analysed for Smoothening a System Workflow.
Advanced Artificial Intelligence Interactives may also Quickly Trace Exceptions
and help in Trouble Shooting of Problem Areas, leading to Fully Automated Enterprise
Systems.
- Object Interaction Model - COLD Machine Technique - Interactions are "Process
Interactions" between two Objects [ or Two Processes ]. This Interaction is Invoked
by One Object Changing the State of the Next Object by calling the Second Objects
Internal Method. The Internal Method may choose to change the State change of Invoked
Object by Rules and Logic and this state Change may cause a Cascading set of Event
Triggers that Change the State of Other Related Objects [ e.g A Domino ].
Cold Machine Technique - This Interaction Model Saves Game Objects from Going
through External Game Loop Cycles and Internal Object Game Loop Cycles, listening
for Events. Out of Context Game Objects may need to be ready for State updates,
but may save CPU cycles by allowing only Chained Triggered Events. The Same Principle
may be used in Other Software Systems like the STEX ATM protocol where A Machine
need not waste CPU cycles by Listening Continuously at Any Port. Another Example
may be that a Process scheduler May be invoked by a Process before it starts Scheduling
and Running a Process. An Internal Unterlying API Function May Change the Internal
State of the Main Object which inturn may trigger a Function call like Forwarding
a Packet further. Note: Saving CPU Cycles in Mobile Devices Saves Battery Life.
Some Processes like Graphics Rendering may need to be run Rendered Continuously,
Though Background Processes may Run "Cold". On Larger Server Systems on Public Networks
A Huge Amount of server CPU Cycles may be saved, adjusting to User Demand - Inturn
Saving Energy Consumption. CPU Strategies may involve shutting down maximum CPU
Cores while keeping a spare core active - for a Responsive system Design.
Intelligent Operating Systems & FCX Programs The Virtual Fabric Memory
Filesystem technique offered by FCX has been Described in sections Below. , offers
a Facility of Accessing a Mixture of Main Memory, Flash Cards [ like XQD, Compact
Flash Cards ] and Harddisks in Programs. Next Generation Operating Systems like
[ Stex OS ] and other Programs written by using FCX Compilers can use Intelligent
kernel manager Techniques to, use cheap non electricity consuming - Flash Card based
Virtual Fabric Memory [ As a Buffer memory for Idle system condition/state ], while
Putting Hard Disks to Idle. With Drop down in Process Loads - using the cold Machine
Technique, General Purpose Programs may also run and reside in Main Memory while
Hard Disks are set to Idle. On Increase in Process demands Hard Disks could run
at Max Speeds. This Technique would Drop Down General purpose machine & Datacenter
Energy Consumption needs.
- Parallel & Sequential Model - This system may be designed for Automated
Parallel or Sequential Execution of Functions of an Object, with the Default Functionallity
being Parallel Execution. Every Sub Function of a Complete Function within an Object
may be Described by an Attribute called [ Sequential | Parallel] to facilitate Parallel
or Sequential Exection of the Functions. The Compiler has the Internal Inbuilt Mechanism
to intelligently handle Parallelism, by tracking callbacks. The Compiler would allow
Programs to enable Parallelism by passsing on Information about total number of
Processors and Processor Cores. This Implies that Aprogram Created with FCX would
Autodetect CPU Cores on a Computer before executing a Parallel Execution Strategy.
No there may be No Explicit Threading Libraries Needed to Execute Parallelism.
- Example 1: Five distinct DB Fetch queries may be run in Parallel and subsequently
Merged in a Sequential operation
- Example 2: A Game Object May Involve Automatic Parallel Execution of Execution Functions
and State Changes. Graphics Rendering Functions may Run at System Level.
- View Modelling - Views are Functions that may generate Views/Perspectives
of an Object or a System e.g. [ Objects, Process, Total System ]. Total System Views
may Consist of: [ Priority 1 Processes, Priority 2 Process ] based on The Process
MetaData. Other Views May be Of Custom Types like 360 Degree Stitched Panaromic
Views. Some Views may be Complex Rendering Views generated during Game Play. Games
and Windowing Mangers may Use the Technique of Z-Buffering & Z-Culling and Scalable
Vector Graphics to Render Images on the Screen [ For Any Form Factor - Based on
the Reference X,Y,Z Axis Values of Objects. ].
- Virtual Fabric Memory
The FCX compiler uses a [ Virtual Fabric Memory ] System to allow Objects &
Processses access to Memory. The system May demarcate Memory Zones in the Virtual
Fabric Memory - High Speed Memory, Flash Cache memory and Hard Disk Memory so as
to allow High Level Objects/Processes to use specific Processes to run in Specific
Memory Zones.
Operating Systems [ Like STEX OS and the Proprietary Parallel Kernel Managers like
VIKM ] may run Dedicated Processes that Move Objects from One Memory Zone to another
as a Part of the Memory Management Process. System Processes may have a Fixed Memory
Zone and Other Objects may be allocated to High Speed Memory Zones and Deallocated
to LowSpeed memory Zones as a Part of the Memory Management Process of an OS or
a Program.
Note: Internal Working Mechanism of the Compiler is that, when Working on Existing
Operating Systems like Windows or Unix, It Detects Memory Addresses for the Main
Memory and Memory addresses of Other Devices though their Drivers to Create a Total
Virtual Fabric Memory, with Demarcated Memory Zones. The FCX Compiler may also Detect
Total Number of Processors and Processor cores and Additional Hardware Device Info.
When Creating a Brand New Operating System the Program may initially access only
the Main System Memory and General Purpose Drivers to create the Operating System
[including the VIKM ]. Specialized Drivers could be written using the FCX Compiler
for Proprietary devices at a Later stage. The Advantage of the FCX Virtual Fabric
Memory Technique is that it allows a Programing Model to use Demarcated memory Zones,
which is not offered by present day General Purpose Operating Systems or Programing
models in Compilers.
In the Program Model an Object may use the Virtual Fabric Memory using Enumerations
like: Fastest Tier 1 Memory, Tier 2 Memory, Tier 3 memory etc. The Developed Programs
autodetect Tiers of Memory Available in any System and make available the best Mmemory
Options for the Program to Utilize. If the Computing System has additional Memory
Cards like XQD cards, the Program would autodetect the High Speed Memory and utitize
it to speed up Programs. The Advantage of Such a Model is that Hardware Technology
Innovations [ Faster Devices newer Devices ] may be Accomodated into Existing Hardware
Systems incrementally as per requirement without the need for a Full system Overhaul.
Newer Systems may have a Wide Variety of Configuration Options available [ Low End
to High End Machines ]. The Hardware appears Tiered and Abstracted to the Operating
System or the Programs - for them to Make The Best utiliation of available Resources.
E.g A Program may Commit a Transaction on a Flash Memory if available and then transfer
the data to a Hard Disk for a Final Commit.
Virtual Memory Fabric Based Physical File Storage - No File System !
The FCX compiler Uses No File system to Store Physical Files or Objects. Every Object
Whether a Video File or a DataBase Record is stored using the Virtual Memory Fabric
[ HardDisk Demarcated Zone ]. The Object Created from the Compiler or the Program
may be stored as a File using the Virtual Fabric Technique. The Pointer to the Main
File [ File ID and Name ] are Stored in Tier 1 Zone of the Virtual Fabric as Ordered
Lists of a Particular File Type. This File Pointer Has the File Start Address and
File End Address File, pointed to a Tier 2 File Storage Zone. The File start Address
and File End addresses are Virtual Memory Fabric Addresses containing the Actual
File. The Ordered Lists may be traversed by Search Algorithms to locate the Start
& End address of the File, to fetch the Actual Physical File. This Virtual Fabric
Address can be reached Directly on the Hard Disk, for a High Speed Buffered File
read into a Special Tier Main Memory, from where the Data may be accessed by the
CPU. All Data belonging to a Particular File are Stored in Contiguous Virtual Fabric
Memory Locations.
A Virtual Fabric File "Dynamic Lists [ Where Pop Happens at One End and Push Happens
at the Other ]" Stores the Current Contiguous Blocks of Free Virtual Memory Addresses
along with their Size [ Contiguous Blocks May be greater than a Reasonable Size
of 3 Mb to be Placed on this List ]. When a New File is to be written, an Algorithm
Finds the Most Fitting Contiguous Location to write the File, and it's Start and
End addresses are updated to the File Pointer. When a File is deleted the [ File
Pointers ] are Updated. The Immediately Freed "File Start" and "End" Address Locations
are updated to the Virtual Fabric File "Dynamic Lists" as a Contiguous Free Memory
Block [ Along with Size of Block & only if Block is greater than 3 Mb in Size
]. A Second Minor "Dynamic List" of 1000 [ Customizable ] Memory Addresses with
Contiguous Blocks of Virtual Fabric Memory upto the size of 3 Mb are also Maintained.
This Minor List is used to Write Files of Small Sizes. A Dedicated Process May run
to Rearrange Small Blocks of Defragmented Files to make Them Contiguous. This Virtual
Fabric Based File Pointer Based System, is a Fast Technique to Read Files from the
Disk.
The Internal Construct of the STEX Fluid DataStore is Described as Follows. Every
record in the Fluid Datastor may be Represented by a Single File, and this File
is represented by a File Pointer. The File Pointer is Stored as a Ordered List Object
in a Tier 1 zone of the Virtual Fabric [ Hard Disk Zone]. Records may be Added,
Deleted and Searched on the List by Maintaining an Ordered Ordered List. A File
Index may also be maintained for High Speed traversing of the Ordered List to Locate
a File. This Helps in Extremely Fast Datastore Record/File Pointer Searches, Which
lead to the Actual Data address Location. A separate Ordered List May be Maintained
for Other Dimensions of the Object that are Frequently Used for Searching a Record.
E.g The STEX Network ID or an Email Address. E.g If a PersonID has Multiple Bank
Accounts and Each Account has Account Records, the Datastore Allows Direct Querying
of Bank accounts Object or Accounts Records as The PersonID is stored as Associated
MetaData with the Bank Account Object.[ Parent Object and Metadata Objects are Separate
and Metadata Objects have Parent Objects id's as Metadata atatched to them - thus
Querying does not Involve hierarchical Object Relations in Search Queries ]
Every Object in the STEX Fluid Datastore is Alloted a Dedicated Virtual Memory Fabric
Space of Minimum 1 Mb. [ This Size is Configurable depending on the Object Size
to be Stored ]. The Maximum Size May Have no Upper Limit. This Implies that When
Small Objects or Files Are Written to the Disk They Occupy a Minimum of 1Mb, even
though the File Size May be less than 1Mb. A Freescaling Object Record Belonging
to a Person may occupy 0.5Mb of Data, while 0.5Mb of space is available for Future
data addition. When File Size Updates are Larger than the Total Available Space
for the Object, the Entire Object is written into a New Virtual Fabric Location
with the Addition of 0.5MB Free space for the Future use. By this Technique Maintaining
a Record of 6.5 Billion People on this Planet would require only 6.5 Petabytes of
Average Total Datastore Memory space. This Technique Involves Very Little Fragmentation
and may additionally be healthy for Flash Based Storage devices which suffer from
Constant Writes. Note: Normally Transation Based Objects may require only 10 to
50 Kb of Object Dataspace instead of the 1Mb mentioned. Large "Contiguous &
Free" Virtual Fabric Space Addresses are mained in Lists for the Purpose of New
File Additions or File Relocations.
A File Transaction Log is used to maintain Milestones of a File stream being written
to a Disk or is being relocated from one disk zone to another. Transaction Logs
are maintained to check File Integrity in case of a Power Failure, and are always
checked during a System Startup to check an improper Disk shutdown during a filewrite
process.
Note: A File stream being written onto a Disk Consists of a Set of Milestones which
are maintained in a Transaction Log along with a Milestone Start and End address
and an End of File Descriptor. A large file of 5 Mb May consist of 5 Milestones,
each with a Start and End address. A small file of 2 bytes May have 1 Milestone
with a start and end address.
If the Transaction Log is Intact the Ordered List File Pointers and Contiguous Free
Space Lists may be Updated to the Disk. In Case of a Power Failure Scenario, Between
a File Write Process, The System may check the Transaction Log for Data Integrity
of File Milestones. If Milestones are in the right Sequence and the transaction
log has a File end descriptor, the Linked Lists and free contiguous File lists are
updated, else the stream of Bytes on the Disk are updated into the Ordered List
as a Broken File, which may be deleted if Required. The Same Principle is used to
store Files in Storage Area Networks instead of a Small Disk.
Massively Parallel File or Database Record Reads & Failovers
Finally, Object Record Writes or File Writes may Happen Parallely only Limited by
the Disk IO Capacity. This system Design principle Allows Fluid Datastore to Run
Disk Replication Strategies that are extremely Fast - Where a File Write or Record
Write Process involves Copying one Set of Bytes from One Disk Area to Another, without
the use of a File system based Disk Replication. In such a Strategy The File Pointer
may have Address locations of two or More Replicated File Data, Located in Different
Disks Zones. This Technique may be used for failovers. During Parallel Disk Writes
- The Transaction Log is Verified before selecting a Start Address for Contiguous
File Writing because There may be a Possibility of Contention between two Disk Writes
trying to Occupy the Disk Zone [ Therefore in Principle the Transaction Logs are
only Disk based dynamic lists that hold the Start addresses for every Current Parallel
Write Disk operation ]. Duplicate File Pointer Linked Lists may also be stored for
Security and Robustness and Scalability [ by allowing Parallel Data access from
Disk Zones or Disk Machines through Loadbalancer algorithm - Higher IO Capacity
]. This Technique allows Massively Parallel Record Reads and Writes on a Disk or
a Storage Area Network, by using Infiniband connects for high speed IO.
The Fluid Datastore Facilitates Pre-Generated [ Pre Sorted ] Data Views and Data
Models that allow Allow Fast Queries for Pre Determined Repeat search Queries. Fluid
Datastore also facilitates Data Caching or Data View Caching for Repeated Searches.
This Cache may be on disk or in Memory and removes the need for a separate Inmemory
Caching system or a Key Store.
The entire Mechanism of file storage can also be used as a No file system Based
Fabric Storage Technique, for Next generation Operating systems like STEX OS.
When Running on Proprietary File Systems of Operating Systems like Windows - the
FCX based Programs Mark Certain regions of Hard Disk Space for Exclusive Virtual
Fabric Based Usage - Similar to a Disk Partition.
This FCX Compiler can be Used for "High Speed" Development of
- Next Generation - [ Parallel Kernel ] Intelligent Operating Systems Like [ STEX
- Operating System ] and it's Drivers.
- The STEX Intelligent Digital Grid - [ Information & Technology Services Network
]
- Full Stack Enterprise Control Systems Like Entire Flux [ Core, Retail, Fullfilment,
Integrated ERP etc. ]
- High Performance Freescaling Object Databases & Inmemory Datastores.
- Next Generation STEX ATM-PPP Network Protocol.
- Realistic Artificial Intelligence Interactives - that not Only Interact Intelligently,
but may also carry out some Functions like Booking a Ticket, Showing a Map, Describing
a Factory Process or Even Intelligently Offering Enterprise Operations strategies.
[ Similar to the Intelligent Kernel. - [ A I I] systems Measure Variables in Processes
and calculates Predictable Outcomes ]
- Dynamic 3D Games, Interactive Simulations.
- Next Generation Insurance Systems/ERP systems etc.
Traditional Software Systems have Threading Libraries, to facilitate Application
Level Parallelism/Threading. Automated Parallel Instruction Programing is a Technique
as mentioned above, that may be used to parallelize existing Non Multithreaded Application
Programs, by Modification of Compiler Instruction Sets. It Involves Implementing
Parallelism at the Compiled Instruction Code level. Existing Compilers may also
use "Cross Platform Instruction sets" to facilitate compiling of Existing Software
to run platform independently on Proprietary Systems.
|