>>> 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.
>
>
>>> 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
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 /
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
>>> 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
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:
- 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
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
> 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.
, 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
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
"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
>> 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
"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
> 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
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
> 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
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
> 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
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
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
/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
> 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.
>>> 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
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
>>> 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
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
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
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
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
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
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
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
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
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
>
> 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
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
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
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
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
40 matches
Mail list logo