mirror of
https://github.com/byteworksinc/ORCA-Pascal.git
synced 2024-12-09 20:50:26 +00:00
218 lines
8.6 KiB
Plaintext
218 lines
8.6 KiB
Plaintext
ORCA/Pascal 2.2
|
|
Copyright 1996, Byte Works Inc.
|
|
|
|
-- Change List --------------------------------------------------------------
|
|
|
|
2.2 1. Bugs fixed; see notes, below.
|
|
|
|
2. Pascal supports the extended character set. See "Extended
|
|
Characters."
|
|
|
|
2.1 1. Bugs fixed; see notes, below.
|
|
|
|
2. New optimization added for method calls. See "New
|
|
Optimization."
|
|
|
|
2.0.1 1. Bugs fixed; see notes, below.
|
|
|
|
-- Manual Errata ------------------------------------------------------------
|
|
|
|
p. 340
|
|
|
|
trunc4 returns a longint, so the definition line should read:
|
|
|
|
function trunc4 (x: real): longint;
|
|
|
|
p. 361
|
|
|
|
The ISO and ANSI compliance statements say that ORCA/Pascal 1.2 complies with the standards. So do the other versions, including the current one.
|
|
|
|
p. 364
|
|
|
|
Add the following:
|
|
|
|
ORCA/Pascal supports Apple's extended ASCII character set, allowing use of non-ASCII characters in identifiers and supporting some special characters as substitutes for traditional mathematical operations. See "Extended Characters" for implementation details.
|
|
|
|
p. 378
|
|
|
|
Under "Implementation Restrictions," delete these:
|
|
|
|
"2. Arrays cannot be larger than 64K bytes long."
|
|
|
|
"3. Records cannot be larger than 64K bytes long."
|
|
|
|
ORCA/Pascal supports both using the large memory model. If you try to use a structure larger than 64K with the small memory model, you get a more specific error message telling you to switch memory models.
|
|
|
|
-- New Features -------------------------------------------------------------
|
|
|
|
New Optimization
|
|
----------------
|
|
|
|
There is a new optimization bit for the Optimize directive. When bit 5 (value of 32, or $0020) is set, the compiler is allowed to perform optimizations that will generate code that is not ROMable. Currently, the only optimization it performs is to use self-modifying code for method calls, resulting in code for the call that is about 1/3 faster and shorter than without this optimization.
|
|
|
|
WARNING: Object Pascal code compiled with Pascal 2.1 and later is not compatible with Object Pascal code compiled with Pascal 2.0. You must recompile the entire program and all libraries if the program or libraries involve objects.
|
|
|
|
Extended Characters
|
|
-------------------
|
|
|
|
Bear with me. This is an ASCII file, and it describes non-ASCII material.
|
|
|
|
Beginning with version 2.1, the PRIZM desktop editor supports the full Apple extended character set. A file called FontTest on the samples disk shows the complete character set, and also contains a table that shows how to type each character from a U.S. English keyboard.
|
|
|
|
Pascal supports the use of extended characters in strings, comments, identifiers, and for a few mathematical operations.
|
|
|
|
Any character you can type from PRIZM (or for that matter, any character with an ordinal value in [1..12, 14..255]) can appear in a string or comment. The ordinal value of the character matches the values shown in FontTest, as well as several official Apple publications. Keep in mind that many output devices, including Apple's text console driver, do not support all of these characters. ORCA/Pascal will properly send extended characters to whatever output device you choose, but what happens when the output device tries to handle the character varies from device to device.
|
|
|
|
Many of the characters in the extended character set are used in languages oter than English, and are now allowed in identifiers. There are two ways to think about which characters will work in an identifier.
|
|
|
|
The simple way is to remember that all characters that look like a graphically modified ASCII alphabetic character or a Greek alphabetic character are allowed in identifiers. For example, an a with two dots above it is now legal in an identifier.
|
|
|
|
The more exact, and naturally more complicated way to think about which characters are allowed in an identifier is to list all of them. Since this is an ASCII file, I'll list the ordinal values--you can cross reference the values in FontTest. The ordinal values of the extended characters that are allowed in identifiers are [$80..$9F, $A7, $AE, $AF, $B4..$B9, $BB..$BF, $C4, $C6, $CB..$CF, $D8, $DE, $DF].
|
|
|
|
In addition, ORCA/Pascal supports several extended characters as shortcuts for multi-character mathematical operations. These are:
|
|
|
|
ordinal value description substitutes for
|
|
------------- ----------- ---------------
|
|
$C7 two < <<
|
|
$C8 two > >>
|
|
$AD not equal <>
|
|
$B2 less than or equal <=
|
|
$B3 greater than or equal >=
|
|
$D6 division (- with dots) div
|
|
|
|
Finally, the non-breaking space, sometimes called the sticky space (ordinal value $CA), is treated exactly like a standard space character.
|
|
|
|
-- Bugs from Pascal 2.1 that are fixed in Pascal 2.2 ------------------------
|
|
|
|
1. Incorrect code was generated for compares of objects. For example, if obj1 and obj2 are object variables,
|
|
|
|
if obj1 = nil then ...
|
|
|
|
and
|
|
|
|
if obj1 <> obj2 then ...
|
|
|
|
both generated incorrect code.
|
|
|
|
2. A bug in error reporting has been corrected. For some rare errors, the compiler incremented the error count but did not print the error message.
|
|
|
|
3. Eof and eoln have not worked for the standard input file since the switch to the .CONSOLE driver. They do, now.
|
|
|
|
(Jason)
|
|
|
|
4. When a Read of a real value encounters a character sequence that starts with a character that can't be a part of a real number, as in
|
|
|
|
var
|
|
r: real;
|
|
|
|
begin
|
|
read(r);
|
|
|
|
with input of
|
|
|
|
a
|
|
|
|
should generate a run-time error. In ORCA/Pascal 2.1, this error was not detected.
|
|
|
|
(Rick Prest)
|
|
|
|
5. Reading a value into an array element or a pointer, as in
|
|
|
|
read(readValue[4])
|
|
|
|
did not always work correctly.
|
|
|
|
(Rick Prest)
|
|
|
|
6. Ord4 did not report an error when used on a nonscalar value, as in ord4(3.4).
|
|
|
|
7. When the +t +e flags were used and too many END statements caused the compiler to flag a "'.' expected" error, the error was not reported properly. The file name and error message were garbage when the editor was called, resulting in a blank file with an error message containing random characters.
|
|
|
|
8. Code generation has been improved for optimized code when a value is stored through a global pointer.
|
|
|
|
9. Loads of double values were not performed correctly by the FPE version of the SysFloat library, resulting in a large loss of precision.
|
|
|
|
(Soenke Behrens, Dirk Froehling, Frank Gizinski)
|
|
|
|
10. With output redirected to a file and input comming from the keyboard, pressing the return key echoed the return that should have shown up on the screen to the output file.
|
|
|
|
(Soenke Behrens, David Empson)
|
|
|
|
-- Bugs Fixed from Pascal 2.0.1 ---------------------------------------------
|
|
|
|
1. The compiler flagged a compile error when debug code was generated for a variable that was declared as a type where the type was a pointer to a record, as in
|
|
|
|
type
|
|
r = record
|
|
i: integer;
|
|
end;
|
|
rp = ^r;
|
|
|
|
var
|
|
p: rp;
|
|
|
|
2. Objects could not be packed; now they can.
|
|
|
|
3. It is now possible to compare an object to nil using the equality and inequality comparisons (= and <>).
|
|
|
|
4. Stores to boolean and character fields within an object intermitantly saved only one byte, when they should have saved two bytes.
|
|
|
|
5. String constants in the interface part of a unit did not resolve properly when used from another unit or the main program.
|
|
|
|
(Ken Kazinski)
|
|
|
|
-- Bugs Fixed from Pascal 2.0.0 ---------------------------------------------
|
|
|
|
1. With optimizations on, assigning the same constant to both a byte and word
|
|
could generate code that did not correctly set the most significant byte of
|
|
the word.
|
|
|
|
(GNOTim2)
|
|
|
|
2. In some cases, successive stores of the same long constant to two different
|
|
locations with common subexpression elimination turned on would damage the
|
|
stack.
|
|
|
|
(GNOTim2)
|
|
|
|
3. In some conditional branches involcing comples integer expressions, the
|
|
condition code was not properly evaluated.
|
|
|
|
(GNOTim2)
|
|
|
|
4. Optimization of arithmetic shifts by a constant in the range 9..15 has been
|
|
improved.
|
|
|
|
(GNOTim2)
|
|
|
|
5. Text programs didn't work when launched from the Finder.
|
|
|
|
(JamesG7858)
|
|
|
|
6. On page 250, the manual shows parameter lists for overridden methods,
|
|
like this:
|
|
|
|
cube = object (box)
|
|
front, back: integer;
|
|
function Volume: integer;
|
|
procedure Fill (ptop, pleft, pbottom, pright,
|
|
pfront, pback: integer); override;
|
|
procedure Grow (size: integer); override;
|
|
end;
|
|
|
|
This is incorrect. When you override a method, the parameter lists must
|
|
match. As with forward procedures in Standard Pascal, ORCA/Pascal flags an
|
|
error when you redefine the method list. The correct way to declare this class
|
|
is:
|
|
|
|
cube = object (box)
|
|
front, back: integer;
|
|
function Volume: integer;
|
|
procedure Fill; override;
|
|
procedure Grow; override;
|
|
end;
|
|
|
|
(Daniel B. Johnson)
|
|
|
|
7. The {$rtl} pragma was not exiting with an RTL.
|