C86 v4.2 README
9/29/89
INSTALLATION:
Version 4.2b of the Aztec C86 compiler now includes an installation utility.
To perform a full installation, follow these steps:
- If you haven't already done so, insert disk 1 into a floppy drive.
- Type install <ret>
From this point, follow the installation prompts to complete the installation.
Please note the following approximate hard-disk space requirements:
Minimum Maximum
Professional Package 800K 1.3MB
Developer Package 970K 1.5MB
Commericial Package 970K 1.8MB
The minimum configuration omits source-archive files (in the case of the
commercial version), as well as all library files except the small code/
small data model libraries (all versions).
The installation utility may also be invokved with the /p (for partial) option
if you wish to install only a portion of the package. For example, if your
original installation did not copy archive files, you may invoke Install with
/p to copy ONLY the archive files. The same may be done for the various
models of libraries. To perform a partial-install, follow these steps:
- If you haven't already done so, insert disk 1 into a floppy drive.
- Type install /p <ret>
From this point, follow the installation prompts to complete the installation.
LATE-ADDITIONS TO V4.2B
In addition to the changes listed in the 4.2 release document, the hex86
utility has also been changed. This version fixes two problems that existed
in the 4.1d version, as well as adding support for Intel extended address
records. One problem with the 4.1d compiler was fixed, as well as early bugs
in obji.
HEX86 Changes
HEX86 Bug Fixes:
1. In previous versions, there was a bug in using the -j option (specify
up to 16 bytes of startup code) and the -e & -o options (even & odd). If
an odd number of bytes was specified with the -j option and -e and -o was
used, the last byte of reset data would be omitted.
2. Previous versions of hex86 did not always include the last item of
initialized data in the hex file.
3. Early versions of v4.2 hex86 did not always generate correct checksums for
extended address records.
4. When extended address records were used, early versions of v4.2 hex86
placed the jump to $begin at the end of the initialized data segment instead of
at absolute address ffff:0.
EXTENDED ADDRESS RECORD SUPPORT
This version now supports Intel extended address records within the
hex file. This allows >64K of data to occur in each file, and also allows
code & data to be placed at different locations, but still be contained within
the same physical file. If extended address records are required, then a
symbol table MUST be generated by the linker, using the -t option. The hex86
utility needs this file in order for it to correctly locate code & data. Two
command line options enable the extended address record feature:
-x: This option enables the use of extended address records within the Intel
Hex files generated by hex86. This option may be specified with or
without an explicit segment address. If a segment address is specified
(in hexadecimal), then that address will be the address used in the first
extended address record, and following address records will be
adjusted accordingly. If no address is specified, then the value of
_Corg_ in the program's symbol table will be used.
Data will follow the code within the hexfile, and no special extended
address record will be emitted for it. If code or data goes past 64K,
an extended address record will be emitted to select a new segment.
-i: This option is identical to -x, except that a seperate extended address
record will be emitted for initialzed data, with an address of _Dorg_
(the start of initialized data). An explicit segment for code cannot be
specified with this option, as can be with -x.
OBJI Changes
OBJI Bug Fixes:
1. Early versions of obji occasionally did not generate a BLKEND record for
the last BLKDEF record within the output file. This would cause the Intel
linker to terminate with a "bad object file" error message.
COMPILER Changes
CGEN (Pass 2) Bug fixes:
1. Version 4.1d of pass 2 of the C compiler did not generate correct code when
dealing with Huge pointers. Specifically, segments were bumped by 1000 decimal
instead of 1000 hex when crossing segment boundaries.
