This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch] Raise the dead: i860
- From: Jason Eckhardt <jle at owlnet dot rice dot edu>
- To: "Joseph S. Myers" <jsm at polyomino dot org dot uk>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 9 Aug 2003 11:48:52 -0500 (CDT)
- Subject: Re: [Patch] Raise the dead: i860
On Sat, 9 Aug 2003, Joseph S. Myers wrote:
> On Sat, 9 Aug 2003, Jason Eckhardt wrote:
>
> > This patch un-purges the i860 port. The "new" config/i860/* files
> > are mostly unchanged from the final pre-purge versions, and obviously
> > won't build (pre-targetm port, poisoned macros, etc.). Follow-up
> > patches will resolve the build problems.
>
> I believe that if a target is restored it needs to follow the requirements
> for new targets (described in sourcebuild.texi) fully - for example,
> although the target options supported by the i860 port weren't documented
> before it was removed (bug 5362, still open for some other targets), it
> must not be added back without full documentation.
There are no target options. If you are referring to the
TARGET_SWITCHES that are currently in i860.h, those were never
actually implemented and will be removed or commented for future
use.
>
> I'd rather see a patch that makes the target work and conform to the
> requirements of new targets (and cleanups such as not referring to "GNU
> CC", not using PARAMS or old-style function definitions), that for
> existing files is against current CVS versions; for files that were
> removed is against the last version before they were removed; and for any
> new files gives the contents of the new file.
The idea was to first get the i860 pieces back in place, so
I could begin committing incremental changes such as these. Is that
okay with everybody? I have follow-up patches which take care of
the ISO C90 conversion as well as others, see below. But I prefer
not to queue up large numbers of un-related changes as one huge
patch-- further, many incremental changes will happen more slowly,
over time, like every other part of the compiler.
Most importantly, the back-end macros (target hooks) are changing so
rapidly, I want to avoid further divergence and get the pieces
back in place so they will be subject to the normal conversion
process as people add/change hooks.
> I don't think adding a
> nonworking target is a good idea; when it is added it should be in such a
> state that reasonable testresults for the target (at least for C if not
> other languages) can be sent to gcc-testresults.
There is a follow-up patch which remedies the build problems. Again,
I'd like to get the old baseline port back in place so I can begin
committing incremental changes to the repository as time permits.
But the i860 port requires far more work to get "reasonable" test
results. This will have to happen incrementally, over time, as I
do this in my very rarified "spare" time fragments.
>
> > * config/i860/varargs.asm: New.
>
> This file was added in revision 1.2, "preserve i860 __builtin_saveregs for
> future reference"
> <http://gcc.gnu.org/ml/gcc-patches/2001-04/msg01121.html>. Could you fix
> the i860 varargs support rather than re-adding that file, which is in CVS
> if wanted for reference?
>
I have mostly fixed the varargs support, which is in a follow-up patch.
However, this routine is still necessary to link i860 code.
Eventually, I may also do builtin_saveregs as rtl so the external routine
will be unnecessary-- but that is future work. For now, this works
reasonably well.
> > * config/i860/xm-i860.h: New.
>
> This file was removed in a previous cleanup of Zack's some time before the
> target was removed, and should not need to be added back.
>
You're right, I missed that. I won't add it back.
Thanks, jason.