Newsgroups: comp.arch
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!ficc!peter
From: peter@ficc.ferranti.com (Peter da Silva)
Subject: Re: Segmented Architectures ( formerly Re: 48-bit computers)
Message-ID: <Y-FA4Y4@xds13.ferranti.com>
Reply-To: peter@ficc.ferranti.com (Peter da Silva)
Organization: Xenix Support, FICC
References: <1991Mar27.172325.10800@sj.nec.com> <7920@uceng.UC.EDU> <VWEAP86@xds13.ferranti.com> <3305@crdos1.crd.ge.COM>
Date: Tue, 2 Apr 91 22:29:08 GMT

In article <3305@crdos1.crd.ge.COM> davidsen@crdos1.crd.ge.com (bill davidsen) writes:
> In article <VWEAP86@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> | N nice and effectively compatible ones. Outside of the 80x86 family, all
> | my big portability problems are caused by differences in *software*
> | architectures or buggy code. 

>   All that bigendian vs. little endian stuff is just a bad dream, right?

No, it's just not a big problem.

> And the problems we've had porting between 32 and 64 bit computers
> didn't happen?

You mean between 16 and 32 bit computers? No, it's not a big problem.

Let me explain this point a bit more: the places where endianness, and
the size of pointers not being the same size as ints, and that sort of
thing cause problems are relatively small, and can generally be easily
fixed. 90% of these problems are the result of someone trying to use
an internal data structure for external storage. The remaining 10% are
caused by buggy code. Or buggy compilers.

Really. Anyone who writes ``execl("/bin/sh", "sh", "-i", 0)'' has just
written buggy code.

And it's easy enough to fix. A pass through lint, and I'm a happy camper.
My big problems in porting code are where people assume things like:

	malloc will not fail.
	arrays can be grown indefinitely.
	pointers in different objects can be compared.

All of these things are reasonable assumptions on an 80386, a 68000, a
VAX, a SPARC, etc... They die horribly on the 8086 family of processors,
and fixing the code tends to require a major rewrite.

>   You've been around long enough to know better. The cause of
> portability problems is code which makes assumptions about the hardware.

This is true, but apart from the 8086 family of processors portability
problems are easy to fix. Toss in a few casts or go to ANSI compilers and
everything's right as rain. But there's nothing I can do with an attempt
to malloc(100000) other than cripple the program or redesign it.

Nope... I'll stand on my claim that after working with the 8086 and its
derivatives any other hardware portability concerns are cake.
-- 
Peter da Silva.  `-_-'  peter@ferranti.com
+1 713 274 5180.  'U`  "Have you hugged your wolf today?"
