andrews@hpcupt1.HP.COM (Edward E. Andrews) (07/19/90)
I've complied C68 and tried to get it to compile itself. C68 does not like #include statements. I keep getting CPP errors. Is there a fix?
HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (07/24/90)
???? you have to apply cpp first, then feeding the cpp output to c68. c68 only likes #line statements. I am not willing to incorporate a preprocesser into c68 since many system dependencies enter a preprocessor (contrary to the compiler). C.v.W.
Glen Lalonde <lalonde@torolab2.vnet.ibm.com> (03/21/91)
I was converting all sizeof() to (int)sizeof(), so I could compile with
gcc, when I noticed a c68 bug.
Try this:
main() { int a,b;
long buf[32/sizeof(long)];
long buf2[32/((int)sizeof(long))];
a = sizeof(buf);
b = sizeof(buf2);
printf("a is %d, b is %d\n", a,b); }
Gcc and ack give 32,32. c68 gives 32 and 16.
This bug caused my machine to crash, also there must be few more bugs in
c68 since I get read errors about once every half an hour if I use a
c68 compiled kernel.HBO043%DJUKFA11.BITNET@cunyvm.cuny.edu (Christoph van Wuellen) (03/22/91)
I confirm this bug. The fix is easy: In file expr.c, function primary, look at the big switch statement and search case openpa: here, casts are done. In this case, head and tail must be saved to local copies and restored later. because this was not done by c68, the definition 'long' was overwritten by 'int' when the cast was performed. C.v.W This is fixed now and will be included in the next patch. Since I regard this error as severe, the next patch will be submitted very soon.
bob@miranda.inmos.co.uk (Bob Green) (03/28/91)
In article <48408@nigel.ee.udel.edu>, lalonde@torolab2.vnet.ibm.com (Glen Lalonde) writes: |> I was converting all sizeof() to (int)sizeof(), so I could compile with |> gcc, when I noticed a c68 bug. |> |> Try this: |> main() { int a,b; |> long buf[32/sizeof(long)]; |> long buf2[32/((int)sizeof(long))]; |> |> a = sizeof(buf); |> b = sizeof(buf2); |> printf("a is %d, b is %d\n", a,b); } |> |> Gcc and ack give 32,32. c68 gives 32 and 16. |> This bug caused my machine to crash, also there must be few more bugs in |> c68 since I get read errors about once every half an hour if I use a |> c68 compiled kernel. You are quite right - the code you include does seem to produce the wrong answer with c68. However I feel that I must point something out to you. It does not seem fair to say "because I've found one thing wrong with c68, then I can blame all of my other problems on it". Believe it or not there could be some other cause of your kernel problem. Perhaps c68 generates faster code, and finds a timing problem in the kernel that slow old ACK doesn't. I'm not saying that is your problem, just that there could be many reasons that you're having trouble. I've been using c68 for a long time now, and used it to successfully port Minix to a home-brew 68000 box. I've NEVER had a read error (that I know of). I have of course rewritten the disk tasks to talk to my hardware, so perhaps the problem you mention is in there. A long time ago I mailed CvW how much I liked c68. But now I must stand up publically and thank him for all the work he has put in (and continues to put in) to c68/386. I think its a great compiler and the Minix community would be worse off without it. Thanks for listening to my rant (did you have a choice) ;-) -Bob -- | Bob Green Inmos Ltd, Bristol | EMail(UK) ukc!inmos!bob |---------------------------------------| or bob@inmos.co.uk |The opinions above are my personal | Internet: bob@inmos.com |views and do not reflect Inmos policy. | UUCP:(US) uunet!inmos.com!bob