Path: utzoo!attcan!uunet!munnari.oz.au!comp.vuw.ac.nz!kaukau.comp.vuw.ac.nz!waikato!virtue!ccc_ldo From: ccc_ldo@waikato.ac.nz Newsgroups: comp.arch Subject: Re: RISC Machine Data Structure Word Alignment Problems? Summary: Pad fields? Just say No! Keywords: risc pad correctness alignment efficiency space_time_tradeoff Message-ID: <78.25d06890@waikato.ac.nz> Date: 7 Feb 90 14:45:47 GMT References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> Lines: 51 In , peter@ficc.uu.net (Peter da Silva) deplores the fact that VAX and 680n0 (n > 1) processors allow word and longword accesses on arbitrary byte boundaries, saying that "since non-word-aligned values do cost extra cycles to access, any 68020 C compiler that didn't pad that structure is broken." GAK! I can't believe I'm reading this! He goes on to say: "Some 'features' of CISC processors are just too expensive to use." So what's the alternative? Have you tried counting how many extra cycles you spend doing explicit byte-by-byte accesses? The thing is, as a programmer, I want to be able to make the tradeoff (space versus time) myself. Sure byte-packed structures will cost more memory cycles to access, and bit-packed structures even more so. But there are times when I'm willing to pay the cost--think of an array of a hundred thousand 3-byte records, or a million boolean elements. I heartily *RESENT* CPU designers who take it upon themselves to say "Nope--that alternative costs a few too many memory cycles for us to be comfortable with, so we'll leave out the hardware support for it, and force you to do it in software should you feel the urge, which will make it even *MORE* expensive." Even Motorola aren't completely free of this disease. Look at the 68881/68882 floating-point units, which put an extra 16 padding bits into every extended- precision quantity, just so they take up an even number of longwords. I don't like compilers which automatically insert padding bits and bytes between elements of arrays and structures--which is to say, most of them. My argument is based on a very simple principle: "correctness comes before efficiency". Pad fields can cause all kinds of problems, not just when different compilers follow different rules in inserting them: think of what happens when you're trying to compare two objects which happen to differ only in the random garbage in the pad fields. I'd rather have a compiler which allowed me to specify explicit alignment constraints on element types (with the default being byte alignment for everything), and which reported errors with element offsets that didn't match their alignment constraints--that is, I was forced to put in padding fields myself (so that I knew where they were and how big they were), rather than having the compiler do it for me. In conclusion, I'll say it again. *I'M* the programmer, *I'M* the only one who knows what the performance requirements of my program are (including its memory usage), let *ME* make the tradeoff decisions. Lawrence D'Oliveiro Computer Services Dept, University of Waikato Hamilton, New Zealand ldo@waikato.ac.nz