A Case to maintain target i370-*-mvs as a live target

[Ivan Warren]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> On Monday 02 February 2004 13:18, Ivan Warren wrote:
> > > I did look at work required to (at least) obtain a workable 
> i370-ibm-mvs
> > port - and (almost) all the work resides in the 
> gcc/config/i370 directory.
> 
> This is not just about making the port working with the existing
> GCC infrastructure.  It is also about cleaning up GCC itself, and
> from looking at http://gcc.gnu.org/backends.html you'd say that
> i370 is a "problematic target":
> - There is no known simulator

There is freely available emulator at www.conmicro.cx/hercules (which
is actually the reason for the case in maintaining the port). Some of
the freely available operating systems (excluding linux) are the
actual targets (they are old operating systems, definitelly not
posix)

> - The port does not define the prologue/epilogue in RTL

The reason for the 'exotic' prolog/epilog are really because of the
exotic linkage convention used in the targeted operating systems [1].
However, it should be possible to have an RTL description of the
prolog & epilog.

> - It uses the old define_peephole
> - It doesn't use define_constant
> - It is a cc0 target.

I cannot comment on the above. My gcc internals knowledge is yet too
rudimentary. The question is really : Do the above make it impossible
to maintain the port, or does it mean some extra work is needed to
comply to these constraints ?

> 
> So it uses at least four things we're trying to avoid in new ports
> and working on removing in existing ports.  That is also part of
> maintaining ports.
> 
> Gr.
> Steven
> 

I think I now have a better understanding for the reason to obsolete
the port.

My plan was to maintain in a somewhat 'workable' state the port
anyway (even if it is obsolete) - be it for my personal use. The idea
was that, if it was possible to officially maintain the port, to
lessen the workload required to maintain it, and of course, let other
people benefit from it.

If the decision to obsolete the port is maintained (which I would
understand) then I will possibly try to instanciate a new port that
would both satisfy the new gcc constraints while making it possible
for users of the emulator using the targeted operating system to have
a working gcc compiler.

- --Ivan

[1] However, if the port is purelly standalone, the ABI itself can be
redesigned and it would be possible to use any kind of routine
linkage convention (with the exception that the architecture doesn't
define a stack per-se).

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQB5rhodFv4a3KlzEEQJBGwCfYnYTsi0IXtlE0weBQC44uLTz0O8AniER
87gfALmAHJa3921hEUVZfMbX
=uPjk
-----END PGP SIGNATURE-----