At Thu, 12 Feb 2009 16:03:44 -0500, Jim Wise wrote: > > der Mouse <mouse%Rodents-Montreal.ORG@localhost> writes: > > >> The biggest problem with doing global optimization is structural: in > >> Unix the compiler is expected to behave a certain way with respect to > >> object files, and object files have a fixed format and well known > >> semantics. > > > > Not all that much so. For example, if you were to turn .o files into a > > serialization of gcc's internal "tree" structure (I'm handwaving > > tremendously here, I know), the disruption for almost all uses of .o > > files would probably be no greater than the disruption caused by > > switching from a.out to ELF. > > There _is_ prior art -- the Amsterdam Compiler Kit, more commonly known > as `that weird compiler in Minix' commonly used raw assembly as an > object format, at least in libraries, and had compiler options to output > (and input for later use) various stages of intermediate languages from > the optimizer passes. > > With a little make(1)-fu, you could use these intermediate forms in > place of object files throughout. > > More formally, this approach was also used in ANDF -- and is what's > really happening when executing java code under a JIT compiler. > > -- > Jim Wise > jwise%draga.com@localhost I have not used this, but maybe this could serve as a starting point for someone... http://www.cs.utah.edu/flux/alchemy/cmi.html Best regards, Marko
Attachment:
pgpARejGQ9E5U.pgp
Description: PGP signature