RS6000 questions/comments

[Cris J. Rhea]

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---
seems easier to post and hope that someone in Austin will respond than
try to report all of these as problems/concerns.

--- Cris

uunet!ssi!cjr
ssi!cjr at uunet.uu.net

/* ---------- "That $%%^&# RS6000" ---------- */
 
 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.

 * There is no /usr/lib/debug/malloc.o. Or at least I can't find 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.

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

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

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

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

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

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

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

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

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

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

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

* SCCS: If you try and SCCS a file out on the rs6k that is older than
	a year (I think), then sccs prints out a 4 or 5 line paragraph warning
	you that the file you just sccs'd out is over a year old...
	I guess this means that we should always be changing things, at least
	once a year????