This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: arm-elf-gcc : change default data alignement depending on ARM/THUMB


Yves:


On Thu, Aug 21, 2003 at 10:57:31AM -0500, Bill Gatliff wrote:


I don't see why Linus (or anyone else, for that matter) would have a problem understanding how "volatile" works.



I have a vague feeling that there used to be border cases for which gcc happened to produced bad code.


Perhaps, although I'm struggling to find any examples lately!


Either way, a quick search brought me to this post which explains it quite
clearly (I think):

http://www.geocrawler.com/archives/3/597/2001/7/0/6253709/


Essentially, his appraoach allows to control where writing
back to memory is relevant and where it isn't, while
volatile forces it all the time.


Right, that's my read of his email too. Which is another beef of mine with his code (ot): he refuses to ever let the compiler do the work for him. Yes, he gets a modest performance improvement by taking on volatility and several similar burdens (macros vs. inlines, typedefs, enumerations, etc.) himself, in exchange for a monumental maintenance headache. Of course, he has a monumental staff...


But that's still no excuse. If they weren't tracking down petty issues like barriers, endianness, etc., imagine what the core Linux developers could be working on! Speaking hypothetically, of course: I have no idea what the daily life of a Linux kernel developer is like. I just take what they give me and port it over, warts and all.

Oh, and Linus's approach ties you inextricably to gcc. Mine works for any ANSI-compliant compiler.



Yes. Linux is really only target at GCC. Oh, and this is the x-gcc mailing list! :)


But had he started out with MSFT or Intel's tools instead, and used whatever facilities those tools provided him to implement his barriers, he'd be stuck there. I avoid suggesting non-ANSI solutions to problems like this for a number of reasons, not the least of which is that it makes it easier to convert someone over to gcc down the road. :^)



b.g.


--
Bill Gatliff
In the dark on embedded GNU?  Step into the light.
bgat@billgatliff.com



------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]