Re: z/Linux 32-bit modules

>>> On 5/29/2018 at 01:45 AM, Paul Edwards wrote: > Hi Philipp. > > Thanks a lot for those 2 links. Now I see that > some work needs to be done by the Linux > team (not by application programmers) to run > ELF32 binaries as AM64 instead of AM31. > > BFN. Paul. > >

Re: z/Linux 32-bit modules

>>> On 5/29/2018 at 01:45 AM, Paul Edwards wrote: > Hi Philipp. > > Thanks a lot for those 2 links. Now I see that > some work needs to be done by the Linux > team (not by application programmers) to run > ELF32 binaries as AM64 instead of AM31. Define "Linux team" because at this point, it

Re: z/Linux 32-bit modules

Hi Philipp. Thanks a lot for those 2 links. Now I see that some work needs to be done by the Linux team (not by application programmers) to run ELF32 binaries as AM64 instead of AM31. BFN. Paul. -- For LINUX-390 subscribe /

Re: z/Linux 32-bit modules

Ingo Adlung wrote: >Not only may the distributors at some point choose to >deprecate 31 (32) bit compat mode, but all performance >optimizations for the gcc compiler back-end for >new Z hardware are done for 64-bit only. OK, that's some confirmation of what I suspected might be happening. And I

Re: z/Linux 32-bit modules

>>> On 5/28/2018 at 09:46 AM, Ingo Adlung wrote: > Different to the spirit of this mail thread I would like encouraging > you to invest in 64-bit versions of your software. Not only may the > distributors at some point choose to deprecate 31 (32) bit compat mode, That is going to happen with

Re: z/Linux 32-bit modules

Ubuntu Server for IBM Z and LinuxONE aka s390x (started with 16.04 LTS, released in April 2016) was always 64-bit only, hence no 31-bit (legacy) support for any of the Ubuntu Server for s390x releases so far. Frank Heimes | Tech. Lead Ubuntu Server on Z | Canonical Ltd. mail:

Re: z/Linux 32-bit modules

- or will be as we move on. Linux on 390 Port <LINUX-390@VM.MARIST.EDU> wrote on 28.05.2018 08:15:57: > From: Paul Edwards <mutazi...@gmail.com> > To: LINUX-390@VM.MARIST.EDU > Date: 28.05.2018 13:53 > Subject: Re: [LINUX-390] z/Linux 32-bit modules > Sent by: L

Re: z/Linux 32-bit modules

On 2018-05-28 08:15, Paul Edwards wrote: And that, Paul, is why it’s not going to fly. All of the 31 bit code would have to be reimplemented. A bunch of other people do all that work and take on all the risk to what end? Hi Alan. What code needs to be reimplemented? I think it is very

Re: z/Linux 32-bit modules

> And that, Paul, is why it’s not going to fly. > All of the 31 bit code would have to be reimplemented. > A bunch of other people do all that work and > take on all the risk to what end? Hi Alan. What code needs to be reimplemented? I think it is very unlikely any C code needs to be changed.

Re: z/Linux 32-bit modules

, mutazi...@gmail.com wrote: From: mutazi...@gmail.com To: LINUX-390@VM.MARIST.EDU Cc: Date: May 27, 2018, 3:45:32 PM Subject: Re: [LINUX-390] z/Linux 32-bit modules >> Hi Joe. You didn’t show the ELF32 ABI which >> is what is being discussed. > Yes I did

Re: z/Linux 32-bit modules

Hypotheses are interesting, but does anyone have any comparative performance-related data? It's not too hard for me to imagine that the compiler writers and maintainers might actually be able to do a better job with their 64-bit code optimizers if they have less work to do otherwise. Let me also

Re: z/Linux 32-bit modules

"I read the whole thing and it doesn’t discuss ELF32 at all, and it says that pointers are 8 bytes in size." My bad. I linked you to the z/series ABI. You wanted the s/390 ABI, which is known as compat mode on z/series. http://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_s390/book1.html "My

Re: z/Linux 32-bit modules

>> Hi Joe. You didn’t show the ELF32 ABI which >> is what is being discussed. > Yes I did. Same document covers 32-bit and 64-bit. No it doesn’t. I read the whole thing and it doesn’t discuss ELF32 at all, and it says that pointers are 8 bytes in size, not sometimes 4, sometimes 8. >> assuming

Re: z/Linux 32-bit modules

"Hi Joe. You didn’t show the ELF32 ABI which is what is being discussed." Yes I did. Same document covers 32-bit and 64-bit. "assuming the z/Linux 31-bit software is made AM-anything, if it isn’t already." It aint the software. Its the hardware. The hardware cannot process 32-bit. It can

Re: z/Linux 32-bit modules

> You can't run a 32-bit linux program in AM64. > As I've pointed out to you, the ABI does not allow it. Hi Joe. You didn’t show the ELF32 ABI which is what is being discussed. In addition, even if the ELF32 ABI explicitly said “this runs as AM31”, that doesn’t mean the documentation can’t simply

Re: z/Linux 32-bit modules

You can't run a 32-bit linux program in AM64. As I've pointed out to you, the ABI does not allow it. Joe On Sat, May 26, 2018 at 1:04 PM, Paul Edwards wrote: > > z/Linux was written for 31-bit addressing hardware. So the top bit is > > always expected to be set in 32-bit

Re: z/Linux 32-bit modules

> z/Linux was written for 31-bit addressing hardware. So the top bit is > always expected to be set in 32-bit data/31-bit addressing user mode. That top bit ceases to be used by the hardware in BALR etc if the 32-bit program is run as AM64. So the only issue is whether any *code* goes to the

Re: z/Linux 32-bit modules

On 5/26/18 5:28 AM, Paul Edwards wrote: >> Right off the bat, all the ones that require >> you to set the high order bit of >> the last argument address. > > I am surprised that there exists any such > code in z/Linux. > > That was something traditionally done on z/OS > (but has to be reworked

Re: z/Linux 32-bit modules

> Right off the bat, all the ones that require > you to set the high order bit of > the last argument address. I am surprised that there exists any such code in z/Linux. That was something traditionally done on z/OS (but has to be reworked to work as AM64), but I expected most things in z/Linux

Re: z/Linux 32-bit modules

Hi Alan. My previous message seems to have been reformatted badly, so I am trying again. What 31-bit APIs do you think would break if they were run as AM64, and why can’t that code be updated to be quadmodal (24/31/32/64)? I would want all the APIs updated prior to anyone running 32-bit programs

Re: z/Linux 32-bit modules

On 5/25/18 2:50 PM, Rick Troth wrote: > Problem is that most people are just not interested. Most people just > don't care (that we're wasting bytes and maybe a few cycles). When > building, they don't bother to mark 'sed' (or anything) as "make this > one 32-bit". It would be extra effort. Or

Re: z/Linux 32-bit modules

/Linux 32-bit modules > The performance benefit of "compactness"> isn't worth (IMO) the breakage that comes> with it. Under laboratory conditions you> can create 32-bit programs with AM64. > They just can't (generally) deal with> 31-bit APIs, something they must u

Re: z/Linux 32-bit modules

> The performance benefit of "compactness"> isn't worth (IMO) the breakage that > comes> with it. Under laboratory conditions you> can create 32-bit programs > with AM64. > They just can't (generally) deal with> 31-bit APIs, something > they must use to> get the benefit of 32-bit registers.

Re: z/Linux 32-bit modules

>>> On 5/25/2018 at 05:18 PM, Alan Altmark wrote: -snip- > The performance benefit of "compactness" isn't worth (IMO) the breakage > that comes with it. Under laboratory conditions you can create 32-bit > programs with AM64. They just can't (generally) deal with

Re: z/Linux 32-bit modules

On Friday, 05/25/2018 at 08:51 GMT, Mark Post wrote: > >>> On 5/23/2018 at 01:25 PM, Alan Altmark wrote: > > While Paul doesn't need to express the value of AM32 (it's obvious) > > Not to me. 4 GiB address space without increasing the space needed to

Re: z/Linux 32-bit modules

>>> On 5/23/2018 at 01:25 PM, Alan Altmark wrote: > While Paul doesn't need to express the value of AM32 (it's obvious) Not to me. Mark Post -- For LINUX-390 subscribe / signoff / archive access

Re: z/Linux 32-bit modules

