Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!MATHOM.GANDALF.CS.CMU.EDU!lindsay
From: lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
Newsgroups: comp.arch
Subject: Re: RISC hard to program?
Message-ID: <9895@pt.cs.cmu.edu>
Date: 13 Jul 90 16:47:20 GMT
References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca> <1139@carol.fwi.uva.nl>
Organization: Carnegie-Mellon University, CS/RI
Lines: 33

In article <1139@carol.fwi.uva.nl> beemster@fwi.uva.nl 
	(Marcel Beemster) writes:
>In general my feelings towards
>software development are: "If it runs on s SPARC, it runs everywhere",

It's good for portability to develop code on the _least_ forgiving
machine that you can find.

I once did it the other way around, to my sorrow.  We had a large
compiler that ran on a DEC-20, and was supposedly working.  I ported
it to a VAX with BSD 4.2, and there were no end of seg faults.  Why?
Well, the 20 had a virtual address space of 256 KW.  So, a large
compiler which generated a wild address would reference something
that existed.  In a 4 GB space, that changed.  Further, it turned out
that the average wild pointer was used for reads, gathering data
which resulted in a boolean decision.  So, there had always been a
fair chance that the branch would go the right way!

Then I ported it from the VAX to a Sun-3.  Another disaster!  Sun had
intelligently made page zero illegal, so that nul pointers would
trap.

If the original development had been done on the most unforgiving
machine, the ports would have been started a bit later - but would
have been finished sooner.

In general, the best way to develop portable code is to force the
original development to happen on two machines at once.  This means
that the original team is still there during that crucial first port.
Plus, portability issues can surface _before_ the design is frozen.

-- 
Don		D.C.Lindsay