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

["Ivan Warren" <ivan at vmfacility dot fr>]

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

Gentlemen,

A couple of things :

First, the i370 port (and contrary to the s390 port) is the only one providing HLASM (the traditional Assembler format) for legacy MVS (and subsequently VM and DOS/VS[E]).

Second, the s390 port provides only 31 bit addressing (and uses some instructions that are only available for that addressing mode) - while the i370 supports 24 bits addressing mode (and the related instructions).

The interresting part (as far as me & some of the people I am thinking about are concerned) of the i370 port is it's ability to create object output for *traditional* mvs, vm & dos/vs(e) programing (this excludes MVS/OE) : The output object format (and the execution object structure) are extremelly different from those supported by the binutils suite (for example, there are no notion of '.text .data or .bss sections')

We have a some people maintaining some (very outdated) operating systems for that architecture (but they do not have the licensing constraints of the recent versions).

Also, I must admit this is a very borderline (this is not a mainstream environment at all) and the lack of possible testsuite (because it cannot interface with binutils) makes it quite to effectivelly maintain.

However, my feeling is that it would be easier to maintain i370 (and possibly only i370-ibm-mvs) than trying to backport s390 to the 24 bit addressing mode architecture and HLASM output.

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. The necessary modifications to the rest of the tree structure are modifications that (I think) are required anyway in order to provide cross-pagecode support (essentially problems with string handling for language interpreted strings (like __asm__ parameters, __attribute__, extern, etc when the source & execution pagecodes are radically different - this is referenced in PR http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13258).

Finally, because the exception handling in these environment is, for the time being, not something that can be easily implemented (i370-ibm-mvs is actually a possible target for at least 3 different environments) means this backend is only usable for the 'c' language. This is also the case because there is (for the time being) no complete c libraries (there are a few attempts - at least 3 to provide a minimal C library).

Non-obsleting this backend is not of paramount importance, I must admit. But there is a user base, possible use for such a backend, and because the backend has a restricted execution environment use (c only) and because maintaining this backend should only affect the backend itself, I do think it shouldn't be too hard to do.

Thanks,

- --Ivan

> -----Original Message-----
> From: Kazu Hirata [mailto:kazu@cs.umass.edu] 
> Sent: Monday, February 02, 2004 5:36 AM
> To: ivan@vmfacility.fr
> Cc: gcc@gcc.gnu.org; mark@codesourcery.com; 
> dje@watson.ibm.com; zack@codesourcery.com
> Subject: Re: A Case to maintain target i370-*-mvs as a live target
> 
> 
> Hi Ivan,
> 
> > I would like to make a case to keep i370-*-mvs a 
> non-obsolete target 
> > for gcc.
> 
> Do you think you can derive your mvs port off of s390 port, 
> which is much better maintained?  Please follow the following 
> links for recent comments.
> 
http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00008.html

http://gcc.gnu.org/ml/gcc-patches/2004-02/msg00048.html

Kazu Hirata

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBQB5AC4dFv4a3KlzEEQJocACff8/uJ3D757ozpx6S0VCEtgwIpPwAoLB4
QRkufJYAru7MjDlC/vVOgYYG
=QVqX
-----END PGP SIGNATURE-----