From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Harvey To: mark@codesourcery.com, torvalds@transmeta.com Cc: chip@perlsupport.com, craig@jcb-sc.com, davem@redhat.com, egcs@egcs.cygnus.com, rth@cygnus.com, tim@wagner.Princeton.EDU Subject: Re: Linux and aliasing? Date: Wed, 30 Jun 1999 15:43:00 -0000 Message-ID: <199906062207.PAA24899@elbe.ghs.com> X-SW-Source: 1999-06n/msg00232.html Message-ID: <19990630154300.4zOajrP-IrNiNv9xhHj21KWZoXVZBIt8zOExcSuWFzI@z> > From: Linus Torvalds > > On Sun, 6 Jun 1999 mark@codesourcery.com wrote: > > > > Right. But the part that's causing aliasing issues is just a memcpy; > > that's the `*(u32 *) p' bit. You could write: > > > > memcpy (&a, p, sizeof (a)); > > a = ntohl (a); > > Which is crap. > > And a compiler that requires you to write code like that is, by > implication.. >::: > If you can't see why > > a = ntohl((u32 *) p); > > is better than the horrible thing you're suggesting (regardless of whether > the code generated is the same or not), then I might as well throw in the > towel immediately. The whole point of my suggestion was to make good code > generation possible with an interface that you can actually use without > barfing.. > > Linus Umm, the ice is getting thin, here. From time to time, I have to change kernel code FROM things like ``a = ntohl((u32 *) p);'' TO things like ``memcpy (&a, p, sizeof a); a = ntohl (a);''. Why? Because it's illegal for a reason, and the alpha platform I support has alignment requirements for which I have a guarantee that the memcpy approach will work and be reasonably efficient. The cast can generate a kernel alignment fault and will either panic or have a hideous run-time fixup cost. I know we are talking about aliasing, but in terms of why the rules are there, I think this is an illuminating example. LP64 is coming to the PeeCee world, and even if the fixup is in hardware, you still have a runtime penalty for making addressibility assumptions that are properly the domain of the compiler. Ross.Harvey@Computer.Org