Path: utzoo!attcan!uunet!husc6!purdue!umd5!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Portability and alignment constraints
Message-ID: <11567@mimsy.UUCP>
Date: 19 May 88 09:18:57 GMT
References: <2853@pasteur.Berkeley.Edu> <51436@sun.uucp> <524@wsccs.UUCP> <10886@steinmetz.ge.com>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 40

In article <10886@steinmetz.ge.com> davidsen@steinmetz.ge.com
(William E. Davidsen Jr) writes:
>  Without commenting on the original issue ... I would like to say that
>Terry is *not* the only person getting in trouble on the Sun4.

(Probably not; but no one else seems to immediately denounce the
machine because of this.)

>A number of major machines (VAX, 80x86, 68xxx) lose
>performance when alignment is not preserved for 2 byte and 4 byte
>quantities, but they will access the data.

On the other hand, a number of major machines (Pyramid, before the
microcode tweak that allowed *(long*)((addr&~3)+2); CCI/Harris/Sperry
Power 6/32; and as you mention, some Honeywell machines) have
restrictions like those in the SPARC architecture.  As far as
I know, the Pyramid still disallows short and long word accesses
on odd byte addresses, as does the 68000 and 010 (but not 020)
and the venerable PDP-11 series.

>  Since there is no alignment algorythm which applies in all cases,
>exchanging binary data requires some assumption, and that is "no
>alignment.'

Exchanging binary data has more than just alignment problems: aside
from integer endian-clashes, there are a multitude of floating point
formats.  Not even the number of bits per byte is fixed.  Portable
programs rely on some other method of exchanging data (RPC library,
ASCII interchange, etc.).

As long as the claim is only `I do not like it', I shall stand aside.
I am not unsympathetic---I had to fix numerous Vaxisms in Gosling Emacs
when we first got our Pyramid (one of those that did not support
*(long*) unless the address was 0 mod 4); finding all of these was no
fun at all---but when someone claims that the machine is `broken', or
does not abide K&R, or various other falsehoods, I will post
corrections.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris