Date: Thu, 20 Jan 2000 09:55:27 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Peter Wemm <peter@netplex.com.au>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin Makefile src/usr.bin/uac Makefile uac.1 uac.c Message-ID: <Pine.BSF.4.21.0001200942380.1624-100000@alphplex.bde.org> In-Reply-To: <200001191810.NAA30224@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jan 2000, Garrett Wollman wrote:
> <<On Thu, 20 Jan 2000 02:09:18 +0800, Peter Wemm <peter@netplex.com.au> said:
>
> > Is it necessarily Alpha specific? What about sparc? MIPS? other risc cpus
> > that might require manual fixups for unaligned accesses?
>
> i386en with the AC bit set in EFLAGS?
i486en :-). The AC bit isn't implemented on plain i386's.
Unfortunately, gcc still doesn't generate aligned accesses for all cases,
e.g., for copying properly aligned but non-4-byte aligned structs:
---
struct misaligned {
char x[16];
};
struct {
int x;
char y;
struct misaligned z;
} x, y;
main()
{
/* The magic 0x40000 is PSL_AC. */
asm("pushfl; popl %eax; orl $0x40000,%eax; pushl %eax; popfl");
x.z = y.z;
}
---
The struct assignment is implemented as 4 misaligned load-stores, so the
above traps on the first load the assignment.
The "fixup" on i386's can be as simple as turning off the AC bit it the
kernel, but this defeats the point of applications setting their AC bit
in order to find all pessimal alignments.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0001200942380.1624-100000>