eho@clarity.Princeton.EDU (Eric Ho) (09/11/89)
How much work is it to keep the existing design/organisation of gcc as it is now but make it to be able to read/load in architectural info (hence overiding the default values of various macros) as the user chooses to ? If the user doesn't raise the flag then gcc will be the same as before -- i.e. it should impose no performance penalties. I know that reading in this kind of info will slow the compiler down to a certain extent but I thought that it'll be nice if the user can at least have a choice. This feature I guess will of some help to people who are designing/using new machines/architectures or simply adding a new processor to an existing family -- this helps/breeds experimentations -- i.e. everytime you add a new feature to the processor you just need to modify a single file and don't need to rebuild gcc in order to test things out. Oh well, just a thought ... -- 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-
pardo@cs.washington.edu (David Keppel) (09/12/89)
>>>[Ongoing discussion of multi-target gcc] >>[Make it load arch info dynamically] eho@clarity.Princeton.EDU (Eric Ho) writes: >[No flag, same as before. Flag, read in arch info] As it stands, gcc has lots of macros describing the target machine(s). Those macros are expanded when the compiler is built. The code that gets produced is very dependent on the arch. info. The choices seem to be: * Replace the macros with lookups in to runtime data structures. * Compile separate machine-dependent parts for each target. * Compile for the default target and for a generic target. Replacing the macros with dynamic lookups will make a slow compiler. Compiling for each target will produce a fast compiler. It doesn't let you `fiddle' with the target unless you rebuild the compiler. In the case of `gcc', the machine description lives a lot of places in the compiler. This makes a faster compiler, but would make each machine-dependent part large. Compiling for a `hard' target and for a generic target would generally make a maintainence problem. You would be maintaining two versions of lots of peices of code; one for the version that gets compioled to a single target, and one for the version that looks up in the data structures. You could write a machine description for a `generic target'. That target has macros that do lookups in to a data structure rather than compiling to hard constants. Then build two versions of `gcc', one for the hard target and one for runtime binding of the md. Folloups to comp.lang.misc ;-D on ( Retargetable postings ) Pardo -- pardo@cs.washington.edu {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo