Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: net.unix-wizards,net.arch Subject: Re: Boundary alignment: Ken Reek responds (LONG!) Message-ID: <3867@utzoo.UUCP> Date: Wed, 16-May-84 19:58:59 EDT Article-I.D.: utzoo.3867 Posted: Wed May 16 19:58:59 1984 Date-Received: Wed, 16-May-84 19:58:59 EDT References: <1052@ritcv.UUCP>, <2543@watcgl.UUCP> Organization: U of Toronto Zoology Lines: 143 Dave Martindale has addressed some of Ken Reek's comments; here's some more rebuttal... > Simple hardware wins on more counts than just making life easier for > lazy engineers. It is simpler and cheaper to build, ..., more reliable, > easier to fix when it breaks, etc etc. Yes, simple hardware is easier to design, easier to fix, and all of the rest. But it is a lot less useful. How simple should it be? An abacus is pretty simple, for example. The whole point of the RISC notion is that the hardware can be made dramatically simpler *without* losing anything important. You haven't demonstrated that "aligned" machines lose anything important -- the inability to run unportable software is hardly significant, or the RISC would be doomed by its inability to run VMS. > (omitted from above) simpler for the software to run (comparing an 11/44 to > the nightmare complexity of the VAX i/o structure, for example, tells you > why 4.2BSD is so bloated) You are confusing implementation with interface. The functions you choose to implement do not determine the interface between the hardware and the soft- ware; consider the many different ways that different machines support I/O. On the Vax, it is the complexity of the interface that causes the problems, not underlying implementation. Complexity of implementation usually rears its ugly head in the interface as well. Even things like caches and unaligned-operand features do show up, if you think about it carefully. Ask someone who's written operating-system memory-management code what he thinks of unaligned operands that can straddle page boundaries. No, unaligned operands are *not* free of software complexities, although the extra complexity they introduce is at least localized. > Don't forget that magic word "cheaper". It has become fashionable > to say "software costs totally dominate hardware costs", but most > people forget to add "...unless you can't afford the hardware in the > first place". Hardware and software money don't usually come out of > the same pot, and the people who make decisions about such things are > not necessarily as enlightened as we are. Then enlighten them! If you buy a machine on which software development is difficult only because that machine is cheaper, you're not making a very good decision. It's up to those who know about such things to educate those that "make the decisions" about the false economy of choosing a machine based only on price. I don't know about you, but my software development would not be one cent cheaper on an unaligned machine. (My current machine, a PDP11, is aligned.) Clean, portable software has no problem with such a machine. > And once again, don't forget the example of the VAX: sure, it looks > like a nice machine, but it's grossly overpriced for its market now. > This is despite massive use of [semi-]custom ICs on the more recent > VAXen -- and you would not believe what a disaster that is for > production and maintenance! (There is an awful lot to be said for > using standard parts, which means restricting yourself to things that > can be built economically with them.) Are you suggesting that it would have been better to build Vaxen from 7400 series logic? I think not. Read that last parenthesized sentence again -- the point is not that you should use standard parts even for jobs that they can't do, but that you should restrict your jobs to things that standard parts *can* do. It actually is possible to implement a VAX in 7400's -- what do you think the 780 is made of? -- it's just hard and expensive. > I have heard, from reliable sources, that if/when the successor to the VAX > emerges, the biggest difference will be that it will be much simpler. That's the interface again, not necessarily the implementation. See earlier for comments on the visibility of implementation complexities. > If you can show me a way to eliminate alignment constraints without a > speed penalty, WITHOUT adding large amounts of hardware (which I could > use better to make the aligned version faster), I'd love to hear about > it. It's hard. Page 200 of the Vax Hardware Handbook describes how it is done with a cache on the 780. The same can be (is!) done with data, using a larger cache to compensate for the less sequential nature of data accesses. Please read your Vax Hardware Handbook more carefully. The same is *not* done with data, unless the data item fortuitously happens to fall within an 8-byte-aligned doubleword. A data item that straddles an 8-byte boundary in memory will take two fetches, i.e. a speed penalty. Nor is the presence of the cache an "out": caches cost hardware. Lots. The VAX has already paid this particular price for other reasons -- stupid memory-system interface design -- but this doesn't make the cache free. Well-designed machines in this speed range don't need caches at all. > But actually, most of this is beside the [original] point. We are not > talking about some decision which makes life a lot harder for the poor > software jockey. We are talking about a decision which requires more > memory to get equivalent performance. There is a perfectly straight- > forward hardware-vs-hardware tradeoff here: is it cheaper to build > a machine that doesn't care about alignment, or to just stack more > memory on a machine that does care? I would give long odds that the > latter approach wins, even just on initial cost. When you think about > things like reliability and maintenance, it wins big. Good point. However, for programs that dynamically allocate space, the size of the largest problem that can be handled is determined by how efficiently you use that space. For ANY given memory size, the program that more efficiently uses the space can handle larger problems. Of greater concern, though, is where all that data resides when the program is not actually running. Can you add additional disk space to hold all of the wasted space in your data structures as cheaply as you can add main memory? I would be upset if I had to buy another drive because all of my existing ones were full of data that was 25% wasted space. Sure, you can pack them on disk and unpack them when you read them, but you are then trading away execution efficiency. You have not refuted my point at all. Granted that adding memory (be it main memory or disk) costs money, it's still cheaper and simpler than adding unaligned-operand hardware. > I agree that this doesn't help the poor people who have made a big > investment in data structures that assume no alignment constraints. > These people have made a mistake, period: they have imbedded a major > machine-dependent assumption in software that obviously should have > been portable. This is my whole point -- alignment should NOT be machine dependent. There is an anecdote attributed to Abraham Lincoln. He asked a riddle: "If you call a dog's tail a leg, how many legs does a dog have?". The correct answer is: "Four. Calling the tail a leg doesn't make it one." The fact is, alignment *IS* machine dependent, and all the wishing in the world won't change it. To quote Dave Martindale: .......................... You make software which is portable by making it independent of the details of the implementations of a wide variety of machines, not by arguing that a certain class of those machines should not be allowed to exist. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry