jfc@athena.mit.edu (John F Carr) (12/19/90)
It's been a long time since I've seen current documentation for hc,
and I have a few questions.
Is there a list of what all the supported pragma directives are? I've
figured out some by running "strings" on the binary, but it's not
always clear from the name what the pragma does or how it is used.
hc also supports a number of extensions to the C language. It has a
few extra keywords. For example, function definitions can be declared
"_Inline". This suggests that hc will inline functions, but it
doesn't seem to affect code generation. There are also keywords
"_Bound" and "_CC", which are sometimes inserted by error recovery but
don't seem to be legal otherwise. Do any of these do anything?
I know that hc recognizes certain function names and inlines them; is
there a list of recognized functions?
When is the next release of hc2 for the RT due?
--
John Carr (jfc@athena.mit.edu)brunner@bullhead.uucp (01/04/91)
The current version of the Metaware High C compiler (hc) is 2.1y. During the last months of the past year I tested two later versions of the compiler (2.1z and 2.1A). Unfortunately, both of these contained a bug I consider "fatal" a kernel compiled with either of the post-y versions would crash at the first pass through tcp_input.c, when calls to the protocol control block manipulation routines in_pcbconnect() and in_pcblookup() were made. At the year's end the support contract for the C compiler for IBM/4.3 was not renewed, nor were the contracts for the Pascal or FORTRAN compilers, so we are stuck with what we have. Note that gcc 1.37 is available from several sites on the internet, and that 1.38 has been announced and the RT is among the supported platforms. #include <std/disclaimer.h> Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.
brunner@bullhead.uucp (01/04/91)
I forgot to mention that I've passed the questions concerning pragmas and so forth on to Mimi Vo who knows more about the compiler than I do. Either she or I will post a follow-up with the details. #include <std/disclaimer.h> Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.
dyer@spdcc.COM (Steve Dyer) (01/04/91)
So what's the final state of AOS 4.3 anyway? Just the Dec 88 tape
and the patches previously sent out? It is officially kaput now?
--
Steve Dyer
dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
dyer@arktouros.mit.edu, dyer@hstbme.mit.edujfc@athena.mit.edu (John F Carr) (01/04/91)
In article <1991Jan4.000714.6440@panews> brunner@ibmsupt.UUCP () writes: >Note that gcc 1.37 is available from >several sites on the internet, and that 1.38 has been announced and the >RT is among the supported platforms. The "released" version of gcc for the RT is based on 1.35.99 (essentially the same as 1.36) with many modifications (I put "released" in quotes becuase this is not an official FSF release). I find hc 2.1y to be a better compiler: it produces faster, smaller code that has fewer bugs. Neither gcc 1.37 nor gcc 1.38 supports the RT. gcc version 2 will support the RT and will be a viable alternative to hc (code quality is slightly worse than hc; this will probably change), but I don't know when it will be released. Is there a reason not to make later versions of hc 2.1 available, with the warning that there are known bugs? hc 2.1y has bugs too; having 2 versions available increases the chances of finding a compiler that works. -- John Carr (jfc@athena.mit.edu)
brunner@bullhead.uucp (01/05/91)
In article <1991Jan4.054021.3334@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: >In article <1991Jan4.000714.6440@panews> brunner@ibmsupt.UUCP () writes: >>Note that gcc 1.37 is available from >>several sites on the internet, and that 1.38 has been announced and the >>RT is among the supported platforms. > >The "released" version of gcc for the RT is based on 1.35.99 (essentially >the same as 1.36) with many modifications (I put "released" in quotes >becuase this is not an official FSF release). I find hc 2.1y to be a better >compiler: it produces faster, smaller code that has fewer bugs. Neither gcc >1.37 nor gcc 1.38 supports the RT. gcc version 2 will support the RT and >will be a viable alternative to hc (code quality is slightly worse than hc; >this will probably change), but I don't know when it will be released. Thanks for the clarification John, I also got email from Richard Kenner today along the same lines. The error is mine. Richard wrote in part that: The last version for which I updated the patches was 1.36 (really 1.35.99+). That version is available on jim.ultra.nyu.edu (it may have been copied elsewhere). But, from viewpoint, that doesn't work. It has many bugs (it can't correcly compile X11, for example). He also wrote that GCC V2.0 will support the RT, and that it may go into beta test at MIT in a month or so. The RT version has been tested and is used in-house to compile "everything, including X11R4". > >Is there a reason not to make later versions of hc 2.1 available, with the >warning that there are known bugs? hc 2.1y has bugs too; having 2 versions >available increases the chances of finding a compiler that works. > Well, as I described in my posting of yesterday in response to Tim's question, if 2.1z or 2.1A is used to compile the low-level internet code, the resulting .o when linked will yeild a kernel which crashes rather early in the boot process. This is pretty fatal and I was very surprised to find it present in the 2.1A compiler as I'd reported it after finding the cause of failure with the 2.1z version of the compiler. I'm sending John a copy of the 2.1A version, but I won't place it on ibmsupt for general release -- I really wish this bug had been fixed! > John Carr (jfc@athena.mit.edu) #include <std/disclaimer.h> Eric Brunner, Consultant, IBM AWD Palo Alto (415) 855-4486 inet: brunner@monet.berkeley.edu uucp: uunet!ibmsupt!brunner trying to understand multiprocessing is like having bees live inside your head.