Frank Heckenbach wrote:
Adriaan van Os wrote:
Some more in Apple UCSD Pascal (just for the record)
- A compilation can be a program, or one or more units separated
with semicolons and ending with a period.
Several units separated with semicolons? Strange. Kind of contradicts the meaning of "unit" (in the common meaning of the word) to me ...
There will have been pragmatic reasons for it, way back in 1980. With 64 or 128 Kbyte memory you need a lot of segmentation and chaining, therefore small units. There was no --automake feature.
- File type INTERACTIVE
What difference does it make?
[1] Apple UCSD Pascal Language Reference Manual.
"If the file is not of type INTERACTIVE, RESET automatically performs a GET action -- that is, it loads the first record of the file into the file’s buffer variable and advances the file pointer to the second record. If the file is INTERACTIVE, no GET is performed; the buffer variable’s value is undefined and the file pointer points to the first record." [1, page 28]
"READ With a CHAR Variable.
For a CHAR variable, READ reads one character from the file and assigns that character to the variable. There are two special cases: Whenever the end-of-line character (ASCII 13) is READ, the value assigned to the CHAR variable is a space (ASCII 32), not a CR. Whenever EOF becomes true, the value assigned to the CHAR variable is not defined.
After the READ, the next READ or READLN will always start with the character immediately following the one just READ.
The workings of EOLN and EOF depend on whether the file is of type TEXT or INTERACTIVE. For a TEXT file, EOF is true when the last text character in the file has been READ. EOLN is true when the last text character on a line has been READ and whenever EOF is true. (A "text character" here means a character that is not the end-of-line character or the end-of-file character).
For an INTERACTIVE file, EOF is not true until the end-of-file character has been READ. EOLN is not true until the end-of-line character at the end of the line has been READ or until EOF is true." [1, page 34]
"The standard predeclared files INPUT and OUTPUT are INTERACTIVE files representing the console keyboard and screen; another predefined file called KEYBOARD also represents the keyboard." [1, page 11]
- Predefined file KEYBOARD
GPC provides `Kbd' in the unit `Turbo3' (BP compatibility for Turbo Pascal 3.0 compatibility). Does it behave the same?
"The difference between INPUT and KEYBOARD is that when INPUT is used to refer to the keyboard, the typed characters are automatically displayed on the screen; when KEYBOARD is used, the characters are not automatically displayed." [1, page 12]
- Bit-packing
We don't set `--ignore-packed' in UCSD mode, so this should be the same in GPC.
Yes, it is.
- INTEGER type can be modified by a length attribute
Well, we have the `Size' attribute (probably different syntax, but the semantics might be the same?).
The 'Size' attribute denotes the number of decimal digits (BCD), not the number of bits.
" TYPE BIGNUM = INTEGER[ 12] VAR FATS: INTEGER[ 25];
This defines BIGNUM as a type which can have any integer value requiring not more than 12 decimal digits. FATS can have any integer value requiring not more than 25 digits. The length attribute can be any unsigned INTEGER constant up to and including 36." [1, page 19].
- LONG INTEGER type, represented internally as a binary-coded
decimal (BCD) number (up to 36 digits)
Nice. :-( I guess when GCC will support 128 bit integers, we can declare it as such (or the exact subrange), since the internal representation shouldn't matter.
Because integer values are "discrete" numbers. In non-BCD floating point you have the problem that you cannot even represent something simple like 2 euro 13 exactly (which is a horror for accounting applications).
- Built-in function PAGE
Is this the same as in standard Pascal (start new page where applicable)? Then I can just activate it in UCSD Pascal mode.
I think so (if my understanding of it is right).
"The page procedure sends a top-of-form character (ASCII 12) to the file. The form is
PAGE( FILEID)
where FILEID is the identifier of an open file of type TEXT or INTERACTIVE." [1, page 39]
- Built-in functions UNITREAD, UNITBUSY, UNITWAIT and UNITCLEAR
The UNITxxx routines provide hardware-oriented low-level IO. "They allow a Pascal program to transfer a specified number of consecutive bytes between memory and a device. They are not controlled by filenames, directories, etc., but merely use device numbers and (for diskette drives) block numbers." [1, page 26]
Back in those good old times, there were no security issues, you simply had full control ! You could destroy everything or do wonderful things with it, like copying MS-DOS diskettes on an Apple IIgs !
procedure UNITREAD( UNITNUMBER, ARRAY, LENGTH [, [BLOCKNUMBER] [, MODE]] ) procedure UNITWRITE( UNITNUMBER, ARRAY, LENGTH [, [BLOCKNUMBER] [, MODE]] ) function UNITBUSY: boolean {always returns FALSE on the Apple II} procedure UNITCLEAR( UNITNUMBER)
If someone is interested, I can provide more details.
- Built-in functions PWROFTEN and TREESEARCH
PWROFTEN
"This function returns a real value which is 10 to a specified (integer) power. The form is
PWROFTEN( EXPONENT)
where EXPONENT is an integer value in the range 0..37. This function returns the value of 10 to the EXPONENT power." [1, page 45]
TREESEARCH
"This is a fast function for searching a binary tree that has a particular kind of structure. The form is
TREESEARCH( ROOTPTR, NODEPTR, NAME)
where ROOTPTR is a pointer to the root node of the tree to be searched, NODEPTR is a pointer variable to be updated by TREESEARCH, and NAME is the identifier of a PACKED ARRAY[ 1..8] OF CHAR which contains the 8-character name to be searched for in the tree.
The nodes of the binary tree are assumed to be linked records of the form
NODE = RECORD NAME: PACKED ARRAY{ 1..8] of CHAR; LEFTLINK, RIGHTLINK: ^NODE
...(* other fields can be anything *) ... END;
The type name and the field names are not important; TREESEARCH only assumes that the first eight bytes of the record contain an 8-character name and are followed by two pointers to other nodes.
It is also assumed that names are not duplicated within the tree and are assigned to nodes according to an alphabetical rule: for a given node, the name of the left subnode is alphabetically less than the name of the node, and the name of the right subnode is alphabetically greater than the name of the node. Finally, any links that do not point to other nodes should be NIL.
TREESEARCH can return any of three values:
0: The NAME passed to TREESEARCH has been found in the tree. NODEPTR now points to the node with the specified name.
1: The NAME is not in the tree. If it is added to the tree, it should be the right subnode of the node pointed to by NODEPTR. -1: The NAME is not in the tree. If it is added to the tree, it should be the left subnode of the node pointed to by NODEPTR.
The TREESEARCH function does not perform any type checking on the parameters passed to it." [1, page 49-50]
- Built-in function SCAN
"This function scans a range of memory bytes, looking for a one-character target. The target can be a specified character, or it can be any character that doesn't match the specified character. SCAN returns an integer value, which is the number of bytes scanned. the form is
SCAN( LIMIT, PEXPR, SOURCE)
where
LIMIT is an integer value which gives the maximum number of bytes to scan. If LIMIT is negative, SCAN will scan backward. If SCAN fails to find the specified target, it will return the value of LIMIT
PEXPR is a "partial expression" which specifies the target of the scan. PEXPR takes one of the following forms:
= CH <> CH
where CH stands for any expression that yields a result of type char.
SOURCE is a variable of any type except a file type. The first byte of the variable is the starting point of the scan.
SCAN terminates when it finds the target or when it has scanned LIMIT bytes. It then returns the number of bytes scanned. It the target is found at the starting point, the value returned will be zero. It LIMIT is negative, the scan will go backward and the value returned will also be negative." [1, page 51-52]
What do they do? Can they be provided in a unit?
No problem for PWROFTEN, TREESEARCH and SCAN.
<to be continued>
Adriaan van Os