Xref: utzoo comp.arch:13684 comp.lang.c:25787 Path: utzoo!attcan!uunet!van-bc!ubc-cs!alberta!calgary!ctycal!ingoldsb From: ingoldsb@ctycal.UUCP (Terry Ingoldsby) Newsgroups: comp.arch,comp.lang.c Subject: Re: RISC Machine Data Structure Word Alignment Problems? Summary: How slow can you go? Keywords: risc sun Message-ID: <328@ctycal.UUCP> Date: 7 Feb 90 19:26:03 GMT References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> <1648@skye.ed.ac.uk> Organization: The City of Calgary, Ab Lines: 52 In article <1648@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes: > In article peter@ficc.uu.net (Peter da Silva) writes: > >Worse, since non-word-aligned values do cost extra cycles to access, any > >68020 C compiler that didn't pad that structure is broken. > > This is nonsense. Which you want depends whether speed or size is more > important. A valid criticism would be that too many C compilers don't let > you specify which kind of optimisation you want. > This discussion, IMHO, is pointless. The C compilers work just fine the way are (or at least the ones I am familiar with). I don't think some of the people discussing this realize the implications of what they propose. I work on an Intergraph Clipper based workstation. Unless I am mistaken, floating point values can only be aligned on 8 byte boundaries if the processor is to be able to access them in a single instruction. If you try to access a floating point value that is not 8 byte aligned, it actually grabs the value at the next lowest 8 byte boundary. It doesn't even give a bus error trap! In theory, the compiler could place it on arbitrary boundaries by generating a sequence of instructions that would read adjacent values and AND and OR the values into memory. It sounds to me that we are talking about 4 or 5 instructions to do this, so your access speed would be the pits! The reason people seem to want to be able to store values at arbitrary locations seems to have to do with the need to write out contiguous regions of memory to a binary file. They then complain that reading that file back into the memory of another machine doesn't work. No one ever said it would. If you want portable code, don't write it that way. It is almost always possible to sacrifice portability for speed. I don't know why this is so astonishing; you can't write out binary values for integers between machines, what would lead anyone to believe that structures should be any different. C is a low level language. If you want greater data abstraction, move to a higher level language that guarantees that data will appear to be in the same format across systems. That guarantee is not in the C definition; doing so would probably limit C's ability to blast bits. The only format that C guarantees to understand is ascii represented numeric values. The only thread of this discussion that might relate to comp.arch is why processors (such as Clipper) do not give a trap if you try to access memory on illegal boundaries. Surely that would not require much silicon? -- Terry Ingoldsby ctycal!ingoldsb@calgary.UUCP Land Information Systems or The City of Calgary ...{alberta,ubc-cs,utai}!calgary!ctycal!ingoldsb