On Fri, May 25, 2018 at 7:52 AM Rick Troth wrote: > I've been trying to follow this thread, but I'm not seeing the "what's > the problem we're trying to solve?" part. (I think I saw the question, > but didn't see the answer.) > ​Paul seems to have a "hang up" about AM-31. He

Re: z/Linux 32-bit modules

I've been trying to follow this thread, but I'm not seeing the "what's the problem we're trying to solve?" part. (I think I saw the question, but didn't see the answer.) It's known that, on bi-modal processors with 64-bit kernels, 32-bit applications run faster. (And here I count AM31 as

Re: z/Linux 32-bit modules

Timothy – I don’t personally have any programs that have lots of pointers in memory so that the effect of defeating the cache can be demonstrated. But while ever people are building ELF32 binaries for reasons that they think make sense, I would like to see “truth in advertising” and for gcc to use

Re: z/Linux 32-bit modules

Paul Edwards wrote: >I don't want to use -m64 because that uses the >64-bit registers for everything, but I wish to produce >compact modules using only 32-bit registers and >pointers. OK, so let's dig into this a bit. Have you taken one or more of your programs and compared -m31 and -m64

Re: z/Linux 32-bit modules

Paul, Did you read the Linux ABI document that I linked to you? Joe On Wed, May 23, 2018 at 5:19 PM, Paul Edwards wrote: > Hi Philipp. > > Which CPU instruction do you think a -m31 compile > produces that won't work in AM64 mode when > malloc() starts returning addresses

Re: z/Linux 32-bit modules

Hi Philipp. Which CPU instruction do you think a -m31 compile produces that won't work in AM64 mode when malloc() starts returning addresses between 2 GiB and 4 GiB? I can't think of any. As far as I know a -m24, -m31 or -m32 would produce identical code if those options were available. People

Re: z/Linux 32-bit modules

On Wednesday, 05/23/2018 at 05:08 GMT, Philipp Kern wrote: > On 2018-05-23 08:57, Paul Edwards wrote: > > I would think that most ELF32 programs are already > > able to use the full 4 GiB address space without > > needing a recompile. malloc() can start returning > > addresses

Re: z/Linux 32-bit modules

On 2018-05-23 08:57, Paul Edwards wrote: I would think that most ELF32 programs are already able to use the full 4 GiB address space without needing a recompile. malloc() can start returning addresses in the 2 GiB - 4 GiB range. Traditionally this is untrue on s390 because -m31 produces 31bit

Re: z/Linux 32-bit modules

I believe such an approach might break C semantics regarding pointer addition? In a 32-bit address space (where presumably only 32-bits of the register are used to address a value) the addition of a pointer past-the-end (or prior to the start) of an addressable object is undefined. C compilers

Re: z/Linux 32-bit modules

> > Hi Timothy. > Great questions. I don't want to use -m64 because that uses the 64-bit registers for everything, but I wish to produce compact modules using only 32-bit registers and pointers. I would think that most ELF32 programs are already able to use the full 4 GiB address space without

Re: z/Linux 32-bit modules

Paul Edwards wrote: >I would like the z/Linux kernel to be modified >to start an ELF32 binary in AM64 and have access >to a full 4 GiB address space. Leaving aside technical viability for a moment, I have a basic application change management concern. Shouldn't the program binary make its own

Re: z/Linux 32-bit modules

Hi Martin. Thanks for your reply. >> If the answer is AM31, then what happens if it >> is run as AM64 instead? > The process is started by the kernel in the "correct" mode, > you can not specify that a ELF32 binary is started in AMODE-64. > The kernel enforces limits as well, e.g. with a 31-bit

Re: z/Linux 32-bit modules

On Mon, 21 May 2018 07:21:38 +1000 Paul Edwards wrote: > When 32-bit modules are created on z/Linux > using "gcc -m32" or whatever, is the resultant > module run as AM31 or AM64? The -m31 option creates objects and binaries in the ELF32 format. Without the option or with

z/Linux 32-bit modules

When 32-bit modules are created on z/Linux using "gcc -m32" or whatever, is the resultant module run as AM31 or AM64? If the answer is AM31, then what happens if it is run as AM64 instead? Thanks. Paul. --- This email has been checked for viruses by AVG. https://www.avg.com