Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!mailrus!ames!vsi1!wyse!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.sys.m68k Subject: Re: quad-aligning the 68020 stack Keywords: 68020 stack longword alignment quad Message-ID: <2759@winchester.mips.COM> Date: 11 Aug 88 02:26:47 GMT References: <2194@uhccux.uhcc.hawaii.edu> <4431@cbmvax.UUCP> <2727@winchester.mips.COM> <4434@cbmvax.UUCP> Reply-To: mash@winchester.UUCP (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 30 In article <4434@cbmvax.UUCP> ford@kenobi.cts.com (Mike "Ford" Ditto) writes: >In article <4431@cbmvax.UUCP> ditto@cbmvax.UUCP (That's me) wrote: >>For real 32-bit 68020 systems, I am a firm believer in keeping all >>stacks and structures longword aligned at all times. > >In article <2727@winchester.mips.COM> mash@winchester.UUCP (John Mashey) writes: >>Right philosophy, but consider thinking further ahead to 64-bit objects, >>at least. > [ ... ] > >I don't see a real reason for this. Admittedly, the older 68000 compilers >that only aligned to 16 bits were a mistake, but that is because the 68000 >has a 32-bit archetecture. I can't imagine an extention to the 68000 >archetecture that will have objects larger than 32 bits (other than floats) >nor an object-code-compatible chip with a wider-than-32-bits data bus. >64-bit chips and memories are certainly on their way to popularity, but >they really don't have much affect on 680x0 performance decisions, or >vice-versa. No major disagreement, i.e., the main motivation was for the broadest possible portability (as I have no personal interest in improving in the speed of 68K-based systems :-). In some systems that one might design with external caches, it might be a performance or cost improvement if 64-bit things were usually on the correct boundaries. (Very minor). -- -john mashey DISCLAIMER:UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086