Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!rutgers!cmcl2!edler
From: edler@cmcl2.NYU.EDU (Jan Edler)
Newsgroups: comp.unix.wizards
Subject: Re: M68020 and 4-byte alignment
Summary: we did it
Message-ID: <38172@cmcl2.NYU.EDU>
Date: 27 Feb 89 19:07:39 GMT
References: <1361@atari.UUCP>
Reply-To: edler@cmcl2.UUCP (Jan Edler)
Organization: New York University, Ultracomputer project
Lines: 35

In article <1361@atari.UUCP> achar@atari.UUCP (Alan Char) writes:
>I am interested in experiences people have had converting a UNIX system
>(operating system and utilities/applications) from 2-byte aligned to
>4-byte aligned, specifically, when upgrading from a 68000 environment to
>a 68020 environment.

We did this, but for a 68010 system, not a 68020 one.  Our motivation
was peculiar to our hardware (experimental shared memory
multiprocessor) - we built hardware to make loads and stores of
properly aligned longs atomic.

Anyway, other than recompiling everything, I don't recall the change
being terribly difficult.  We had to be careful to make all the
necessary compiler changes (e.g.  make sure automatics are properly
aligned), but that wasn't too bad.  I don't remember too many instances
of user code that had to change; there may have been a couple things in
the library, but they weren't hard to find.  For example, the user-level
signal handling code and the kernel trap handling code have to be
careful to maintain stack alignment properly.

The most difficult aspect of it is probably the complete
incompatibility of the change.  In general, you can't trust binaries
from before the changeover.  Also, we use cross compilers a lot, and it
is annoying that we need a special cross compiler, we can't use just
any old 68k cross compiler (e.g. one that also works for 68k-based
workstations or single-board computers).

We never looked into the question of how much faster the machine runs
with proper alignment, but I suppose it could be noticeable.

Jan Edler
NYU Ultracomputer Research Laboratory
(212) 998-3353
edler@nyu.edu
...!cmcl2!edler