🚀 go-pugleaf

In article <1992Aug17.234228.16195@leland.Stanford.EDU> buc@leland.stanford.edu (Robert Richards) writes:
>
>I am trying to port a C program to the Cray under UNICOS.  The slowest
>part of the port is the 32-bit references that I have to convert to
>CRAY's 64-bit world.  Are there any tools that help one find where
>code is not 64-bit world compatible?

I've lost count of how many codes I've ported to the Cray.  It's not always
hard, but then people are always doing things to screw you up.  I don't know
of any specific tools, but I usually run a lot of greps.

First step, get the code to compile and run correctly with an ANSI C compiler
on a 32 bit machine (or wherever the code is known to work correctly.)
Most 64 bit portability problems won't be caught by the compiler but you
really should start with a clean program.

Step two, look for all references (grep) to read and/or write.  Quite often
this indicates that the program is doing binary IO...there is nothing wrong
with this but it can indicate a problem with moving files to other machines.
Redefine all binary IO in terms of a stream of bytes.

Look for unions (this one just got me).....these could be indications of 
somebody trying to mess with the bits (overlaying a float and an integer,
for example.)  Since you are doing ME and not EE I suspect you won't  see
too much bit twiddling, either.

Finally, run the program and see where it stops.  

It's really not hard to write portable 64/32 bit code.....keep your fingers
crossed.  Going the other way is even harder.

							Malcolm Slaney
							Apple ATG

	We have a Cray Y-MP running Unicos 6.0, CF77 version 5.0, and
Cray Standard C release 3.0.  I have a C driver that calls a FORTRAN
subroutine with common data between the two (i.e., a C struct defined
outside the main, and a corresponding FORTRAN common block).  What I'm
trying to do is execute 'segldr' with the -f option set to '-indef', so
that any unitialized common variables are supposed to be 10605054(octal).
When I execute 'segldr' with the two .o files, however, and print out
the common variables in the C program before calling the FORTRAN
subroutine, they are coming out 0.  If I take out the call to the FORTRAN
routine, recompile and segldr again, they come out negative indefinite --
the same is true if I make the FORTRAN routine a standalone program.

Is there something special that must be done with segldr to get it to
work with object files generated by different types of compilers, or
am I completely missing something?

Here's the C code:
-----------------------------------
#include <stdio.h>
struct {
	int a;
	float b;
}
CB;
main()
{
	printf("in main, before WRITDAT, a= %o b= %o\n",CB.a,CB.b);
	WRITDAT();
}

And the FORTRAN code:
-------------------------------------
	SUBROUTINE WRITDAT
	COMMON /CB/ A, B
	INTEGER A
	REAL B
 100	FORMAT(O64)
	PRINT *, 'IN WRITDAT:'
	WRITE (*,100) A
	WRITE (*,100) B
	RETURN
	END

Then to compile and load:

cc -c dum.c
cft77 writdat.f
segldr -f -indef -o xxx dum.o writdat.o

Thanks,
Kathryn Cables
Naval Surface Warfare Center
kcables@relay.nswc.navy.mil