Re: new port for Xtensa processors (bfd files)

[Bob Wilson <bwilson at tensilica dot com>]

On Tuesday 01 April 2003 07:53, Nick Clifton wrote:
> The only problem that I see is that a couple of the files are
> generated by some kind of tool (include/xtensa-config.h
> bfd/xtensa-modules.c), and the sources for this tool were not
> contributed as well.  Are Tensilica planning to contribute this tool
> at some point ?

If the tool was a reasonably small, self-contained program or script, we could 
contribute it, but it's not.  The tool that generates these files is the 
"Xtensa Processor Generator".  It's big, complicated, proprietary, and it 
requires a certain environment to run.  And, since it is the heart of 
Tensilica's intellectual property (IP) and we're an IP company, there's no 
way I'd get permission to give it away regardless.

The problem here is that we allow our users to configure and extend the 
instruction set of an Xtensa processor in very flexible ways.  We need to 
generate code to handle things like instruction encoding and decoding.  The 
"source" for this code is a combination of user-selections from the Processor 
Generator GUI and user-supplied instructions specified in a proprietary 
language.  We wanted to be able to contribute something to FSF that is 
self-contained, buildable and useful, and we also want our users to be able 
to rebuild GNU tools with support for their own Xtensa configurations.

The solution (for now anyway) is to pick a specific and fairly generic Xtensa 
configuration for which we are contributing the generated files.  This is not 
an attempt to contribute a "crippled" version of the Xtensa port.  The 
default configuration has a reasonable set of features, and if there's some 
reason to switch to a different Xtensa configuration for the default, that 
would be fine with me.  If a Tensilica user wants to rebuild GNU tools for a 
different configuration, we give them versions of these generated files that 
they can use to replace the default versions.  Of course, all versions of the 
files are licensed under GPL.

This is the best approach I've been able to come up with.  I don't think any 
other binutils ports have had to face the issue of a configurable instruction 
set, so there wasn't a clear path to follow.  (I haven't looked in detail at 
the ARC port, but I didn't see anything there that handled the issues that 
came up with the Xtensa port.)  I think the warnings about modifying the 
generated files may be overly broad -- there's no problem with modifying 
those files as long as the interface is not changed.  If someone wanted to 
experiment with a different Xtensa configuration, it would not be hard to 
modify those files to describe a different instruction set.  It might be 
tedious, but not hard.  Changing the interface would be a problem because 
then it would not be possible to drop in versions of the files generated 
automatically for a different Xtensa configuration.

If anyone has questions or issues or suggestions about how this ought to be 
handled, I'll do my best to respond and be flexible.