🚀 go-pugleaf

In <LJ81OX3ggpc2@ficc.uu.net>, 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