RS6000 questions/comments

[Chuck Karish]

In article <141 at ssi.UUCP> cjr at ssi.UUCP (Cris J. Rhea) writes:
>I am one of the system admins at our company. One of our compiler folks
>started using one of our rs6000's and had the following comments---
> 
> Here are some crude porting notes on the software I got to port and test 
> out ok on the rs6k machines.
>
> * Make on the rs6k has no TARGET_ARCH or HOST_ARCH. The rs6k has no arch
>	command that I can find.
>
> * Make on the rs6k doesn't seem to automatically sccs out files it can't 
>	find, so you may need to sccs get SCCS.
>
> * The make on rs6k also doesn't automatically issue the .INIT rule.
>
> * Makefiles with blank lines that have tabs in them are treated as syntax
>	errors by the rs6k make utility.

AIX isn't BSD and it isn't SunOS.  Those constructs aren't
available everywhere and makefiles that depend on them aren't
portable.  IBM could have adopted the approach that Convex did,
and say "The customer is always right; let's give them a
development environment just like their ond one".  Convex
restricted this to the VMS and Cray environments, though, on a
4.2->4.3 base.  It would be madness to try to be backward
compatible with everybody.

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

Isn't there a PD one available?  I should look into this, myself.

> * 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.

It does if you invoke it as xlc.  Just change $CC to 'xlc' in
the makefiles.  Unless, of course, 'cc' is hard-coded into the
rules...

>	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.

Completely consistent with the ANSI/ISO C standard, though.  A
standard compiler #defines __STDC__ to be 1.  If __STDC__ is
#defined to be anything else, or is not #defined, you don't
have a Standard C compiler.

>	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>.

This behavior is required by POSIX.1.  Declarations in line are
permitted, but only if no POSIX.1-required headers are #included.

>	I almost tried a -D__STDC__=0 on the compile line, but chickened
>	out, maybe I'll try that some other time.

If the code you're porting assigns a special meaning to the
case where __STDC__ == 0, it's broken and should be fixed.  Not
an AIX problem.  The #define would probably have worked.  Any
problems caused by doing this should be reported to IBM as
bugs; their tests for __STDC__ in headers should be correct.

> * 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.

An enum as a bit field?  The C Standard doesn't make any guarantees
about the size or alignability of an enum.  This usage is risky.

> * 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.

C Compilers have always been free to do this.  What's the point
of having prototypes in the language if you insist on being able
to contradict them?

> * 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. 

This is good advice.  As I said before, it's required by POSIX.1.
AIX 3.1.5 on the RISC System/6000 models 320 and 530 conforms to
the POSIX.1 standard as measured by the NIST-PCTS.  By default
the namespace rules are more relaxed when you call 'cc', but
the _POSIX_SOURCE macro does what it's supposed to.

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

#ident isn't C, as far as I know.  Should be a #pragma.

>* 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.

I agree that this is annoying.

>* The rs6k has defined NULL to be ((void*)0) instead of 0.

This is covered in the FAQ for comp.lang.c, and is the topic of
a shouting match now in progress in comp.std.c.  The only
portable use of NULL is to cast it to a pointer of the
appropriate type.  Code that requires that NULL == 0 is
broken.  Some systems use the (void *) cast when they don't
have to, but it's a correct implementation of NULL.

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

AIX is not BSD.  vfork() is a value-added performance hack, and
should not be used (except inside #ifdefs) in programs that are
intended to be maximally portable.  It's perfectly reasonable
for IBM not to provide vfork() if they don't think there's a
significant perormance advantage.  "#define vfork fork" should
fix this.

>* 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.

Then #define _XOPEN_SOURCE and they'll go away.  <curses.h> seems
to #define TRUE and FALS unconditionally, though.

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

As noted above, you need it for some forward declarations,
which can't safely be done in line if you need any of the
standard headers.  Any header may #include any other header.
-- 

	Chuck Karish		karish at mindcraft.com
	Mindcraft, Inc.		(415) 323-9000