eho@clarity.Princeton.EDU (Eric Ho) (09/10/89)
I was just thinking that since gcc is a retargetable optimizing compiler, wouldn't it be nice to put all kinds of architectural info outside the compiler -- i.e. in a seperate file or data/rule base of some sort and gcc reads this file according to what architecture the user is compiling his/her program on. This way, you save a lot of time by avoiding to rebuild gcc everytime you've need recompile your code for different architectures. For instance, if I want to remake my application for a new architecture then all I need to do is supply that architectural info/database to gcc and it'll generate the correct binary for that new architecture (without recompiling gcc at all) and I can do all this on my Sun-4 or do it on the new machine. What do others think ? It shouldn't be too difficult to reorgainize gcc this way, right ? -- Eric Ho Cognitive Science Lab., Princeton University voice = 609-258-2987 email = eho@confidence.princeton.edu 609-258-2819 (messages) eho@bogey.princeton.edu regards. -eric-
ham@Neon.Stanford.EDU (Peter R. Ham) (09/11/89)
Persoally, I like the generality of your approach. Unfortunately, compilations would probably run much slower using such an architectual database. Speed, is one of the primary advantages of using macros that way gcc does. Turning all of those machine dependent macros into items in a database seems like a huge chore to me. I wouldn't recommend this trying to implement this change to anyone, although I agree the results would be "clean", but probably much slower. If you are going to rewrite gcc from scatch and are not concerned about compilation speed, the go for it. The use of macros is a major design decision in gcc. (At least it looks like it from reading the code). Maybe further discussiong of gcc's design should go ong gnu.gcc.bug. -- Peter Ham PO Box 3430 (h)(415) 324-9645 MS Computer Science Student Stanford, CA ham@polya.stanford.edu Stanford University 94309 (o)(415) 723-2067
eho@clarity.Princeton.EDU (Eric Ho) (09/11/89)
> In article <HAM.89Sep10115811@Neon.Stanford.EDU> ham@Neon.Stanford.EDU (Peter > R. Ham) writes: > > Persoally, I like the generality of your approach. > Unfortunately, compilations would probably run much slower > using such an architectual database. Speed, is one of > the primary advantages of using macros that way gcc does. > Turning all of those machine dependent macros into > items in a database seems like a huge chore to me. Hm... so there is no easy way to read in those macros dynamically huh ? How about keeping everything as what it is now (I don't fancy doing major changes to gcc -- I can spend my time on better things than rewriting gcc) but say to extend it to be able to read in those macros dynamically on user's demand ? -- Eric Ho Cognitive Science Lab., Princeton University voice = 609-258-2987 email = eho@confidence.princeton.edu 609-258-2819 (messages) eho@bogey.princeton.edu regards. -eric-