ciaraldi@Rochester.ARPA@sri-unix.UUCP (08/29/83)
From: Mike Ciaraldi <ciaraldi@Rochester.ARPA> We are using this compiler on an IBM PC under Concurrent CP/M, and have had several problems. If you read the article in the newest BYTE comparing C compilers for CP/M-86, you saw the discussion of memory models. The one we really need is "compact", which allows unlimited data (heap) size, so we can pass pointers between processes. The "big" mode lets the code grow also, but we don't need that in our application. What happens? DRI includes two sample C programs with the compiler. One of them works OK on the small and compact models, but when compiled with medium or big it runs but produces no output! The other test program also works OK for small and compact, but crashes the system when using the other two models. I can see having problems with early versions of the complier (we have serial number 23), but you would think the sample programs would have been tessted before release. As mentioned above, compact model was OK, but now that has problems, too. e.g. When you do a getchar to read a character from the keyboard, in both small and compact the function does not return anything unttil you hit <CR>. In small, repeated getchar's fetch the characters on the line, and finally a '\n'. But in compact, the very first getchar returns the '\n'! So, in compact it is impossible to do any keyboard input, because all you get are new-lines. In both models, "scanf" never returns no matter what you type. The rest of the compiler seems OK. It calculates, calls subroutines, etc. But the runtime library seems all messed up. Does anyone know if there are C compilers for CP/M-86 that allow addressing more than 64K of data? In the BYTE article it mentioned c-systems and Lattice, but that does not seem to be correct. c-systems in its newest release supports extended code but not data. Lattice will support extended data under MS-DOS in October, but they told me on the phone that the CP/M version was delayed pending information on "segment fixup" coming from DRI. Except for these problems, the DRI C looks good. But, for our application it does not measure up. Any comments or suggestions are welcome. Mike Ciaraldi University of Rochester; Taylor Instrument Co. ciaraldi@rochester
POURNE@mit-mc@sri-unix.UUCP (09/04/83)
From: Jerry E. Pournelle <POURNE@mit-mc> We've got a bunch of C compilers around here but I have not written about them preciesly because we don't at the moment have the resources to test for situations such as you describe. I know Mike Lehman pretty well (he's the author of the Digital compiler) and I find it unlikely that he'd let the thing out without severe testing particularly of the examples; is it possible you have a broken compiler? Do write to Lehman at Digital poste haste; he'll want to know about any problems in his latest baby.