Grok32` is designed to be compiled with standard C compilers. Grok32` is not a formal object-oriented language, but it does handle almost all substantial values as objects. The C-code used to implement Grok32` expects the host OperatingSystem to have some kind of HandleManager service. The host OperatingSystem�s HandleManager service effectively manages memory behind the scenes. This allows the executable code for Grok32` to not concern itself with MemoryManagement.
On the other hand, Grok32` could also contain its own MemoryManagement procedures�
Each object has a handle. Each handle is known by its MachineSize Cardinal value.
The ObjectHandler manages memory for all objects.
ObjectHandler(card)
�returns the pointer to the beginning of an object�s actual data.
ObjectType(card)
�returns the object�s Type. This information is necessary to interpret the data.
ObjectSize(card)
�returns the object�s size in bytes.
How big can an object be? How about 2^32 bytes (4 GigaBytes)?
4 GigaBytes is an ample size for most stuff, and the size will fit in a 32-bit register.
This is enough.
As an example, let�s develop the BinaryString Type.
The BinaryString is a quasi-arbitrary-length string kept in memory as an array of bytes. In actuality, it can represent a Cardinal, part of a Real, or a String. ObjectType(handleCard) keeps track of this interpretation.
The BinaryString is a particularly good example of an Object because it is literally what Cardinal, Real, and String values are ultimately composed of. The BinaryString data composes the Cardinal, Real, String Types which are ordered in increasing complexity.
The Cardinal interpretation of a BinaryString subdivides the string into register sized parts and evaluates these in order of significance. By convention, the first byte pointed at is the most significant, and the last byte is the least significant.
The Real interpretation of a BinaryString subdivides the string into register sized parts except there is both an exponent and a fraction which are both supposed to be capable of being arbitrarily large, but which are not actually.
The String interpretation of a BinaryString subdivides the string into register sized parts using features of the StringObject. See String Implementation Notes. The means whereby the StringObject is interpreted is also important insofar as it imposes rules on the way Grok32` codes Files. A Grok32` TextFile begins by assigning Cardinal values to each CharacterCodes used in the subsequent text-String. (These Cardinal values then specify a Character�s CharacterSet in the subsequent StringParsing.)
[The following was taken verbatim from Type.htm. This and the above form the object-handle requirements made by Grok32`. In principle, the language does not have to be written in C, but why not, since it is the most popular, general-consumption, excellent-public-domain intellectual capital available.]
If type is the Name of a DataType, (Type[Name][type] is True), and substance is the BinaryString for type, then�
(4) Type[type][Function][substance]
�converts the BinaryString, substance, into the type�s value.
"Type[type][Function]" is assigned to the Function which, if successful, returns a handle to an ExpressionAtom. This handle accesses the basic DataType evoked when substance is elicited. Normally, type is a field available through an ExpressionAtom handle. See the source code for Reckon[Expression[Branch]] for details of how the Function in (4) is used when a String is Reckoned as an Expression.
The Function returned by (4) is called the TypeNameFunction.
The above may take input and return some form of Noop.
[The aggregate of ExpressionAtoms and their handles define the underlying object code.]
In the case of �Name[substance]�, for example, �substance� is either a recognized Name or it is created. Type[Name][Function] is assigned to the Function that executes this Name-recognition. This Function takes input, (a BinaryString), and returns a handle if the input is interpretable as a Name. If the input BinaryString is not interpretable as a Name, False is returned.
The Time[�] document notes that "�a Cardinal TimeValue measures time in processor cycles."
What exactly is a "processor cycle"?
If by "processor cycle", is meant an "instruction", then Time[�]'s realization is dependent on processor architecture. Modern processors have a high degree of parallel processing, that nonetheless adheres to a Von Neuman Machine model. Time[�] will be implemented differently, processor to processor. See `Time`Processor`.
� 2004, 2005
by John Van Wie Bergamini.
All rights reserved.