Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!lll-lcc!qantel!ihnp4!cuae2!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.lang.c
Subject: Re: Re: structure alignment question
Message-ID: <1195@ttrdc.UUCP>
Date: Wed, 24-Sep-86 20:41:20 EDT
Article-I.D.: ttrdc.1195
Posted: Wed Sep 24 20:41:20 1986
Date-Received: Fri, 26-Sep-86 03:10:28 EDT
References: <101@hcx1.UUCP> <7363@sun.uucp> <696@mips.UUCP> <7447@sun.uucp> <1705@mcc-pp.UUCP>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 79

In article <1705@mcc-pp.UUCP>, tiemann@mcc-pp.UUCP (Michael Tiemann) writes:
>> > Note that for speed, it is usually best to align data items on the most
>> > restrictive boundaries, even if a specific machine implementation doesn't
>> > really require it.  Lots of machines let words be on arbitrary boundaries,
>> > but you pay for it in speed, if not now, then later, as CPUs come
>> > to have wider data paths.
>I was waiting for SOMEBODY to talk performace for once. The last 68000
>compiler I used aligned strings on WORD boundaries. This would cost
>one byte per string, half the time. But there was a big speed payoff:
>I could do word operations in my strnlen, strncmp, strncpy, and whatever
>other string processing functions I happened to write. All this code ported
>to a Sun-3 no (apparent) problem, but crashed on a Sun-2, because the SUN
>compiler allocated strings in a totally stingy 1-byte alignment.
>So now, all this "fast" code actually runs slower than a "dumb" byte-copy
>model, because the 68020 faults itself to death reading in 32-bit words
>on odd boundaries, and doesn't run at all on a Sun-2 because the 68010
>can read odd words.
 ^^^ can't, you mean?

What's more, what if there lay data in the byte after the end of a string
being copied to which was not an integral multiple of your copy-quantity
(4 bytes or whatever)?  That byte (and possibly more) will get clobbered,
unless you stop short of that point and finish the operation using byte
operations.  For that matter, compare of null-terminated string operations
also would need similar handling to make the compares valid (and you then
need to know the length of the string anyhow first).  (If all strings involved
were counted strings a la fortran, that would be a different story.)

But for the functions where word-operations would make sense if possible,
one could check whether the pointer(s) being passed were appropriately
aligned to choose the method (word operations or byte operations).  This
would be something like

func(ptr,count) char *ptr; int count;
{
	if (ptr & 01) {
		/* byte operations */
		...
	} else if (ptr & 02) {
		/* short word operations */
		...
	} else {
		/* long word operations */
		...
	}
}

I'm sure details would need to be worked out, (and why not use the
word operations in the middle of even a misaligned string?) but I wonder
if this would prove useful?

One could probably also force string alignment by using a union, but
it might be unwise to depend on it, as well as it being unwieldy for
places where inline data "texttexttext..." strings would normally be
used.

>Now I *know* you're not *supposed* to do things like that, but often
>high performance comes not by reading some 20 year old manual, but
>by analyzing the machine at hand, and trying to more than just
>accomodate it. Tune those compilers, comment those machine dependencies,
>and watch the code fly!
>I suppose that this letter was a bit of a flame, sorry.
>Y'all are welcome to flame me back,
>
>Michael
>tiemann@mcc.com

If you do this kind of thing, for the sake of portability #ifdef it for
the targeted machine(s) and supply a safely portable, if slow, alternative
for others.  Otherwise somebody is gonna come along, port the code to
some machine you never dreamed of, and it will crash and burn.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy