Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!zaphod.mps.ohio-state.edu!usc!apple!snorkelwacker!spdcc!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.lang.misc
Subject: Re: NOT Educating FORTRAN programmers to use C
Message-ID: <1990Jan12.235347.5167@esegue.segue.boston.ma.us>
Date: 12 Jan 90 23:53:47 GMT
References: <649@chem.ucsd.EDU> <15643@haddock.ima.isc.com>
Sender: johnl@esegue.segue.boston.ma.us (John R. Levine)
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Distribution: na
Organization: Segue Software, Cambridge MA
Lines: 23

On the last machine I saw that had problems with misaligned doubles, a
360/91, the Fortran compiler generated code assuming that there were no
alignment problems and the runtime system caught the alignment fault and
fixed it up, slowly, allowing the 99.9% of programs without alignment
problems to run at full speed and permitting the rest at least to run.

When IBM went to the 370 series they permitted misaligned operands, and that
particular problem went away.  In an article in the CACM a few years ago one
of the designers of the 370 said that in practice very few 370 programs use
misaligned operands and in retrospect the performance loss wasn't worth it,
they should have stuck with alignment.

This suggests that while something like explicit unaligned pointers would
work, a better solution is to write your programs so they don't have
alignment problems in the first place.  It's not very hard, most of the
misaligned data I've seen is either due to badly written I/O routines or
overenthusiastic bit squishing.  I have never understood why so many unix
programs (particularly those written in Berkeley, California) have alignment
problems, it must be all that VBD.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."