home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / unix / cray / 243 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  2.0 KB

  1. Xref: sparky comp.unix.cray:243 comp.sys.super:909
  2. Path: sparky!uunet!dtix!darwin.sura.net!mips!apple!apple!malcolm
  3. From: malcolm@Apple.COM (Malcolm Slaney)
  4. Newsgroups: comp.unix.cray,comp.sys.super
  5. Subject: Re: Are there specific tools to assist in porting C to CRAY
  6. Summary: Use GREP
  7. Message-ID: <71317@apple.Apple.COM>
  8. Date: 18 Aug 92 04:45:38 GMT
  9. References: <1992Aug17.234228.16195@leland.Stanford.EDU>
  10. Organization: Apple Computer Inc, Cupertino, CA
  11. Lines: 33
  12.  
  13. In article <1992Aug17.234228.16195@leland.Stanford.EDU> buc@leland.stanford.edu (Robert Richards) writes:
  14. >
  15. >I am trying to port a C program to the Cray under UNICOS.  The slowest
  16. >part of the port is the 32-bit references that I have to convert to
  17. >CRAY's 64-bit world.  Are there any tools that help one find where
  18. >code is not 64-bit world compatible?
  19.  
  20. I've lost count of how many codes I've ported to the Cray.  It's not always
  21. hard, but then people are always doing things to screw you up.  I don't know
  22. of any specific tools, but I usually run a lot of greps.
  23.  
  24. First step, get the code to compile and run correctly with an ANSI C compiler
  25. on a 32 bit machine (or wherever the code is known to work correctly.)
  26. Most 64 bit portability problems won't be caught by the compiler but you
  27. really should start with a clean program.
  28.  
  29. Step two, look for all references (grep) to read and/or write.  Quite often
  30. this indicates that the program is doing binary IO...there is nothing wrong
  31. with this but it can indicate a problem with moving files to other machines.
  32. Redefine all binary IO in terms of a stream of bytes.
  33.  
  34. Look for unions (this one just got me).....these could be indications of 
  35. somebody trying to mess with the bits (overlaying a float and an integer,
  36. for example.)  Since you are doing ME and not EE I suspect you won't  see
  37. too much bit twiddling, either.
  38.  
  39. Finally, run the program and see where it stops.  
  40.  
  41. It's really not hard to write portable 64/32 bit code.....keep your fingers
  42. crossed.  Going the other way is even harder.
  43.  
  44.                             Malcolm Slaney
  45.                             Apple ATG
  46.