This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Supporting more than one CPU with the same gas port.


On Thu, 5 Jan 2012, nick clifton wrote:

> Mind you, I suspect that this sort of thing (a computing device with more than
> one type of CPU sharing the memory and other resources) might become more
> prevalent in the future.  If it does, then the binutils will need to adapt to
> be able to handle generating executables for such devices.

I think it does make sense, both for better support of such devices and 
simply as a matter of clean design, for the assembler to have a target 
vector encapsulating all the target dependencies, so that it is possible 
to build in support for multiple targets, and for the global state to be 
limited so that it is then possible to support multiple targets in the 
same assembler run.

The assembler is both much further from this than GCC - everything is done 
with md_* macros with no notion of a target vector, whereas hundreds of 
GCC target macros have been moved to such a vector - and much closer, in 
that there are many fewer macros than in GCC so completing the move to a 
target vector would be a much smaller task.  (Although it's not just md_* 
macros, most of which would be easy to convert to functions in a target 
vector; there are lots of other macros used as well; app.c would be a 
particularly troublesome case for converting such preprocessor 
conditionals to runtime checks, with many conditionals on individual 
targets rather than on features.)

-- 
Joseph S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]