bill@proxftl.UUCP (T. William Wells) (08/30/88)
In article <1673@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes:
: The best way to learn to write portable code is to be required to port
: your applications to Vaxes, 68000s, and PCs. (I have all 3 on my desk!)
We find that using 68000's (Suns and Macintoshes) and IBM-PC's
(in the various memory models) is sufficient to catch most
portability problems. Especially since we avoid as much as
possible using system provided libraries and do not do terminal
I/O except through standard I/O.
Anybody else have suggestions on sets of systems for checking
portability? And how about portability between different system
libraries and different terminal handling schemes, a problem we
don't (yet) have because we ignore it?
---
Bill
novavax!proxftl!billfouts@lemming.nas.nasa.gov.nas.nasa.gov (Marty Fouts) (08/30/88)
I have the (mis)fortune of having access to a wide range of machines, and find that portability issues fall into about four catagories: (for me, your milage may vary) 1) floating header files (where is struct mumble defined, where does header file bletch.h live, etc.) 2) library differences (is it in libc, or libm, is it strchr or rindex, does it exist or do I have to carry my own version along. . .) 3) Implementation problems (working around bugs in the system. . .) 4) Architecture dependencies due to language design or implementation decisions left to the implementer. (it worked on my brand x, but after I tried it on brand y, I went back and read K&R and sure enough its not legal. . .) The rude fact is that the first three can't be covered by any small set of machines, although a fairly good aproximation can be made by trying a System V machine, a BSD machine, an MS-DOS machine, and a non- un*x machine. (VAX/VMS, Apollo) As far as the fourth goes, I have been bitten by the following collection of dumb assumptions: 1) byte ordering 2) word size 3) "all pointers are == char *" 4) calling stack implementation 5) assuming a linear address space without holes My collection of machines which ring out these problems is fairly small, but probably not widely accessable. I find that I can get by with only three machines to cover all of the dumb assumptions: A Vax 11/780, a Cray 2, and an Silicon Graphics Iris 4D. The Cray system seriously strains dumb assumptions in 1-3 and 5, and the Iris gets 4. Without the 2, a much larger collection of machines would be needed, but I suspect that a lot could be accomplished with an IBM PC and a SUN-3 as an alternative. Anyway, I don't assume that code I've written is reasonably portable, until it compiles and appears to work on 16, 32 and 64 bit machines of varying byte order, memory model and calling stack implementation, and then I only assume that it is reasonably portable and that I've blown it for the next class of machines I'm going to see. This is a very healthy paranoia to develop. Marty +-+-+-+ I don't know who I am, why should you? +-+-+-+ | fouts@lemming.nas.nasa.gov | | ...!ames!orville!fouts | | Never attribute to malice what can be | +-+-+-+ explained by incompetence. +-+-+-+
chip@ateng.uucp (Chip Salzenberg) (08/31/88)
According to bill@proxftl.UUCP (T. William Wells): >We find that using 68000's (Suns and Macintoshes) and IBM-PC's >(in the various memory models) is sufficient to catch most >portability problems. You forgot the best one: any '286 running SCO Xenix System V. I like to refer to my machine as a portability test with a power switch. -- Chip Salzenberg <chip@ateng.uu.net> or <uunet!ateng!chip> A T Engineering My employer may or may not agree with me. The urgent leaves no time for the important.
ddb@ns.UUCP (David Dyer-Bennet) (08/31/88)
In article <673@proxftl.UUCP> bill@proxftl.UUCP (T. William Wells) writes: >In article <1673@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >: The best way to learn to write portable code is to be required to port >: your applications to Vaxes, 68000s, and PCs. (I have all 3 on my desk!) > >We find that using 68000's (Suns and Macintoshes) and IBM-PC's >(in the various memory models) is sufficient to catch most >portability problems. > >Anybody else have suggestions on sets of systems for checking >portability? No portability check is complete until you've tried some word-oriented rather than byte-oriented system. Preferrably something with a word-size not a multiple of 8 bits (like 60, or 36). CDC, Unisys, Honeywell, and of course the DEC PDP-10 series all come to mind. Also, while I haven't tried it personally, I remember a LONG string of articles years ago in some group with the subject "Porting to PRIME seen as a probable negative experience"; I seem to remember it has to do with different types of pointers being of different sizes, none of which would fit in in an int. -- -- David Dyer-Bennet ...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300
g-rh@cca.CCA.COM (Richard Harter) (09/01/88)
In article <795@ns.UUCP> ddb@ns.UUCP (David Dyer-Bennet) writes: > Also, while I haven't tried it personally, I remember a LONG string of >articles years ago in some group with the subject "Porting to PRIME seen >as a probable negative experience"; I seem to remember it has to do with >different types of pointers being of different sizes, none of which would >fit in in an int. This is somewhat of a bum rap. Prime C at one time had 48 bit char pointers versus 32 bit word pointers. Currently all pointers are 48 bits. This makes for problems for people who blithely stuff pointers into ints. But it really isn't a problem for people who port from UNIX to PRIMOS who run their code through lint (and act on the results). Primos C does have some oddities. They set the high bit on in ascii chars. Setting a file pointer to stdin or stdout has to be done at the top level. Library routines sometimes have different calling sequences. There is a 128K limit on array sizes (machine architecture). But it really isn't all that bad; I've never seen the C compiler break on standard portable C which is more than I can say for VMS C. -- In the fields of Hell where the grass grows high Are the graves of dreams allowed to die. Richard Harter, SMDS Inc.
jv@mhres.mh.nl (Johan Vromans) (09/01/88)
From article <673@proxftl.UUCP>, by bill@proxftl.UUCP (T. William Wells): > Anybody else have suggestions on sets of systems for checking > portability? I have used an Hewlett-Packard HP9000 model 500, which has a very strange memory architecture (uses non-contiguous memory segments), and a real stack (which means that uninitialized local variables contain a zero). Emacs cannot run on it. There exists a Pr1me system which always has the high bit of each byte set, so ASCII runs from 128 to 255. Of course, EBCDIC machines catch most of the programs which avoided <ctype.h> but use ('a' <= x && x <= 'z') , and segmented memory machines (like PC's with large model) catch all programs that (mis)use ints and pointers and longs. -- Johan
smryan@garth.UUCP (Steven Ryan) (09/02/88)
>Anybody else have suggestions on sets of systems for checking >portability? And how about portability between different system >libraries and different terminal handling schemes, a problem we >don't (yet) have because we ignore it? I would think Vaxes, IBM-PCs, Suns, and Macs are somewhat incestuous. If you have the money and are interested in the market, you might try some radically different hardware and operating systems like mainframe IBM, Cray, CDC, Fujitsu,.....
daveb@geac.UUCP (David Collier-Brown) (09/02/88)
>>In article <1673@dataio.Data-IO.COM> bright@dataio.Data-IO.COM (Walter Bright) writes: >>: The best way to learn to write portable code is to be required to port >>: your applications to Vaxes, 68000s, and PCs. (I have all 3 on my desk!) From article <795@ns.UUCP>, by ddb@ns.UUCP (David Dyer-Bennet): > No portability check is complete until you've tried some word-oriented > rather than byte-oriented system. Preferrably something with a word-size > not a multiple of 8 bits (like 60, or 36). CDC, Unisys, Honeywell, and of > course the DEC PDP-10 series all come to mind. Actually the 9-bit byte machines are fairly easy to port to: all sorts of code of varying quality will run on the Honeywell-Bull DPS-8 using the Waterloo C Compiler. Try a machine with funny pointer lengths like the DPS-6, though... Its an 8-bit byte, but char pointers are 48 bits and others are 32, if you use to high an address the system will trap even loading a register, etc, etc. --dave (Bell labs had a DPS-8 C compiler many moons ago) c-b -- David Collier-Brown. |{yunexus,utgpu}!geac!lethe!dave 78 Hillcrest Ave,. | He's so smart he's dumb. Willowdale, Ontario. | --Joyce C-B
rogerk@mips.COM (Roger B.A. Klorese) (09/02/88)
In article <2305@mhres.mh.nl> jv@mhres.mh.nl (Johan Vromans) writes: >From article <673@proxftl.UUCP>, by bill@proxftl.UUCP (T. William Wells): >> Anybody else have suggestions on sets of systems for checking >> portability? >There exists a Pr1me system which always has the high bit >of each byte set, so ASCII runs from 128 to 255. Yes, *all* of 'em. (At least, all of the "50 Series" proprietary processors.) -- Roger B.A. Klorese MIPS Computer Systems, Inc. {ames,decwrl,prls,pyramid}!mips!rogerk 25 Burlington Mall Rd, Suite 300 rogerk@mips.COM (rogerk%mips.COM@ames.arc.nasa.gov) Burlington, MA 01803 I don't think we're in toto any more, Kansas... +1 617 270-0613