This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [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.



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