From schneider@msbcs.ENET.dec.com  Fri Sep 27 16:58:16 1996
Received: from mail11.digital.com  for schneider@msbcs.ENET.dec.com
	by www.ccl.net (8.7.5/950822.1) id QAA16855; Fri, 27 Sep 1996 16:42:24 -0400 (EDT)
Received: from us1rmc.bb.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV)
	id QAA27678; Fri, 27 Sep 1996 16:34:40 -0400 (EDT)
Received: from msbcs.enet by us1rmc.bb.dec.com (5.65/rmc-22feb94)
	id AA05537; Fri, 27 Sep 96 16:36:10 -0400
Message-Id: <9609272036.AA05537@us1rmc.bb.dec.com>
Received: from msbcs.enet; by us1rmc.enet; Fri, 27 Sep 96 16:36:10 EDT
Date: Fri, 27 Sep 96 16:36:10 EDT
From: "Chuck (aka chazix), 508-493-1399 (DTN 223-1399)  27-Sep-1996 1545 -0400" <schneider@msbcs.ENET.dec.com>
To: chemistry@www.ccl.net
Cc: loh@msbcs.ENET.dec.com, schneider@msbcs.ENET.dec.com
Apparently-To: chemistry@www.ccl.net
Subject: re: CCL:f77 comp. on DEC alpha


Greetings,

I'm not usually a follower of this forum, but a colleague asked me if I could
respond to Rochus Schmid's inquiry about building deMon for an Alpha system. 
I will assume that the operating system is Digital UNIX.

I wouldn't say unaligned accesses are common when porting Fortran code to the
Alpha architecture, but they can certainly happen.  I can only make rather
general statements about what sort of code contructs cause unaligned accesses.
By default, the compiler assumes that data are stored at addresses that are a
multiple of the size of the data type - for example, INTEGER*4 data is
expected to be at an address that is a multiple of 4.  If this assumption is
broken, unaligned accesses are likely.  I would say that the easiest way for
this to happen in pure Fortran code is a mismatch between the data types of
the formal and actual parameters of a subroutine call - for example, passing a
REAL*4 argument to a subroutine that expects an REAL*8.

I would not assume that the problem is related to the 64-bit nature of the
Alpha architecture, since standard Fortran constructs don't have any notion of
the size of an address (as far as I can think of at the moment).  However, if
there is any use of POINTER types, or any non-Fortran code involved, there are
more possibilities for introducing unaligned accesses.

The statement that the program stops at the time of the unaligned access
puzzles me.  The operating system will "fix up" unaligned accesses so that
the access completes, albeit at a tremendous cost to performance.  It seems
more likely that the unaligned access is just the first symptom of a problem
that eventually results in the halt.  The program may stop so quickly after
the unaligned access that it appears to be simultaneous, but I would expect an
additional message about what actually stops the program - for example,
"signal segmentation fault".

To determine what's causing an unaligned access, one way is to disable the
operating system "fixup", so that the unaligned access will result in the
program being signaled.  The signal can be caught while running the program
under a debugger, or the program can be simply be run and allowed to dump a
core file upon receiving the signal, after which the core file can be examined
with a debugger.  For example, given a program named a.out:

$ uac p sigbus		! make unaligned access cause SIGBUS (see man 1 uac)
$ a.out			! run program
  (core dumped)
$ dbx a.out core	! use debugger to analyze core dump
dbx> where
$ uac p reset		! reset unaligned accesses to being fixed up

Regards,
Chuck Schneider
Digital High Performance Computing Expertise Center, Maynard, Massachusetts