--- On Mon, 5/30/11, Richard Guenther <richard.guent...@gmail.com> wrote:
> On Mon, May 30, 2011 at 1:14 PM, > Robert Beeporbop <rbeepor...@yahoo.com> > wrote: > > Thank you for the information! > > > > So it sounds like right now, I could use 4.6.0 > (4.7.0?), and be architecture-independent between processors > of the same type. Like, code could be compiled to GIMPLE > with no optimization for generic x86, then optimized and > linked differently depending on the target processor, say > for a 80386 and a core2, as long as the memory layout is the > same. Would this work? This is still really good! > > To some extent yes. When programs check feature > availability based > on preprocessor macros like __SSE2__ it of course can't > (those are > evaluated early). Good point. > > > I have read what has been written about GIMPLE, on the > website, I have not yet read the code. Is there any other > documentation which would be useful to read? > > I don't think the information is useful for your case. > Well I may want to start hacking code! It sounds like a large amount of work would need to be done to make this architecture- independent, I'm probably not up for that. The idea is appealing, though. > > How hard would it be to make GIMPLE fully > architecture-independent? Could placement of items in memory > be handled by the linker, and everything before linking be > symbolically referenced? Sorry this is a pretty general > question, and I haven't looked at the code, is this within > the realm of possibility? Other than sizes of types and > memory layout, what is architecture-dependent in GIMPLE? > > It's impossible, already the language frontends expose some > ABI details. > > > Pretty stable is good enough, if gcc could be upgraded > through a minor version or two, or bugfix patched, without > the need to recompile everything, that would be great! On a > major release of the distribution, everything would be > recompiled anyways, so it doesn't matter if the GIMPLE > format changes. > > I would expect that we try to remain compatible on a > release branch. > But given the lack of any automated way to detect if we > break something > there the guarantee is pretty low. > > Richard. >
