Re: Xtensa port, part 2: config.gcc and new config/xtensa files

[Bob Wilson <bwilson at tensilica dot com>]

Richard Henderson wrote:
> 
> On Mon, Dec 03, 2001 at 04:24:30PM -0800, Bob Wilson wrote:
> > OK.  I knew I had to do this for 3.1 anyway.  I guess I might as well do
> > it for the 3.0 version as well....
> 
> Err.. just so you know, I was reviewing this for 3.1, not 3.0.
> I suspect that Mark won't take new ports for 3.0.3 at this point,
> and I would be surprised if there's a 3.0.4.  In either case,
> you'd need his ok for it to go onto the release branch.

I had been assuming for a long time that there was no way we could
contribute something for 3.0.x, but I decided that it couldn't hurt to
ask.  Mark has not yet agreed to take these changes on the 3.0 branch,
but when I asked, he replied that it was a possibility "assuming that
people are persuaded that your port is useful to the community and
properly coded."

So I guess I'm just going to wait and see whether people think this port
is useful and properly coded....  It would certainly be _very_ useful to
us and some of our customers to have the Xtensa port included in 3.0.3,
and if not that, any subsequent 3.0.x releases.


> Besides, there's
> 
> toplev.h:#define fatal_insn(msgid, insn)
> toplev.h:#define fatal_insn_not_found(insn)
> 
> and several other similar diagnostic routines already defined.

OK.  I grepped for "abort" and didn't see anything, but I'll be happy to
use these alternatives.  "fatal_insn" sounds fine to me.


> > It isn't emitted by the prologue expander.  The only way that I could
> > find to make this work without adding new hooks into GCC was to emit the
> > "unspec_volatile" as a side effect of copying the incoming argument in
> > a7 (the hard frame pointer register) to a pseudo.  I could look at the
> > number and types of the incoming arguments to determine if there is an
> > argument in a7 but I'd still have to find the "unspec_volatile" insn
> > since I need to transform all the instructions prior to that point.
> > It's a lot easier to just search for it.
> 
> Oh lord.  I'll reiterate what I may have mentioned before in
> another thread -- I think it's a big mistake to define an ABI
> that passes arguments in the hard frame pointer -- but let it
> go for now.

I know the Xtensa ABI is tricky to implement in GCC, but changing it
isn't an option for me right now.  There are lots of other tools and
code already written with the existing ABI, so I just need to find a way
to make it work in GCC.