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 /
> 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.
>> 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
> 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
> 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
> 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
> 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.
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
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
>
> 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
mail_source=link_campaign=sig-email_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On 22 May 2018 at 21:31, Martin Schwidefsky <schwidef...@de.ibm.com> wrote:
> On Mon, 21 May 2018 07:21:38 +1000
> Paul Edwards <mutazi...@gmail.com> wrote:
>
> &
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
13 matches
Mail list logo
