Upload

Digital Research

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

@@ -0,0 +1,54 @@
+.ps 55,65
+These are notes made while altering the Alcyon compiler for CP/M.
+.ls
+.le;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).
+.le;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".
+.le;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.
+.le;Command line switches MUST be case-insensitive.
+.le;In the preprocessor, you have a lot of "versaxxxx" functions.  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.
+.le;I changed the name for the Whitesmith's compiler to WHITESM, to eliminate
+conflicts.
+.le;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.
+.le;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?
+.le;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 check
+your index variables, and print a message if there are too many labels for 
+you to handle.
+.le;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).
+.le;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.
+.le;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??
+.els
+We have not encountered any further bugs since the two for which we gave you
+source code.
+
+
+
+
+