egisin@watmath.waterloo.edu (Eric Gisin) (02/12/88)
There are several problems with the Mark Johnson C compiler.
The preprocessor doesn't do macro expansion correctly.
There are a few code generation bugs, and the C library
is missing some things and has a few bugs.
It is also missing goto which is commonly used.
I used to have Mark's (new) mail address, but I can't reach him any more.
The last I heard he was working on rewriting macro expansion,
but I don't know when and if this will be released.
I've documented the compiler bugs I know about so others can avoid them.
To get around the other problems I have a couple of solutions.
I found a public domain preprocessor (decus) I almost have working and will post
a binary when I've tested it for a while. It also has #if, #elif and #assert.
(this is a 140K program I've compiled with MJC with only ~10 changes.
I did have to preprocess it under Unix cpp though.)
I wrote a short preprocessor to handle goto's by generating asm() statements,
which I will post as source to this group.
I suspect others have fixed things in LIB.C themselves.
If people send me fixes I'll try to merge them
and post a set of context diffs based on the original.
(I've fixed redirection and made some small extentions).
Eric Gisin, egisin@Waterloo.EDU, watmath!egisin.
Compiler bugs:
pointer-to-function types can not be declared (in general).
sizeof((*)()) and typedef (F*)() don't work.
expressions with && and || will generate incorrect code.
to work around this parenthesise the && subexpressions, for example
a && b || c --> (a && b) || c
multiple structure assignment (a = b = c) doesn't work.
when using combined operator assignments (+=, etc) the left side is evaluated
twice, not once (for example, *p++ |= BITS increments twice).
Documented features that cause many problems:
the type of initialization variables must not be (char)
and initialization values must have matching length (short or long).
I found this the most time-consuming problem in porting code.
grep all C files for '=.{' looking for char variables or structure components.
often you can change char to short.
look for things like "long STKSIZ = 4096" and use 4096L.
also make sure NULL is defined as 0L, not 0.nfrech@ALMSA-1.ARPA ("Norman R. Frech") (06/17/88)
Has anyone out there had any experience/luck with Mark Johnson C. I am
trying to compile a C program which I wrote under BSD 4.3 on our VAX at
at work at home on my 1040. The program is fairly simple and straight
forward. It simply reads a SLAM II input file, parses the file line by
line for a renumbering purpose and writes out a modified file. The program
works fine on our vax but when I try to compile using Mark Johnson C v2.0
I get a 0 byte output file. I have had very little success using this
C package so far ('hello, world' really works great) and I think I might
have to break down and buy MWC or maybe Laser C.
Any suggestions would be appreciated.
Norm Frech <nfrech@almsa-1.arpa>
*************************************************************************
"Verbatim regurgitation is against my principles" - Neal, The Young Ones.
************************************************************************* bds@lzaz.ATT.COM (BRUCE SZABLAK) (06/17/88)
In article <8806162102.AA01677@ucbvax.Berkeley.EDU>, nfrech@ALMSA-1.ARPA ("Norman R. Frech") writes: > > Has anyone out there had any experience/luck with Mark Johnson C. Yes, I've had v2.0 for a week or 2, and I've compiled one program in excess of 1700 lines or so with no problem. I'd like to help you but your problem description is pretty vague (but not more so than some MR's I've received ;-) ). Remember: MJC (and MWC) have 16 bit ints and 32 bit pointers which cause 99% of all porting problems in my experience. Run LINT on your vax code and look for mismatched pointer assignments and inconsistent use of parameters to functions (Mark: any chance of supporting function prototypes ala ANSI?). If that fails, take a shot at sprinkling some printfs in your code to insure your getting into main ok and so on. Look through your code to see if any kind of error will cause you to exit early. As a last resort, compile your program one function at a time and test: compile main (commenting out function calls in it), then the next function etc. Good Luck.
egisin@watmath.waterloo.edu (Eric Gisin) (06/20/88)
One common problem I have with MJC is running out of disk space. Neither the compiler nor linker check for write errors. A truncated .TTP file will do nothing or give you a strange TOS error. Stack overflow is another possiblity, you can change it in ttp.s.
piet@ruuinf.UUCP (Piet van Oostrum) (06/20/88)
In article <155@lzaz.ATT.COM> bds@lzaz.ATT.COM (BRUCE SZABLAK) writes: In article <8806162102.AA01677@ucbvax.Berkeley.EDU>, nfrech@ALMSA-1.ARPA ("Norman R. Frech") writes: > > Has anyone out there had any experience/luck with Mark Johnson C. Yes, I've had v2.0 for a week or 2, and I've compiled one program in excess of 1700 lines or so with no problem. I'd like to help you but your problem description is pretty vague (but not more so than some MR's I've received ;-) ). I tried to compile some programs with MJC V1.2, and just got V2.0, but did not try it yet. I also expierenced some problems (note these are all V1.2): 1. macro expansion with a trap inside get screwed (e.g. #define Fseek(a,b,c) trap(....)) 2. The stdio package is almost totally broken. I rewrote a part of it but have not ported the changes to V2.0. Some problems: Redirection from a shell gives big problems. MJC just supposes that stdin and stdout are terminals if they are not redirected on its command line. So reading from a file as stdin clobbers the file. Besides, it doesn't use Fforce, so you end up with the wrong file handles (no longer 0, 1) if you do redirection in the program. Next the buffering is incomplete. fread and fwrite use unbuffered I/O, so you can't mix them with other stdio calls, like putchar. The files are not closed on exit, so you MUST do that yourself. fseek also doesn't take buffering into account. I don't know any more from the top of my head. I'm waiting for GNU cc for the ST!