Changes: -------- I) AMIGA-SPECIFIC PROBLEMS -------------------------- 1) Problem: BLink either crashed the machine or produced large files that are reported by AmigaDOS to be 'not an object module'. Reason: BLink version 6.7 does not like (?) empty hunks. Solution: HCC does no longer change the output hunk for XREF/XDEF statements. It does not begin a DATA hunk when no datas are defined. TOP collects all hunks and outputs 0-1 CODE, 0-1 DATA and 0-1 BSS hunk. This also decreases the executable's size, and A68k can do better optimizing. 2) Problem: A68k does not understand '.text', '.comm' etc. Reason: The output of HCC is made for JAS, Sozobon's assembler for the Atari. Solution: TOP now converts this instructions to Motorola format, which is used by A68k. 3) Problem: BLink missed some names that already had been declared in other files when linking multiple files together. Reason: A68k sometimes 'forgets' to XDEF a name that already was XREF'd. Solution: TOP collects all XREF/XDEF statements and XREF's only that names that are not XDEF'd. 4) Problem: Functions declared as static were also callable from other files. Reason: Every called function is, by default, global. This resulted in a PUBLIC and then in a XDEF directive. Solution: HCC now marks static functions/variables as '.STATIC'. TOP never XDEF's such names. 5) Problem: When running in a batch file, HCC and TOP did not terminate the batch file when an error occured. Reason: The exit() function was called with a value of 1. Solution: The exit() function is now called with EXIT_ERROR (10) or EXIT_FAILURE (20). 6) Problem: HCC reported an error when trying to compile programs for Lattice (CManual from Fish #337) that contained the word 'chip' (special variable storage class that forces the variables to be created in chip memory). Reason: Since HCC was created for the Atari ST, he did not know this... Solution: HCC now simply skips this word (no syntax check etc), but returns EXIT_WARN (5) to the operating system. This can be determined in a batch file ('If warn'). TOP has a new command-line option, the flag -c, to force all DATA and BSS hunks of the current file to chip memory. CAUTION: This will work correct only when using A68k version 2.61 or higher (provided on this disk). 7) Problem: HCC always wrote the output file to the current directory. Reason: No command-line option for specifying the ouput file was there. Solution: HCC can now be called with the name of the output file following the input file name. But compiling multiple files in sequential order, and compiling from stdin and to stdout, is no longer possible. 8) Problem: TOP always wrote his temporary files to the current directory. Reason: The filename for the temporary files. Solution: Temporary files are now written to 'T:'. You can use the 'Assign' command to change this directory. Be careful: The temporary filenames are hard-coded, so TOP should only run once at a time! 9) Problem: A68k sometimes reported an 'alignment error'. Reason: HCC made no alignment of simple global variables, only structures were word-aligned. Solution: HCC now aligns global variables to word boundaries. (If you need longword-aligned data for BCPL AmigaDOS, the safest way is to declare the data at the beginning of your program or in an extra file, to force them to the beginning of the DATA or BSS hunk. Hunks always start on a longword boundary). 10) Problem: Program prargs in directory 'libraries/workbench' on the 'Libs&DevsCompanion' Disk from Commodore (Fish #344) did not work when compiled with HCC. Reason: The pointer to the Workbench startup message was expected in argv. Solution: Changed startup code HCCStartup.asm to supply the message in argv when started from workbench. II) INT SIZE (16/32 BIT) PROBLEMS --------------------------------- 1) Problem: Many guru's when calling Amiga system functions. Reason: HCC used int variables with 16 bit size. The standard int size on the Amiga is 32 bit. Solution: HCC now has a new command-line option, the flag -L, which forces ints to be 32 bit rather than 16 bit in size. Also, when -L is specified, function call parameters are always forced to be long. You can, in fact, call Amiga system functions with char parameters, they will be expanded (via ext.w, ext.l) to 32 bit. (I saw this behaviour when disassembling older programs compiled with Lattice. Cant say if this is standard or not, but since it prevents MANY guru's, I implemented it. In my opinion this is the ONLY acceptable solution as long as HCC does not support ANSI function parameter prototypes. Please let me know if this is incompatible to Aztec or Lattice, since HCC is my only C compiler, I can't decide that.) 2) Problem: HCC could not distinguish between 0x00011000 and 0x00001000 when using the 'switch' statement. Reason: The value to compare is always casted to int. But the compare directive generated by HCC was always 'cmp.w' (16 bit). Solution: Depending on the -L flag, the compare directive is now 'cmp.w' or 'cmp.l'. Notice that without -L flag, the error still is present, since the value to compare is casted to int even if you write 'switch (longvariable)'. 3) Problem: When using the -L flag, HCC used short's with 16 bit, but unsigned short's with 32 bit. This caused the guru to meditate about the size of the USHORT fields in struct NewWindow. Reason: HCC did not distinguish between 'unsigned' and 'unsigned short'. Solution: Added the data type 'unsigned short' to HCC. Many structures of the compiler (the documentation of the source is nearly ZERO) had to be changed. Hope I found all relevant parts. 4) Problem: HCC did not handle bit fields correct when using the -L flag. Reason: Bit fields are of int size, but the code generated to handle them was designed for 16 bit fields only. Solution: Depending on the -L flag, code for 16 or 32 bit is generated. This is tested successfully with 'DisAsm' from Fish #27. (Caution: HCC stores the bits in the field from right to left. The Aztec compiler that compiled DisAsm stores them from left to right. You simply have to reverse the declarations. Another problem are lines like 'printf("%c%c", getchar(), getchar() );' since HCC and this Aztec compiler would do the two getchar() calls in different order. Since the ANSI standard explicitly declares the bit order in fields and the argument computation order in function calls to be compiler-dependant, I did not change HCC.) III) CCLIB LIBRARY USEAGE PROBLEMS ---------------------------------- 1) Problem: The first test to use CClib.library resulted in an immediate crash. Reason: HCC used registers for register variables that were destroyed by CClib.library. This results from the fact that CClib.library was compiled with Aztec (Robert W. Albrecht, personal communication). Solution: HCC now handles D0, D1, D2, D3, A0, A1 and A2 either as scratch registers or completely does not use them. TOP does the same. A5 is now used as local stack pointer instead of the now unused A6. I think that the register handling of HCC and TOP could be improved a bit, but I was satisfied when CClib.library could be used. (P.S.) 16-01-91 New CClib.library V3.0 saves D2-D7, A2-A5. HCC, TOP, FD2Stubs and the math routines in HCC.lib re-changed to use D3 for register variables. D2 and A2 are seldom used temporary registers. (P.P.S.) 21-05-91 A6 is now used as a temporary register for structure assignments instead of A2. A2 is now used for register variables. So you can have the same number of register variables as with the Atari version (5 Data, 3 Address). 2) Problem: The printf/scanf() routines of CClib.library did not handle floating point variables correctly. Reason: CClib.library uses 64 bit IEEE floating point format, HCC uses Motorola fast floating point format. Solution: HCC now uses printf/scanf() routines derived from Dale Schumacher's Public Domain dLibs 1.20.0 standard C library functions for the Atari ST. This routines are located in HCC.lib, the printf/scanf() routines of CClib.library are now declared (in CClib_lib.fd) as ##private and cannot be used by HCC. I decided not to put them in a separate linker file and use them only when floating point handling is required, since this is the safe way, even when your 'printf("Hello, world!\n");' would become much shorter when using CClib.library's printf() function. 3) Problem: CClib.library's toupper() and tolower() functions caused problems when called like toupper(*c++) Reason: These functions were macros. When expanded, the ++ was done twice. Solution: Implemented the functions as real code (file ctype.c). (P.S.) 16-01-91 New CClib.library V3.0 has working built-in toupper() and tolower() functions. Thanks Robert! IV) BUGS -------- 1) Problem: Some executables crashed when optimized by TOP without -p flag. Reason: The code fragment move.l d0,(a3) move.l (a3),a3 was changed to move.l d0,a3 move.l a3,(a3) Solution: Added additional 'if' condition in file peep2.c. (P.S.) This bug was fixed in the 2.0 release of TOP. 2) Problem: Some executables crashed when optimized by TOP without -p flag. Reason: The code fragment move.l (a0),d0 addq.l #1,(a0) move.l d0,a0 was changed to move.l (a0),a0 addq.l #1,(a0) Solution: Added additional 'if' condition in file peep3.c. 3) Problem: The line 'unsigned char text[] = "text";' resulted in an error message, but 'char text[] = "text";' of course not. Reason: HCC did not recognize this as string constant array. Solution: Added additional 'if' condition in file d2.c. (P.S.) Would it be correct to assume "Hello" as null-terminated array of UNSIGNED char ? 4) Problem: Sometimes executables made wrong decisions when comparisons like '&&', '||', '==', '!=', '<', '>', '<=' or '>=' were used. Reason: The result checking instruction could test 32 bit, but the comparison result storing instruction affected only 16 bit of a register. Solution: Changed some parts in g2.c and gen.c to create '.l' 32 bit comparison result storing instructions instead of '.w' 16 bit instructions. V) OTHER CHANGES ---------------- 1) Problem: HCC had a very large size. Reason: One reason was that the code for debugging purposes was always compiled and added to the executable. Solution: Enclosed debugging code between '#ifdef DEBUG' and '#endif' preprocessor statements. 2) Problem: HCC did not know ANSI Bell (\a), Vertical Tab (\v) and hex numbers (\xNN). Reason: This is not an ANSI C compiler. Solution: Added the necessary code to tok.c 3) Problem: HCC needed lots of memory. Reason: One reason was that a fixed size BSS hunk to hold the buffers for the 20 possible include files needed much memory. Solution: The buffers are now generated at run-time, only when needed, via malloc(). Greetings to all AMIGA freaks, Detlef Wuerkner Werrastrasse 7 D-6300 Giessen GERMANY