aburt@cisden.UUCP (Andrew Burt) (03/14/85)
I don't recall seeing this hashed out in here so I thought I'd see what
the general reaction is.
Recently I've had to work around a machine dependency (on several machines)
that it strikes me C should allow me to avoid. After all, C is
supposed to be portable and "low" level at the same time, right? The
problem is in structure padding. I fully realize why when I say:
struct foo {
int i;
};
struct bar {
char c;
struct foo f;
};
I may get an internal representation with c having offset 0 from the
beginning of bar and f.i having offset, say, 2 (or 4 or ...) with a byte
in between them not being used. I also understand the same thing
happening if struct foo is:
struct foo {
char c;
};
However, it would be useful (I didn't say efficient, mind you) if
I could say something like
struct bar {
char c;
unaligned struct foo f;
};
with the effect that f.c would have an offset of 1 from the beginning
of struct bar; or f.i -- yes, an int at an odd address. I mean this
regardless of how it's implemented. E.g. if I did
struct bar b;
b.f.i = 7;
I would expect code to be generated analogous to
int tmp = 7;
bcopy(&tmp, &b.f.i, sizeof int);
Clearly this is not what I want for a default, since most code really
doesn't care about padding in the middle of structures (or so I would
imagine). But this would be wonderful for porting code and especially
data files to other architectures. Not to mention dealing with
non-unix machines: I'm working on a large piece of comm software that
has to speak to a large variety of machines on a lan, all of which get
very upset when I
write(fd, &b, sizeof(struct bar));
and they get nifty-keen nulls in the middle of it all. If perhaps I could
choose how to organize my structures such that I had, say, two characters
followed by that int (or whatever I need so that I don't get any padding)
I wouldn't mind so much. But the case here is that I have to talk the
language of the remote system, not vice versa -- and it says "char followed
by int" (for example). Since I have no choice, I am writing out a string,
doing the bcopy's into it with #defined offsets. Not pretty.
(The variable length fields I get back are another can of worms entirely,
but I wouldn't even think of suggesting that C should generate code knowing
which bytes imply what structure sizes to use. After all, I need something
to do to earn my paycheck :-)
If we wanted to get carried away, we could ask for structure assignments
between aligned and non-aligned structures with the same elements (the
difference being the latter has padding). Maybe something like this...
struct bar b;
unaligned struct bar ub;
ub = (unaligned) b;
Imagine how easy it would be to port a data file.
In terms of practicality, I wouldn't want this put into C or the ANSI standard.
I was thinking more along the lines of C++, or if it's too late for that,
C+=2. Certainly the language has to grow or it will stagnate.
--
Andrew Burt
Contel Information Systems
{ucbvax!nbires, seismo!hao!nbires, boulder}!cisden!aburt MLY.G.SHADES%MIT-OZ@MIT-MC.ARPA (03/15/85)
the reason for the padding, which admittedly does not hold for
some machines, is that many machines, notably the pdp-11, can not
handle words generated at an odd address. if the compiler was allowed
to generate incorrectly aligned data then the compiler would rapidly
acquire, and rightfully so, a reputation for uselessness; the code
produced would generate odd instruction traps at the most inconvenient
locations.
another interesting effect is with machines that don't have
proper byte addressing but simulate it instead; pdp-10, and honeywell
600/6000/dps 8 line use an incrementing byte pointer into a word; the
honewell level 6/dps 6 uses indexed byte instructions to generate
offset and left/rightness; the raytheon rds 500/704 uses separate
left/right instructions, except as i remember when the argument is
indexed. this list is not by any means definitive or even reasonably
exhaustive. it does however show why in a language that is to be as
portable as possible (c) you would not want and should not include
machine breaking structures.
sorry but that's life down here in river city.
shades%mit-oz%mit-mc.arpa@seismo (? looks right ?)ron@brl-tgr.ARPA (Ron Natalie <ron>) (03/15/85)
> > the reason for the padding, which admittedly does not hold for > some machines, is that many machines, notably the pdp-11, can not > handle words generated at an odd address. if the compiler was allowed > to generate incorrectly aligned data then the compiler would rapidly > acquire, and rightfully so, a reputation for uselessness; the code > produced would generate odd instruction traps at the most inconvenient > locations. > Understandable, but with loss of effieciency you ought to be able to at least assign in and out of "unaligned" data. I know that taking the address of something that is aligned incompatibly with the machine (like odd ints on pdp-11s) and thn passing it as a pointer is going to cause problems. What really galls me is that the VAX, which has virtually no alignment restrictions, insists on padding out structures where the exact same declaration on the PDP-11 doesn't. -Ron
tim@cmu-cs-k.ARPA (Tim Maroney) (03/16/85)
It is not accurate to say that the VAX has no alignment restrictions. While a VAX can handle unaligned data, the performance penalty for doing so is significant. Aligned data is almost always what you want. Nevertheless, it wouldn't have killed the PCC-porters to include a command-line compiler option to turn off alignment for those rare cases when external unaligned data formats have to be matched.... -=- Tim Maroney, Carnegie-Mellon University, Networking ARPA: Tim.Maroney@CMU-CS-K uucp: seismo!cmu-cs-k!tim CompuServe: 74176,1360 audio: shout "Hey, Tim!"
ron@brl-tgr.ARPA (Ron Natalie <ron>) (03/17/85)
> It is not accurate to say that the VAX has no alignment restrictions. While > a VAX can handle unaligned data, the performance penalty for doing so is > significant. Aligned data is almost always what you want. > > Nevertheless, it wouldn't have killed the PCC-porters to include a > command-line compiler option to turn off alignment for those rare cases when > external unaligned data formats have to be matched.... I'd hardly say significant. There are two peformance penalties to pay for not having things longword aligned. The first is that there is a 64 bit path in to memory. Accesses that straddle the boundry, require two fetches. However, if a structure contains elements such that it unevenly spans a longword boundry, it is unclear that padding the structure out to the doubleword is going to do any good whatsoever. The second problem is that the compiler might make use of some tricks that require longword alignment, but it doesn't. Explicitly setting the pointers to point to non standard alignments works just fine (this is how you get around the moronic struct structure). -Ron
jc@mit-athena.UUCP (John Chambers) (03/18/85)
Once again we hahear a justification of C's alignment on the grounds that some machines can't load and store unaligned quantities. THIS IS NOT TRUE! Every machine I've ever used, and I suspect all that have ever been built, can do this quite easily. The method is simple. For unaligned loads, you write code that loads the containing words into two registers, use AND instructions to zero out the unwanted portions, SHIFT instructions to align the wanted bits properly, and an OR instruction to combine them. Every machine I've ever seen has LOAD, AND, SHIFT and OR instructions. But, but, but... This is inefficient, I hear people muttering. Well, sure it is, but it's not any more efficient when I have to code it myself because the @#$#%@# compiler refuses to do it for me. If the data is unaligned (as often happens when you are getting it from another machine), someone has to write the inefficient code to extract the data. It is either me or the compiler. This is not a difficult job for a compiler to do. I know, I've written several. Compilers were invented back in the 50's to save people time by making the machine do the drudge work in generating machine language. Handling misaligned data is an especially dreary piece of drudge work that is both hard for me and easy for the machine. Why can't compilers do their job (making life easy for programmers) right, rather than making feeble excuses that don't stand up to the slightest investigation? I'm getting sort of tired of writing the same pieces of stereotyped code over and over and over and over and over, when I know very well how easy it would be for the compiler to do it for me. (Well, sure, I could dig in and modify the compiler. I did this once. Then I moved to another machine, and its C compiler needed the change, too, and...) Grumble, grumble, grumble.... -- John Chambers [...!decvax!mit-athena] If you're not part of the solution, then you're part of the precipitate.
rick@sesame.UUCP (Rick Richardson) (03/18/85)
> the reason for the padding, which admittedly does not hold for > some machines, is that many machines, notably the pdp-11, can not > handle words generated at an odd address. The original author (sorry I don't have rn, and lost his name) wanted unaligned structures for what looks like a very legitimate and portable reason. He's trying to package up a block of data which is to be sent over a serial line. Probably some protocol. He would love to give symbolic names to the pieces of data instead of trying to pack the stuff by hand into a character array (using >>8 and &0xff, etc.). His ultimate goal is to issue a "write(fd, &block, sizeof(block));". This feature wouldn't cause any problem with word alignment, if used in this manner. The problem is that even if the padding is eliminated with some language construct, he is still going to have machine dependencies in two areas: an assumption that "short" or "int" is a specific length (probably 16 or 32 bits), and that the byte ordering of such things is the same on his machine as specified by the protocol and also of all machines to which he may port. This is not the case, and the only portable way to do this is by shifting and masking the stuff into a character array. The net is that he is specifically asking for a language feature that will lull him into a sense of portability that isn't really present. -- Rick Richardson, PC Research, Inc. {genrad|ihnp4|ima}!wjh12!talcott!sesame!{rick|pcrat!rick} {cbosgd|harvard}!talcott!sesame!{rick|pcrat!rick} rick%sesame@harvard.ARPA
mauney@ncsu.UUCP (Jon Mauney) (03/20/85)
When asking for unaligned structures in C, don't forget to ask that they be unaligned at the BIT level, because you might want to read tapes containing 36 or 60 bit words. Also make sure that the compiler supports viewing numbers as having their bytes interchanged, because you might want to go from the VAX to something sane, occasionally. And we want the compiler to convert between ones- and twos-complement, and among the various representations of floating point, both binary and BCD. Why should I have to write a different conversion routine for every pair of machines, when they could all be added to the compiler for me? Of course, the stodgy old standards commitee will never get sufficiently enlightened to add these features to the language. So we'll have to go with the next-best thing: a library of good, generic data-conversion routines. Fortunately, C provides lots of support for writing generic procedures. -- _Doctor_ Jon Mauney, mcnc!ncsu!mauney \__Mu__/ North Carolina State University [ Huh? Put in a :-)? What does that mean?]
thoth@tellab2.UUCP (Marcus Hall) (03/21/85)
In article <120@mit-athena.UUCP> jc@mit-athena.UUCP (John Chambers) writes: >If the data is unaligned (...) someone has to write the inefficient code to >extract the data. It is either me or the compiler. This is not a difficult >job for a compiler to do. I know, I've written several. > >Handling >misaligned data is an especially dreary piece of drudge work that is both >hard for me and easy for the machine. > OK, how does the compiler know at compile time whether a pointer will be pointing to an aligned structure or not? It would have to assume that is never is aligned, which would produce needlessly innefficient code 95% of the time. Consider x(p) int *p; { return (*p); } On the Z8000 which cannot do un-aligned word addressing, the following code would be produced: Alignment assumed: Alignment of stack No alignment assumed: only assumed: ld r5,2(sp) ld r5,2(sp) ldb rh5,2(sp) ld r4,@r5 ldb rh4,@r5 ldb rl5,3(sp) ret ldb rl4,1(r5) ldb rh4,@r5 ret ldb rl4,1(r5) ret Now, it isn't all that terrible to assume alignment, is it? Actually, as has already been stated, the biggest problem to portability is byte ordering, so if you have to worry about alignment problems you must also worry about byte ordering, so you've got to put the bytes together yourself anyhow. Of course, you could load the int into a register, then asm() in a swab instruction :-). marcus hall ..!ihnp4!tellab1!tellab2!thoth
ndiamond@watdaisy.UUCP (Norman Diamond) (03/22/85)
> When asking for unaligned structures in C, don't forget to ask that > they be unaligned at the BIT level, because you might want to read > tapes containing 36 or 60 bit words. A 36-bit or 60-bit machine already has to make adjustments, regardless of programming language or compiler or options. 9-track tapes, with 1 parity bit, have 8-bit bytes written on them. Similarly, networks are generally specified to have 7-bit or 8-bit data, or 7-bit padded with a zero bit or with parity. The machine already must do some conversion. Why make it so much harder for a C programmer to complete the conversion? > Also make sure that the compiler > supports viewing numbers as having their bytes interchanged, because you > might want to go from the VAX to something sane, occasionally. If a machine's ports reverse the bytes from the protocol specified by the network, then that machine's programs must make adjustments. Again, why should C make it harder? Or if it's on tape, it is already known that data other than character strings cannot really be regarded as portable. > So we'll have to go > with the next-best thing: a library of good, generic data-conversion routines. > Fortunately, C provides lots of support for writing generic procedures. But to overcome the padding, they will have to be in assembly or will have to convert bytes (out of a char array) into ints. For that matter, even the char array doesn't work well on some machines; it may have to be assembly. Yes I understand the earlier suggestion about a smiley face -- though the submission wasn't just a joke, it was rhetoric with a certain message intended. I replied to the message. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
jeff@rtech.ARPA (Jeff Lichtman) (03/22/85)
> > What really galls me is that the VAX, which has virtually no alignment > restrictions, insists on padding out structures where the exact same > declaration on the PDP-11 doesn't. > > -Ron This isn't true on VMS. When we converted our software from Whitesmith's to DEC C, we found that the former aligns structures and the latter doesn't. This caused us problems because we store structures in files, so we had to add our own padding. Sometimes it is a good idea to align structures on machines that don't require it because it makes the code run faster. Reading or writing an aligned word takes only one memory cycle, as opposed to two for an unaligned word. I agree that the compiler shouldn't pad for you, because this takes away the choice. -- Jeff Lichtman at rtech (Relational Technology, Inc.) aka Swazoo Koolak
sde@Mitre-Bedford (03/22/85)
How about adding keyword(s) 'aligned/unaligned' to deal with the pointer alignment question? Of course, it would help to be able to specify a general (un)alignment default. (.5) :-) David sde@mitre-bedford
chris@umcp-cs.UUCP (Chris Torek) (03/23/85)
Actually, if there is a "good" solution to this, it may not be to add a
modifier keyword, but instead to define a new object which is similar
to a structure, but "compressed" (with access time penalties on some
machines).
This eliminates confusion (or so I claim). Consider the following:
unaligned struct foo {
short f_this;
char f_that[2];
};
f (foop) unaligned struct foo *foop; {
...
Is foop a pointer to an unaligned struct foo, or is it an unaligned
pointer to struct foo? (The proposed "const" modifier has this
problem, by the way.)
dollop foo {
short f_this;
char f_that[2];
};
f (foop) dollop foo *foop; {
...
Clearly, here "foop" is a pointer to a "dollop" of bytes.
Unfortunately, this doesn't address arrays. However, I have only ever
wanted unalignment once, and that in a structure. (Look at the XNS
protocol headers; it requires a 4 byte object that is aligned only on a
2 byte boundary.) So to generalize from one example (always a
dangerous game!), structure alignment seems more important.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandatbowler@watmath.UUCP (Alan T. Bowler [SDG]) (03/25/85)
In article <248@rtech.ARPA> jeff@rtech.ARPA (Jeff Lichtman) writes: > I agree that the compiler shouldn't pad for you, >because this takes away the choice. Actually I really want the compiler to pad for me, the optimal alignment varies from machine to machine, and I expect the compiler to handle this detail for me by chosing the alignment that suits the machine. Doubles on some machines need 8 byte alignment, on others 2 byte. The only way to be sure that a program will port with reasonable effieciency is to assume that the compiler will know such things and chose the correct alignments. If the compiler is to be forbidden the freedom to chose the natural alignments that will dramatically increased the amount of work I have to do to port a program.
jdb@mordor.UUCP (John Bruner) (03/25/85)
One of the objections that has been raised against unaligned structures in C is that you can run into trouble if you create a pointer to an unaligned element and pass that pointer to a function. If the machine can't access unaligned data (e.g. an odd address on a PDP-11) the program will die when it tries to reference through the pointer. Worse, if the structure items are not aligned on byte boundaries such a pointer might not even make sense. The solution to this problem is to disallow the unary '&' operator from operating upon elements of a packed/unaligned structure. This is the solution in Pascal, which does not permit a component of a packed record to be passed by reference (as a "var" parameter). There is at least a weak precedent for this in C with the "register" storage class. I'm involved with software development for a machine with a (gack) 36-bit word, and C's inability to define bitfields which cross longword boundaries (and the VAX PCC's inability to deal with integers wider than 32 bits) makes life miserable. By contrast, our other system development language, Pastel (a "colorful" Pascal), makes things much less painful. All our object files must be created with 9 8-bit bytes containing the data for 8 9-bit bytes. In Pastel the conversion is all done by the compiler. In C I had to write routines which explicitly mask and shift to get the desired effect. The problem is much worse if you consider that assemblers, linkers, etc. often want to look at one group of bits at a time (e.g. the opcode field is the upper 12 bits). In Pastel I can declare a packed array of packed records (each record is a 36-bit word), index into the array, and extract the desired element. In C I have to read a block of bytes, convert them into some internal format (e.g. 12 bits per 16-bit "short") and then mask and shift some more if the field I want crosses a 12-bit boundary. No feature is free, of course, and bit-aligned structure elements do increase the complexity of the compiler. However, if they aren't used they do not increase the size or runtime of the resulting program. (Although the Pastel compiler takes more time and space at compile time than PCC, the resulting programs are usually faster and smaller. PCC wins only when the program is very pointer-intensive.) I suppose that I could do what I want using C++, but although LLNL is operated by the University of California we aren't really an educational institution. Hence, I can't get it. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
henry@utzoo.UUCP (Henry Spencer) (03/26/85)
> ... unaligned struct foo *foop; { > > Is foop a pointer to an unaligned struct foo, or is it an unaligned > pointer to struct foo? (The proposed "const" modifier has this > problem, by the way.) No it doesn't, and the problem could be solved for "unaligned" in the same way. Here's how it works for const: const char *pcc; /* ptr to const char */ char *const cpc; /* const ptr to char */ It is agreed that the syntax is a bit ugly, but then C declaration syntax has never been beautiful. (None of this is to be taken to constitute an endorsement of "unaligned". I tend to side with the people who think its contribution to portability would be marginal, perhaps even negative [it deludes people into thinking that their stuff is portable, when it's not].) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
jeff@alberta.UUCP (Curt J. Sampson) (03/28/85)
In article <9434@brl-tgr.ARPA> sde@Mitre-Bedford writes: >How about adding keyword(s) 'aligned/unaligned' to deal with the pointer >alignment question? Of course, it would help to be able to specify a >general (un)alignment default. Ugh! The last thing we need is a couple more keywords. How about adding it as a compiler option. The '-f' option would tell the compiler to optimize code for fast running (ie, do alignment of structures so you can access their elements fast), otherwise make the code small (don't pad structures to save space). Adding two new keywords seems rather unnecessary. -- Curt Sampson ihnp4!alberta!jeff "There is a theory which states that if every anyone discovers exactly what the Usenet is for and why it is here, it will instantly disappear and be replaced by somehing even more bizarre and inexplicable. "There is another theory which states that this has already happened."
jc@mit-athena.UUCP (John Chambers) (03/29/85)
> In article <120@mit-athena.UUCP> jc@mit-athena.UUCP (John Chambers) writes: > >If the data is unaligned (...) someone has to write the inefficient code to > >extract the data. It is either me or the compiler. This is not a difficult > >job for a compiler to do.... Handling > >misaligned data is an especially dreary piece of drudge work that is both > >hard for me and easy for the machine. > > OK, how does the compiler know at compile time whether a pointer will be > pointing to an aligned structure or not? It would have to assume that is > never is aligned, which would produce needlessly innefficient code 95% of > the time. Good point, but not really relevant. You see, current C compilers have this problem right now. Try an experiment like: #include <stdio.h> int a[4] = {1,2,3,4}; int i, *p; main() { for (i=0; i<9; i++) { /* First 9 "integers" */ p = (int*)((int)a + i); /* Subvert C's casts */ printf("%04x: %4x=%d\n",p,*p,*p); } return 0; } On our VAX (4.2BSD), the result is: 1030: 1=1 1031: 2000000=33554432 1032: 20000=131072 1033: 200=512 1034: 2=2 1035: 3000000=50331648 1036: 30000=196608 1037: 300=768 1038: 3=3 Even on machines that "can't do" unaligned integers, this program will probably run without "error" and will give some garbage for output. The point is that C programs can stuff any value whatsoever into pointers. After all, what's to stop them? Unless you violate hardware bounds, you will usually get something. At worst, the low-order bits will be ignored, and you'll get one of the "adjacent" aligned words. So the argument that not doing alignment would require that the compiler handle funny pointers is a red herring. It could do what current compilers do--assume that all pointers are valid and generate code to blindly do the operations. Anyhow, you changed the subject. It wasn't about valid/invalid pointers. It was about alignment of fields within structures. Personally, I'd vote for adding Pascal's "packed" attribute to C structures. Much as I don't love Pascal, I gotta admit that this time they did something right. Let's face it, there are reasons for wanting things aligned, and reasons for wanting them unaligned. It's yet another space/time tradeoff. Packed structures waste cpu time to save memory; aligned structures waste memory to save cpu time. Both are desirable. It's unfortunate that the guys at Bell didn't get around to adding this goodie to C before the language became entrenched. My arguments against automatic alignment come from the fact that I have been burned by it over and over, while I am not aware of any case where it has helped me. (But then, you notice the bad times more than the good.) After all, what does it gain a man to save a millisecond of his computer's time if he loses an hour of his own time thereby? -- John Chambers [...!decvax!mit-athena] If you're not part of the solution, then you're part of the precipitate.
brooks@lll-crg.ARPA (Eugene D. Brooks III) (03/30/85)
> const char *pcc; /* ptr to const char */ > char *const cpc; /* const ptr to char */ Just when I thould I could successfully declare a pointer to a pointer to a fuction which returns a pointer to an int you toss in another curve ball. Fun, fun, fun!
gwyn@Brl-Vld.ARPA (VLD/VMB) (04/01/85)
Don't worry about it; you needn't use "const" if it confuses you. It's there for improved code generation and checking.
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/01/85)
I find the argument for having packet structures to save memory reasonable. This is a genuine concern in many codes. An example of this would be a simulation code for a packet switching system where the packets have many fields of different types. When I write such codes I find myself carefully ordering the structure declarations to minimize the effects of padding. Would lifting the restriction on the addressing order of structure elements fill this need without any changes to the sematics of C? Suppose the compiler were free to reorder the elements of a structure in order to minimize padding. Would it break any code? Are there programs (other than I/O portability) that depend on structure elements being ordered in memory with the same order as the delcarations?
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/01/85)
> times more than the good.) After all, what does it gain a man > to save a millisecond of his computer's time if he loses an hour > of his own time thereby? Ancient Chinese Proverb: One man's millisecond is another man's cpu hour! 1/2 * :-)
sde@Mitre-Bedford (04/01/85)
|>How about adding keyword(s) 'aligned/unaligned' to deal with the pointer |>alignment question? Of course, it would help to be able to specify a |>general (un)alignment default. | |Ugh! The last thing we need is a couple more keywords. How about adding |it as a compiler option. The '-f' option would tell the compiler to |optimize code for fast running (ie, do alignment of structures so you can |access their elements fast), otherwise make the code small (don't pad |structures to save space). Adding two new keywords seems rather |unnecessary. |-- | Curt Sampson ihnp4!alberta!jeff And how would the compiler option know which structures &/or sub-structures are to be aligned and which are to be packed? (But if the comment was only on the question of "...default", then "... TWO new keyowrds " is not correct. Also, it would be nice to be able to treat such a default as similar to conditional compilation, so that for debugging purposes, a section's default could be changed to determine if a problem lay therein. This certainly could not be done by compiler options ( even though, to grant you a point, you could do somthing like 'cc -.. <structname>," or whatever, assuming arbitrarily long command length). David Eisenberg sde@mitre-bedford
henry@utzoo.UUCP (Henry Spencer) (04/02/85)
> Even on machines that "can't do" unaligned integers, this program > will probably run without "error" and will give some garbage for > output. The point is that C programs can stuff any value whatsoever > into pointers. After all, what's to stop them? Unless you violate > hardware bounds, you will usually get something. At worst, the > low-order bits will be ignored, and you'll get one of the "adjacent" > aligned words. Wrong. On most machines that don't support unaligned integers, you will get a signal and a core dump. > ...After all, what does it gain a man > to save a millisecond of his computer's time if he loses an hour > of his own time thereby? Sometimes it saves his successor from spending many hours figuring out how to get that millisecond out. Yes, Virginia, some programs do have to run fast, and few are the worse for a speed improvement. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
ndiamond@watdaisy.UUCP (Norman Diamond) (04/03/85)
> > Even on machines that "can't do" unaligned integers, this program > > will probably run without "error" and will give some garbage for > > output. > Wrong. On most machines that don't support unaligned integers, you > will get a signal and a core dump. I don't know which "most" is correct, but have used examples of both kinds of machines. The former are enough of a pain to be cause for a lot of care. (For that matter, so are the latter.) > > ...After all, what does it gain a man > > to save a millisecond of his computer's time if he loses an hour > > of his own time thereby? > Sometimes it saves his successor from spending many hours figuring out > how to get that millisecond out. Yes, Virginia, some programs do have > to run fast, and few are the worse for a speed improvement. If you have to remove one millisecond from a tight loop that has to run in 50 milliseconds, you really should use assembly. -- Norman Diamond UUCP: {decvax|utzoo|ihnp4|allegra}!watmath!watdaisy!ndiamond CSNET: ndiamond%watdaisy@waterloo.csnet ARPA: ndiamond%watdaisy%waterloo.csnet@csnet-relay.arpa "Opinions are those of the keyboard, and do not reflect on me or higher-ups."
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/05/85)
> If you have to remove one millisecond from a tight loop that has to run > in 50 milliseconds, you really should use assembly. If you can possibly do it in assembly then an optimizing compiler that generates good code can do it just as fast and you gain portability. Surely you don't reccomend assembly. Was this posted on April 1 with the vectorizing C compiler news item?
karsh@geowhiz.UUCP (Bruce Karsh) (04/06/85)
>> If you have to remove one millisecond from a tight loop that has to run >> in 50 milliseconds, you really should use assembly. > > If you can possibly do it in assembly then an optimizing compiler that > generates good code can do it just as fast and you gain portability. Can somebody *PROVE* this. I don't think it's true. I think a better statement would be that an optimizing compiler *might* be able to generate code that is as fast. (And then again it might not be able to.) -- Bruce Karsh | U. Wisc. Dept. Geology and Geophysics | 1215 W Dayton, Madison, WI 53706 | This space for rent. (608) 262-1697 | {ihnp4,seismo}!uwvax!geowhiz!karsh |
brownc@utah-cs.UUCP (Eric C. Brown) (04/06/85)
In article <173@geowhiz.UUCP> karsh@geowhiz.UUCP (Bruce Karsh) writes: >>> If you have to remove one millisecond from a tight loop that has to run >>> in 50 milliseconds, you really should use assembly. >> >> If you can possibly do it in assembly then an optimizing compiler that >> generates good code can do it just as fast and you gain portability. > > Can somebody *PROVE* this. I don't think it's true. I think a better >statement would be that an optimizing compiler *might* be able to generate >code that is as fast. (And then again it might not be able to.) > Well, you may not be able to write it in C, but BLISS routinely generates code that is much better than the code that most programmers generate. Try reading "The Design of an Optimizing Compiler", by William Wulf et al. Eric C. Brown brownc@utah-cs ...!seismo!utah-cs!brownc Execute People, not Programs!!
brooks@lll-crg.ARPA (Eugene D. Brooks III) (04/07/85)
> >> If you have to remove one millisecond from a tight loop that has to run > >> in 50 milliseconds, you really should use assembly. > > > > If you can possibly do it in assembly then an optimizing compiler that > > generates good code can do it just as fast and you gain portability. > > Can somebody *PROVE* this. I don't think it's true. I think a better > statement would be that an optimizing compiler *might* be able to generate > code that is as fast. (And then again it might not be able to.) The proof goes as follows. If the compiler did not generate optimal code then the compiler was not an optimizing compiler of high enough quality. Get a better compiler. QED, and 1/2 :-)
zben@umd5.UUCP (04/08/85)
> In article <120@mit-athena.UUCP> jc@mit-athena.UUCP (John Chambers) writes: > ...After all, what does it gain a man >to save a millisecond of his computer's time if he loses an hour >of his own time thereby? First off, lets make the sort of rash assumption that the machine time and the human time cost the same. Machine time has traditionally been much more expensive than human time (I sure as h*ll don't get $300 an hour) but recent history has machine costs dropping like crazy and it simplifies the analysis. Now, the question you have to ask is: "Will this code be executed more than 60 * 60 * 1000 times over the lifetime of this program?". If it will, then it is surely worth your hour of time to tighten it up. If it will not, then why bother... I see the point as being: "why cruftify the source program to do structure access manually (to program around alignment issues) when you could have the compiler do it automatically, error free :-), and leave the source code in a state that a mere mortal can read, understand, and modify..." -- Ben Cranston ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben zben@umd2.ARPA