RS6000 questions/comments

[Sean Eric Fagan]

In article <141 at ssi.UUCP> cjr at ssi.UUCP (Cris J. Rhea) writes:
> * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch
>	command that I can find.

Most machines don't.  It's very simple to write an arch command, though, and
I've had to install one on lots of machines.  Remember, folks, all the
world's not a Sun.

> * Make on the rs6k doesn't seem to automatically sccs out files it can't 
>	find, so you may need to sccs get SCCS.

Are you using SysV sccs convention (s.<filename>) or BSD (SCCS/...)?  If
you're not using the one that the builtin rule expects, I'm not terribly
surprised it doesn't do what you want, and you shouldn't be, either.

> * The make on rs6k also doesn't automatically issue the .INIT rule.

What is this '.INIT' rule?  I've never heard of it, and I've been using
makefiles for half a decade now.

> * Makefiles with blank lines that have tabs in them are treated as syntax
>	errors by the rs6k make utility.

Blank lines with tabs tend to cause problems with make, and always have.

> * There is no /usr/lib/debug/malloc.o. Or at least I can't find it.

Not on my machine, either.  There are several debug mallocs out there; the
advantage being I can get source code if I want it, and, if it doesn't
provide the amount of debugging I want, I can change it.

> * On the rs6k cc does not define __STDC__ by default (unless you want
>	strict ANSI I guess) but the #include's and cc in general appears
>	to be an ANSI implementation. For example, it has stdlib.h, it wants 
>	sprintf() to be declared as "int sprintf();" or not at all, and
>	it allows prototypes all the time.
>	The SVR4 cc has the attitude that strict ANSI mode defines
>	__STDC__ as 1 otherwise it defines it as 0, in either case it is
>	defined. Very inconsistent and annoying.
>	Similar problems were found with the mem*() functions and the
>	malloc()/free()/realloc()/calloc() functions, don't declare
>	them just use <stdlib.h> and <string.h>.
>	I almost tried a -D__STDC__=0 on the compile line, but chickened
>	out, maybe I'll try that some other time.

Good for them!  Doug Gwyn (among others) has a *lot* of objections to
defining __STDC__ when you aren't compliant.  I, personally, could argue
both ways about it, and have done so before.  But there is nothing wrong
with what IBM did in that respect.

> * Expect many warning messages about enum's, especially if used as bit 
>	field types.  This is stupid, if you can't use an enum as
>	a bit field that makes them even more worthless.

I wish I had a copy of the ANSI C Standard handy; I think there might be
good reason they did that.  But I can't remember what ANSI said about
bitfields.  Ah, here it is (just found a copy):  "a bit-field shall have a
type that is a qualified or unqualified verson of one of int, unsigned int,
or signed int."  An enum type can *fit* into an int, but it is not
necessarily an int.  At least, that is likely IBM's reasoning.  I will not
say whether it is good or bad.

> * The rs6k compiler objected to:
>		#define blah(a,,b) a+b
>	The sun doesn't seem to care.

The sun compiler is broken.

> * The rs6k compiler will demote formal parameters to the type they
>	are specified with, the sun does not, e.g.
>		a(f) float f; { }
>	inside a() the f parameter (even though it is passed the entire double)
>	will be truncated to a float before it is used. The sun cc
>	recognizes formal parameters with type float as being more
>	like doubles.

The sun compiler is broken.  You said it was a float, why are you surprised
to find that it is?

> * Don't even attempt to declare any system calls if you include any
>	sys/*.h #include files. The chances of matching the declaration
>	in the #include is impossible and any include of any sys/*.h
>	#include file seems to bring in a whole nest of others, especially
>	unistd.h. 

Any declarations in header files for any standard functions (i.e., those
defined by ANSI and/or POSIX) must match the definition the standard says.
Guess what:  most of those don't necessarily match traditional declarations.
For example, consider:

	extern int lstat();	/* pre-POSIX */
	extern int lstat(const char *, struct stat *);	/* POSIX */

If the latter is in a header file, but you use the former, that is an error.

>* The rs6k C compiler gives a warning error on every use of #ident. 
>	Another warning message to ignore.

As it should.  What is this "#ident"?  Neither ANSI nor POSIX say anything
about it.  It would also, I suspect, complain about "#machine" or whatever
the abortion SysVr4 uses is.

>* The rs6k compiler complains about any macro that has been defined on
>	the compile line and also defined in the source, even if the
>	definitions are exactly the same. Yet another warning message to
>	ignore.

This is legitimate, although it would be nice if it did check to see if they
were the same.

>* The rs6k has defined NULL to be ((void*)0) instead of 0. This has
>	caused numerous fatal errors in some of the SVR4 sources.
>	Places where an unsigned or an ELF64_Addr (an unsigned) is
>	assigned NULL. I resorted to adding a -DNULL=0 to the compile
>	line to get around this.

Both definitions are correct.  See ANSI.

>* The rs6k like the u370 (that's the 3090) has no vfork().

vfork() is a hack, although, I will admit, it does have its uses.  The only
legitimate use of vfork() is that the child will execute before the parent.
However, POSIX does not (yet?) have a vfork() like function; IBM may be
waiting for POSIX to decide what to do before they add one.  (POSIX did
have, last time I checked a draft, a proposal for a 'qfork()' which was
almost-but-not-quite vfork().  So be it.)

>* Somewhere in the include of sys/types.h I think, there are #define's of
>	the very popular names TRUE and FALSE. This cause problems in
>	SVR4 ld1 e.g. it has enum{TRUE=1,FALSE=0}Boolean; in it.

Neither should be there in ANSI or POSIX conformance mode (assuming the
compiler has such a thing).  However, I will say that I believe the SysVr4
one to be *wrong* in that respect, because what if someone else wants to
define a boolean type?

>* The include of unistd.h includes just about everything, you may want to
>	avoid this file unless you really need it.

Again, there are limits on what <unistd.h> can include in POSIX conformance
mode.

>* The yacc source generated on the sun's will not compile on the rs6k,
>	you will need to re-run yacc on the rs6k to get rs6k acceptable
>	source. The sun yacc source declares things like malloc() wrong.

Not a problem, really.  I don't believe that yacc output is guaranteed to be
portable.  You should see if you can fix the yacc template, though.

-- 
Sean Eric Fagan  | "What *does* that 33 do?  I have no idea."
sef at kithrup.COM  |           -- Chris Torek
-----------------+              (torek at ee.lbl.gov)
Any opinions expressed are my own, and generally unpopular with others.