CERN, European Organization for Nuclear Research
1211 Geneva 23
Switzerland

J.D. Blake
blake@cernvax.cern.ch
1991/2/6


                  Users' reactions to GCC for OS-9/68000
                  --------------------------------------


Gccos9 should accept the most  common  options  of  Microware's  cc68,  in
cc68's  syntax,  to  avoid  unnecessary  changes in make files (APastore).
Some commonly used options of cc68 and their gccos9 equivalents are:

	-r              -c              Generate object module (file.r)
	-l=<libfile>    -l<libfile>     Library file
	-m=<size>       -s <size>       Additional stack size (in KB)
	-f=<execfile>   -o <execfile>   Executable file
	-e=<number>     -e <number>     Edition number


The make command in OS-9 has built-in rules for compilation, assembly  and
linking.  The  user  cannot  define  his own default rules, but can define
symbols (CC, CFLAGS, LC, LFLAGS, ...) which appear in the built-in  rules.
It  appears  that  the  built-in  rule  for compilation can in this way be
persuaded to use gcc, but that the rule for linking cannot.  The behaviour
of  OS-9 make is erratic: it will sometimes use a built-in rule instead of
an explicit one (JdeVries).

Gcc is too big to run as a native compiler on many OS-9 systems (AMiotto).
Gcc can compile itself in 2 Mbytes (ASeyama).


Several programs (sysmon, X's maze) must be compiled with  gcc's  -mremote
option  in  order  to  work  (DKemp,  APastore).  Gcc does not support the
"remote" key word of Microware's C.


Gcc compiles a[i+offset]  into  "lea  a+offset(a6),a0"  which  can  easily
overflow  if  offset  is  negative  and  a  is  one  of the first items of
statically allocated data in the program  (AMiotto).  "l68  -a"  fails  to
notice  the  overflow and the program executes wrongly.  Gcc with -mremote
option avoids the problem.


Unibridge's r68020 crashes when "gcc -m68020 -m68881" is applied to C code
generated  by  f2c  and  the  original  Fortran  contains  REAL arithmetic
(LTremblet).  Instructions  of  the  form  "fop.s  #...,fpn"  provoke  the
failure  which  occurs  in the translation of the immediate operand. "cc68
-k=2f" fails in the same way.  Native r68020 avoids the problem.


"gcc  -mremote  -o68"  nearly  always  fails  (LTremblet).  Gcc  does  not
generate  the instruction length information ":n" which o68 needs in order
to generate short branches safely.


Gcc generates 16-bit offsets in internal branches, despite the presence of
-m68020  and  -mremote  options.  The  offset  can  overflow in very large
functions (LTremblet).


A variable argument list pointer can only be used inside the function with
the  variable  argument  list  (APastore).  The  va_arg macro in varargs.h
refers to variables in va_alist, whose scope is limited to this function.


There are no gcc command options to control  l68's  map  (JPetersen).  L68
has   options   -m   (module  map),  -s  (module  map  with  symbols),  -w
(alphabetical order of module map symbols), -j (jump table  map).  Neither
gcc  nor  cc  allows  access  to  these  options: the user has to call l68
directly. "gcc -debug ..." may be used to show the l68  command  generated
by gcc.


What about execution profiling (-p  and  -a  options  of  gcc)?  Profiling
requires  a  profile  dump  library prof.l, which we do not have.  ASeyama
says that he is working on a block profiler.  (OS-9 user meeting)


What about source level debugging?  Gcc does  not  generate  symbol  table
information for r68/r68020.  Gdb cannot be used, as it has not been ported
to OS-9.  Machine independent code may compiled and debugged  on  cernvax,
which has the full suite: g++, gcc, gas, gld, gdb. (OS-9 user meeting)
