[llvm-dev] RFC: Adding support for the z/OS platform to LLVM and clang

Thu Jun 18 05:02:07 PDT 2020

Thanks for the feedback!

As summary,
- some concerns about added complexity and testability were expressed
- details of the encoding conversion in the clang frontend were discussed

For these kinds of discussion, it's best to have a look at the source, so 
I created the first Phabricator review: https://reviews.llvm.org/D82081 

Thanks again!

Best regards,
Kai Nacke
IT Architect

IBM Deutschland GmbH
Vorsitzender des Aufsichtsrats: Sebastian Krause
Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger, Norbert 
Janzen, Markus Koerner, Christian Noll, Nicole Reimer
Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht Stuttgart, 
HRB 14562 / WEEE-Reg.-Nr. DE 99369940

"llvm-dev" <llvm-dev-bounces at lists.llvm.org> wrote on 10.06.2020 21:11:05:

> From: Kai Peter Nacke via llvm-dev <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Date: 10.06.2020 21:11
> Subject: [EXTERNAL] [llvm-dev] RFC: Adding support for the z/OS 
> platform to LLVM and clang
> Sent by: "llvm-dev" <llvm-dev-bounces at lists.llvm.org>
> 
> As part of IBM’s ongoing efforts to improve the z/OS ecosystem, our 
> current plans involve adding support for the z/OS platform to LLVM and 
> Clang. Our goal is to have a viable C and C++ LLVM compiler and runtime 
> library that generates code for, and runs on z/OS.
> 
> Long term, we expect to have a compiler and library that supports the 
> platform more fully. We intend to support the native character encoding 
> (EBCDIC), file system - z/OS UNIX System Services (z/OS UNIX) files and 
> datasets, addressing modes (31-bit and 64-bit, and possibly 24-bit), 
> different floating and fixed point formats, systems programming 
> capabilities, language co-processors, and generating code output in the 
> z/OS object file formats (GOFF and XOBJ).
> 
> The tentative plan is to initially support the z/OS Unix System Services 

> (z/OS UNIX) interface with EBCDIC and ASCII 64-bit code generation. In 
> particular, our intent would be to focus on:
> 1) C++ standard library support. We would be making changes to the 
library 
> so it can work on z/OS.  We would need some design discussions with the 
> community for issues such as character encodings.
> 2) EBCDIC source file input. We would need reviews at the Clang level 
when 
> dealing with reading source files and dealing with multiple code pages.
> 3) GOFF object file output. We would need reviews in LLVM to add a new 
> object file output format.
> Our plans include setting up z/OS build bots and we will update the list 

> when we have them ready to go.
> 
> To begin, we plan to add patches that would:
> - Set the new triple for z/OS
> - Make changes to the build recipes and tools (cmake, etc.) as needed to 

> allow building for z/OS
> Following that, we intend to start on the focus areas listed above:
> 
> 1) Add patches to enable building and using the C++ standard library on 
> z/OS. In particular, issues dealing with EBCDIC would need to be 
> addressed. We would need to have functions in the headers (e.g. 
iostream) 
> that work on ASCII encoded strings, and functions that work on EBCDIC 
> encoded strings. These would need to work with the underlying system C 
> library (e.g. printf) that provides the actual functionality. For 
example, 
> currently, the z/OS C library has (at least) two sets of functions 
(ASCII 
> and EBCDIC versions). The one used by the application is selected at 
> compile time during the system header file processing which selects the 
> correct function via mapping the programmer function name (e.g. printf) 
> into one that the application will link to (e.g. __printf for EBCDIC and 

> \174\174A00118 for ASCII). We would also add patches to disable 
> functionality when on z/OS where there is no support for the 
> functionality. For example, thread specific locales would be disabled 
when 
> in a non-POSIX mode.
>   Our intent is that follow on patches would incrementally add support 
in 
> tandem with the compiler for features that require it and for other z/OS 

> specifics such as various floating/fixed point formats.
> 
> 2) Add patches to Clang to allow EBCDIC and ASCII (ISO-8859-1) encoded 
> input source files. This would be done at the file open time to allow 
the 
> rest of Clang to operate as if the source was UTF-8 and so require no 
> changes downstream. Feedback on this plan is welcome from the Clang 
> community.
>   Our intent is that later patches would handle execution character set 
> differences. Collaboration with the community here would be useful in 
> areas such as adding in exec-charset and library selection options and 
> strategies.
>   Our intent is also to make changes to support any platform issues, 
> processing native C header files, and idiosyncrasies on z/OS such as 
> having no native strnlen function. We would update test tooling to 
handle 
> character encoding issues as needed. Further design discussion will take 

> place on the Clang mailing list.
> 
> 3) Add patches to LLVM that will stub out GOFF object binary generation. 

> We would not be generating assembly (HLASM in z/OS), and instead only 
> generate the binary object directly for the initial round of changes. 
> Assembly generation would follow in later stages once we have a working 
> compiler on z/OS. Feedback on this plan of direction is appreciated.
>   Our intent is that patches that incrementally add support for GOFF 
> object generation such as code sections and records would follow. The 
next 
> steps after support for the object file format would be handling the 
z/OS 
> XPLINK calling convention. This would involve changes to both Clang and 
> LLVM and we intend to follow the same style of functional component 
> responsibility as is done for other platforms calling conventions. If we 

> believe deviations from this is necessary, we plan on notifying the 
> community and ensuring the reasons behind the deviations are valid and 
> accepted.
> 
> Any feedback or comments are welcome.
> 
> Notice: IBM’s statements regarding its plans, directions, and intent are 

> subject to change or withdrawal without notice at IBM’s sole discretion. 

> Information regarding potential future products is intended to outline 
our 
> general product direction and it should not be relied on in making a 
> purchasing decision. The information mentioned regarding potential 
future 
> products is not a commitment, promise, or legal obligation to deliver 
any 
> material, code or functionality. Information about potential future 
> products may not be incorporated into any contract. The development, 
> release, and timing of any future features or functionality described 
for 
> our products remains at our sole discretion.
> 
> Best regards,
> Kai Nacke
> IT Architect
> 
> IBM Deutschland GmbH
> Vorsitzender des Aufsichtsrats: Sebastian Krause
> Geschäftsführung: Gregor Pillen (Vorsitzender), Agnes Heftberger, 
Norbert 
> Janzen, Markus Koerner, Christian Noll, Nicole Reimer
> Sitz der Gesellschaft: Ehningen / Registergericht: Amtsgericht 
Stuttgart, 
> HRB 14562 / WEEE-Reg.-Nr. DE 99369940
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?
> 
u=https-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-
> siA1ZOg&r=43FMMTMN1rMQYLfzcfWYI9JmFbjyCLLZVkpxUNJkDuQ&m=yMqyEWU-
> 
Y3yQdOvsfp9HBkSwlDeLE5A9ZydkH_73SZk&s=ymE6YLFHNgGyUlKieWzvyvY5QV4ycTojjrma8Uz_rhs&e=
> 