Xref: utzoo comp.lang.c:15871 comp.sys.m68k:1091
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!skat.usc.edu!blarson
From: blarson@skat.usc.edu (Bob Larson)
Newsgroups: comp.lang.c,comp.sys.m68k
Subject: Re: Address error quietly fixed on 680x0 systems
Keywords: 68k, sparc, portability
Message-ID: <14995@oberon.USC.EDU>
Date: 28 Jan 89 22:22:51 GMT
References: <302@puivax.UUCP>
Sender: news@oberon.USC.EDU
Reply-To: blarson@skat.usc.edu (Bob Larson)
Followup-To: comp.sys.m68k
Distribution: usa
Organization: USC AIS, Los Angeles
Lines: 18

[note re-directed folloups, this isn't a C issue.]

In article <302@puivax.UUCP> ian@puivax.UUCP (Ian Wilson) writes:
>A piece of code I inherited recently contained the fragment:
>	*((INT_16 *) charbuf_p) = x; charbuf_p += sizeof(INT_16);
>where charbuf_p had no alignment restrictions enforced, including
>no restriction on being an odd address. To my surprise, this turns
>out to work on 680x0 systems, both Sun3 and a vanilla Mac.

The 680n0, with n>=2 does handle this by doing multiple bus cycles.
Thus, the Sun3 (68020) would not need any trap handler to run this
non-portable code.

-- 
Bob Larson	Arpa: Blarson@Ecla.Usc.Edu	blarson@skat.usc.edu
Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson
Prime mailing list:	info-prime-request%ais1@ecla.usc.edu
			oberon!ais1!info-prime-request