Porting to IBM RS/6000

[linas at innerdoor.austin.ibm.com (Linas Vepstas)]

Hi, 

Regarding a port of geomview to the IBM RISC System /6000,
I found your ftp site and sucked over the source for
version 1.4.1, and started compiling it on AIX version 3.2.5.

Below follow my notes. They are inclomplete; I am not yet done,
(have to go home), will try again after siggraph.


                                        Sincerely,
                                        Linas Vepstas

^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^
    Linas Vepstas                Graphics Architecture
    AWD IBM Austin               VNET: AUSVM6(LINAS)
    Zip 9260
    Dept E84S, Bldg 902          Tie Line: 678-1116  
    11400 Burnet Road            External Phone: 1-(512)-838-1116

    http://w3.austin.ibm.com/afs/austin/u3/linas/public/html/home.html
    local: linas at austin.ibm.com
    internet: linas at innerdoor.austin.ibm.com
^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v^

In order to make Geomview compile on the RS/6000, had to do the
following:

-----------------------------------------------------------------
-----------------------------------------------------------------

create a file: ./makefiles/mk.rs6000
which contains the following:
#
# Makefile that sets machine-specific variables and rules 
# for the IBM RS/6000 (AIX 3.2.5, with xlC compiler)
#
#
# A machine-specific makefile is included by all other makefiles.
#

CPU = rs6000
MACHTYPE = ibm
RANLIB = :
INSTALL = /bin/install
AR = /bin/ar
SYSCOPTS = 
CC=cc
# CPLUSPLUS=CC
CPLUSPLUS=xlC

# MAKEFILEDIR is used by NeXT make to find the app.make file;
# we use this to fool sgi make into looking at a dummy app.make
# in this dir:
MAKEFILEDIR=${GEOM}/makefiles

-----------------------------------------------------------------
-----------------------------------------------------------------

Turns out I have to create a bunch of O.ibm files ... this ticks 
me off a little bit. This is a WHOLE lot of work, and the whole 
point of makefiles is that this should NOT have been required. My gut,
shoot from the hip impression is that the Makefiles need to be
redesigned to get rid of the O.* stuff.

As a cheap stunt, I let MACHTYPE be sgi, but then ran into other make
problems -- appearently, some of the makefiles attempt to run install 
(??? even though I am not installing ????). Then, some of the flags
passed to install are not valid (for AIX).

-----------------------------------------------------------------
-----------------------------------------------------------------
include/streampool.h:

Had to include <sys/select.h> in order to get the fd_set type used on
lines 52 and 60.

-----------------------------------------------------------------
-----------------------------------------------------------------

AIX does not support alloca.  I seem to remeber talking to the system
architects about this years ago, but am not sure of the reply.
Something about the CPU archtitecture and/or OS design that made
alloca a real bad deal... I dunno. Sounds weird.

I added the following to porting.h:

#ifdef ibm
#define alloca malloc
#endif

The following files did not include poritng.h ... had to be added
(and the other lines about #include <alloca.h> were removed)
./src/lib/geometry/cmodel/cmodel.c
./src/bin/geomview/common/ndshade.c
./src/bin/geomview/common/drawer.c
./src/lib/gprim/mesh/meshdraw.c
./src/lib/gprim/polylist/pldraw.c
./src/lib/gprim/quad/quaddraw.c
./src/lib/gprim/vect/vectdraw.c

-----------------------------------------------------------------
-----------------------------------------------------------------

include/sl2c.h:
line 51:
> extern complex          div ();

The subroutine div() is a part of the ANSI C standard, and 
is declared as
div_t div(int, int)
in stdlib.h

See paragraph 4.10.6.2 of the ANSI C standard

I renamed the div() in sl2c.h to be deveyed(), but I was unable to find
and .c's that actuall called this ... ?  Actually, it looks like parts
of this header are obsolete, since in src/lib/gprim/discgrp/complex.c,
the functins are called cplx_plus(), cplx_minus(), cplx_div(), etc. etc,
and not plus(), minus(), div(), etc. etc.

-----------------------------------------------------------------
-----------------------------------------------------------------

The AIX compiler, buy defualt, doesn't seem to like
K&R style functional declarations, and I don't know how to 
turn that off.  Thus, I had to edit the following to give the
subroutines ANSI declarations:

./src/lib/gprim/quad/quadbound.c: line 15:
./src/lib/gprim/quad/quadsphere.c: line 5:
./src/lib/gprim/quad/quadevert.c: line 19:
./src/lib/gprim/quad/quadnormal.c: line 16:
./src/lib/gprim/quad/quaddelete.c: line 16:

-----------------------------------------------------------------
-----------------------------------------------------------------

There is a reference in src/lib/gprim/stub/O.sgi/Makefile to "install".
It probably doesn't belong ... it certainly doesn't in for O.ibm

-----------------------------------------------------------------
-----------------------------------------------------------------

Declaring a variable to be "reigster" in AIX is a bad idea.
Chances are, it will cause to compiler to do sub-optimal work.
In particular, take a look at:

./src/lib/gprim/vect/vectdraw.c: line 99, line 101:

These lines attempt to take the address of a variable
that has been declared a "register" !!! Of course, registers 
don't have addresses, so the compile breaks.  Changing "edgecolor"
to be an ordinary variable does compile ok.

-----------------------------------------------------------------
-----------------------------------------------------------------