Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!hplabs!ridge!klein
From: klein@ridge.UUCP (Doug Klein)
Newsgroups: comp.arch
Subject: Re: RISC data alignment
Message-ID: <354@ridge.UUCP>
Date: 27 Jan 88 18:18:04 GMT
References: <2635@calmasd.GE.COM> <3195@cbmvax.UUCP>
Organization: Ridge Computers, Santa Clara, CA
Lines: 74
Summary: Data alignment affects *much* more than just file compatibility!
	 Just getting correct, running applications can be impossible.

In article <3195@cbmvax.UUCP>, daveh@cbmvax.UUCP (Dave Haynie) writes:
> in article <2635@calmasd.GE.COM>, gjo@calmasd.GE.COM (Glenn Olander) says:
> 
> > Please forgive a possibly neophyte-type question, but is it true that
> > there may be an inherent incompatibility between RISC and conventional
> > machines? 
> 
> > If this is true, then it would seem to also be true that a C structure
> > could have different lengths, depending on whether it was compiled 
> > on a RISC or non-RISC machine.  
> 

Having spent the last four years porting large applications to a data
aligned machine (Ridge), I would warn you of more than just data file
compatibility!  This is potentially the least of your problems. To 
mention a few of the gotcha's I have run into:

FORTRAN example 1)

Programmer decides he needs a "array copy" routine. For whatever reason
he decides that the fastest way to copy data is to use:

	subroutine copy(a,b,count)
	double precision a(1),b(1)
	integer count
	do i=1,count
		b(i) = a(1)
	enddo
	return
	end

Now he calls it from somewhere as:

	integer x(100),y(100)
	...
	call copy(x,y,100)

The problem is that x and y are *potentially* word aligned, but the 
subroutine 'copy' uses double loads and stores! BLAM - alignment trap!
The scary part of this is the the alignment of x and/or y can be 
effected in a part of the program *very* far away, e.g., a common
block thousands of lines away. The other scary part is it may take
many, many sample input sets to hit this case.

FORTRAN example 2)

I've seen older FORTRAN programs that try to do forms of stack 
manipulation by allocating a large array, (real buffer(100000) comes
to mind), and then poking arbitrary structures into arbitrary places
in these arrays - lots of potential alignment problems here! 
This happens frequently with EQUIVALENCE statements.
(In particular reference to the originator of this discussion, Calma's
DDM is a nightmare for this problem).


Fortunately, large C applications tend to have been developed with the
idea of portability, and *usually* have run into alignment issues 
early in their development life. Warning flags should fly, though,
when looking at code that runs only on VAXen or 68k boxes. 

Similar to FORTRAN example 2, a common practice in large C applications
is to malloc a big chunk of space, and then start putting arbitrary
structures in it. I've seen this in several of the large commercial
rendering codes, which do a lot of their own "stack" manipulation.
The workaround has usually been to put some "aligning" code into
the low-level routines, i.e., look at the actual address mod'ed with
4 (or 8, or whatever), and then adjust appropriately.

Casting something can cause the compiler to generate an instruction
with strict alignment restraints when the object being cast is not
aligned. (I haven't personally run into this many times).


Doug Klein