Upload

Digital Research

CPM OPERATING SYSTEMS/CPM 68K/1.0X SOURCES/v102a/doc/alcyon.doc

@@ -0,0 +1,81 @@
+
+
+
+
+
+     These are notes made while altering the Alcyon compiler for CP/M.
+
+         1. It would really be nice if you confined your filenames  to
+            8  letters,  all  lower  case,  with a 2 letter extension.
+            This will enable you  to  put  them  on  any  O/S  without
+            translating  them.   (More  of a convenience than anything
+            else).
+
+         2. I corrected a number of "#if... MC68000" which should have
+            been  "#if... REGULUS".   CP/M  also requires MC68000, and
+            you could conceivably run the compiler on  someone  else's
+            (obviously  inferior)  68000  UNIX system.  Similarly, you
+            have a number of "VAX11" conditionals which really  should
+            be "DECC".
+
+         3. How can you not allow nested include files on  some  O/S's
+            when  your  own software requires this feature?  Including
+                  ____  ___ ________
+            multiple input buffers in the "filestack" structure  fixes
+            this  problem  (at the expense of extra memory).  There is
+            no signifigant performance penalty, since the memory is in
+            BSS.
+
+         4. Command line switches MUST be case-insensitive.
+
+         5. In the preprocessor, you have a lot of  "versaxxxx"  func-
+            tions.   Why not define a run-time library (similar to our
+            "klib") which will enable you to  take  out  most  of  the
+            conditional  compilation?   This  would  have  a  positive
+            effect on your reliability and testing time.
+
+         6. I changed  the  name  for  the  Whitesmith's  compiler  to
+            WHITESM, to eliminate conflicts.
+
+         7. Under CP/M or  with  our  cross  tools,  users  have  been
+            accustomed to having the preprocessor "-i" switch take the
+            next   argument   as   the   drive   /    directory    for
+            "#include <file>"  constructs.   I  conditionally compiled
+            this.  In  any  event,  your  standard  include  logic  in
+            "macro.c"  was  faulty  for  systems with a colon (":") as
+            device name delimiter.
+
+         8. Jeez, why the "printf((char *)STDERR" stuff?  Couldn't you
+            write a function "fprintf" for V6 and not make the rest of
+            the world suffer?
+
+         9. The "C268" pass of the compiler produced a file  that  the
+            assembler  wouldn't  assemble  (using  a  very  large ".c"
+            file).  There were more than 20 labels which needed to  be
+            grouped  together.   Increasing the size of the structures
+            in "optim.h" fixed the problem.  You really ought to range
+
+
+                                                                Page 2
+     
+
+
+            check  your  index variables, and print a message if there
+            are too many labels for you to handle.
+
+        10. The  assembler  will  definitely  NOT   work   under   the
+                                              ___
+            Whitesmith's  compiler,  since  you  rely on being able to
+            open a file twice (pass1a) and on being able to  rewind  a
+            text file with "lseek" (pass2).
+
+        11. There is some  dependency  in  the  assembler  on  getting
+            storage from sbrk() which is initialized to zeros.  I took
+            out the code from our  C  runtime  which  zeros  the  area
+            between  the BSS and the stack, and the assembler wouldn't
+            initialize.
+
+        12. The assembler had a bug where  assembling  an  odd  length
+            byte   string  into  the  text  segment  caused  alignment
+            problems.  We fixed this problem over  a  year  ago.   Why
+            wasn't the fix incorporated??