Rob, Thank you for the education. I wasn't up on the "anti-tivoization" issue, but after reading up I would have to say that I'm deeply in that camp; if I buy the hardware, I should be able to do what I damn well please with it -- why I haven't purchased an iphone for example. At the same time, I also believe in GPL w/link-time exception if the situation warrants it. But this is a discussion for another time & place. On 06/23/2012 11:39 PM, Rob Landley wrote: > Less optimized but still works with old compilers is fine. (Less > optimized comes with the territory with old compilers.) This was of particular concern to be because of how much less optimized. For example, an inline function that expanded to about 128 bytes on gcc 4.6 expanded to 500-ish bytes on gcc 3.4.6. I guess I should reserve any further comment until I have hard performance numbers. > And who's talking "if"? > > LLVM/CLANG builds a bootabe linux kernel: > http://lwn.net/Articles/441018/ > > Open64 builds a bootable linux kernel: > http://article.gmane.org/gmane.comp.compilers.open64.devel/2498 > > The PCC guys make an adorable token effort which is largely ignored: > http://bsdfund.org/bundle/ > > Heck, Fabrice bellard did it himself with tinycc back in 2004: > http://bellard.org/tcc/tccboot.html Frankly, I'm glad to hear about these endeavors. I'm not a fan of Apple because of their business policies, but I'm a huge fan of run-time optimization being a hard-core Java programmer (and yes, I admit it :). I did check out tccboot at one point out of interest. >> Another question that has to be asked is "Is Linux ready for this?" The >> answer today may be "yes" or "no", but to say that it can never be ready >> is pure folly. > > I'm saying that adding complexity is not necessarily an improvement, and > that over-optimizing at the expense of portability may turn out to be a > mistake in the long run. Any time you want to add complexity, it must be justified. However, I'm operating by the compiler compatibility rules adopted by the Linux kernel project and putting portability (to non-gcc compilers) as a lower concern than the 99% use case. > You keep using the word "paradigm". Voluntarily. I find this odd. I don't tend to back away from a word just because PHBs (Pointy-Haired Bosses) like to abuse them. I'll even use the word "synergistic" when I think it applies. What I'm proposing introduces a few new paradigms, patterns or schools of thought(and I prefer to pronounce it "pair-uh-dig-uh-me", just because I can). For one, I'm asking people to use a macro where you leave parameters empty as a sort of "default" value. This isn't standard and if I'm going to ask somebody(especially lots of people) to do something non-standard I want to make sure I've explored it thoroughly, eliminated all other options and that there's a really good reason for doing so. If I can prove that there's a good reason for doing it, that there are no other reasonable options, that it has a benefit and is reusable, then we're using a new paradigm and we have to start thinking about the interface differently than we're used to thinking about interfaces. Many consider this out-right macro abuse -- that is a valid school of thought. I'm introducing this as an alternate school of thought. But the other paradigm that seems to be new is using constant function pointers for a sort-of "type-injection" for generic inline functions. We usually think about function pointers as overhead. But since gcc's -findirect-inlining feature has matured, it creates the opportunity for a new way of thinking about the use of function pointers (when they are constant) for generic code. I prefer the term "paradigm" when mechanism requires a distinct way of thinking about the mechanism and its components and can be re-used as a pattern. > So yay standard C99 micro stuff. I'm a little worried about being able > to unwrap it all and understand what's going on, but unlike templates > we have cc -E to fall back on here, so ok. I have (or had) a script somewhere around here to parse that huge one-line macro out and give it some reasonable linebreaks & indentation (feeding it gcc -E). Developing complex pre-processor stuff is a super pain, so I just want to make sure that using it is as painless as possible. > Ok, so "designed with gcc 4.6's optimizer in mind, regression tested back to 3.4 for at least minimal functionality, and not intentionally breaking other compilers". > > That's what I wanted to know, and it sounds good to me. Yes. I wouldn't think it appropriate to propose the patch set if it degraded performance with a fairly recent compiler (stable). Although, gcc 4.6.3 still isn't considered "stable" on Gentoo because there's still a few (10-ish) broken packages blocking it. Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
