e photo of the real 3270 terminal,
>> that MVC instruction has successfully straddled the
>> 2 GiB mark, even in a single instruction.
>>
>> As you can see from the photo in the second link above,
>> the memory at location 0 is different (still contains
>> the IPL P
t;Simply switching off optimization made the negative
> indexes go away, allowing more than 2 GiB to be
> addressed in standard z/Arch, with "-m31".
>
> Prove it on real hardware, not hercules. Hercules doesnt count.
>
> Joe
>
> On Wed, Sep 29, 2021 at 7:09 PM
On Fri, 3 Sept 2021 at 20:12, Ulrich Weigand
wrote:
> "Paul Edwards" wrote on 03.09.2021 13:35:10:
> > > Specifically, if you try to run AMODE64 with Pmode equals
> > > SImode, the compiler will not be aware that the hardware
> > > uses the high 32 bits of base and index registers, and
> > >
Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".
Prove it on real hardware, not hercules. Hercules doesnt count.
Real mainframe hardware is not easily accessible.
Hercules is the most convenient way
to add "-m32" as an alias for
> "-m31", but I would like to add as a request for it to
> work with optimization on.
>
> BFN. Paul.
>
>
>
>
> -Original Message-
> From: Paul Edwards
> Sent: Friday, September 3, 2021 11:12 PM
> To: Jak
lias for
"-m31", but I would like to add as a request for it to
work with optimization on.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Friday, September 3, 2021 11:12 PM
To: Jakub Jelinek
Cc: Ulrich Weigand ; gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
Hi Joe.
Thanks for your comments.
> It is unclear how this would even work.
> For instance, the LA instruction clears the top bit.
In AM64, LA does not clear any bits.
> Also, instructions like LPR, LNR,
These operate on data registers, not addresses,
and will continue to work unchanged.
>
It is unclear how this would even work.
For instance, the LA instruction clears the top bit.
Also, instructions like LPR, LNR, BXLE, BXH all treat the value in the
register as signed, so the top bit is not available.
Joe
> This is not in one single place, but spread throughout the
> compiler, both common code and back-end. I do not think it will
> be possible to get the compiler to generate correct code if
> you do not specify the address size correctly.
1. Is there any way to put a constraint on index
registe
On Fri, Sep 03, 2021 at 10:38:36PM +1000, Paul Edwards via Gcc wrote:
> > This is not in one single place, but spread throughout the
> > compiler, both common code and back-end. I do not think it will
> > be possible to get the compiler to generate correct code if
> > you do not specify the addres
>> > Also, the compiler
>> > will assume the base + index (+ displacement) arithmetic
>> > will operate in 32 bits -- I'm pretty sure this is
>> > actually the root cause of your "negative index" problem.
>> Where is this logic please? Can I do a #if 0 or similar
>> to disable it?
> This is n
"Paul Edwards" wrote on 03.09.2021 13:35:10:
> > Specifically, if you try to run AMODE64 with Pmode equals
> > SImode, the compiler will not be aware that the hardware
> > uses the high 32 bits of base and index registers, and
> > will not necessarily keep them zero.
> The compiler naturally
> - AMODE64 means the native address size is 64 bits. This
> implies that Pmode has to be DImode, since Pmode tells
> the compiler what the native address size is.
> Specifically, if you try to run AMODE64 with Pmode equals
> SImode, the compiler will not be aware that the hardware
> uses th
"Paul Edwards" wrote on 02.09.2021 22:05:39:
> > Is this about supporting a 4GB address space instead
> > of a 2GB space?
>
> Yes, correct.
OK, that makes things clearer. This implies in particular:
- 4GB address space means you need to run in AMODE64
- AMODE64 means the native address size
On Sep 03 2021, Paul Edwards via Gcc wrote:
> The “legacy” environment of z/Linux etc would be 32-bit
> instead of 31-bit. IBM’s reputation will be restored. IBM
> will have the best architecture on the planet. Better than
> x64 because no mode switch is required shifting between
> 32-bit and 64-b
Hi Ulrich. Thanks for your detailed reply.
>> > Therefore again my question, what is the actual goal
>> > you want to achieve? I'm still not sure I understand
>> > that ...
>> I would like to know what is required to implement
>> “-m32” in the S/390 target. I realize that z/Arch
>> doesn’t have
"Paul Edwards" wrote on 02.09.2021 17:26:25:
> > Therefore again my question, what is the actual goal
> > you want to achieve? I'm still not sure I understand
> > that ...
> I would like to know what is required to implement
> “-m32” in the S/390 target. I realize that z/Arch
> doesn’t have a
.
From: Ulrich Weigand
Sent: Friday, September 3, 2021 12:34 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the
>> I just checked my copy of s390.md and I don’t see
>> LA being used for arithmetic.
> This would be the "*la_31" and "*la_31_and" patterns.
Sorry, I did a grep for “LA”, forgetting that
s390.md doesn’t use uppercase instructions.
> (Note that the addition is implicit in the use of
> the "addres
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to address computation, of course.
For example, GCC may use LA on -m31 to implement a
31-bit addition, w
Hi Paul,
> I just checked my copy of s390.md and I don’t see
> LA being used for arithmetic.
This would be the "*la_31" and "*la_31_and" patterns.
(Note that the addition is implicit in the use of
the "address_operand" constraint.)
> If your copy of s390.md is using LA for arithmetic
> then wo
Hi Paul,
"Paul Edwards" wrote on 02.09.2021 10:15:44:
> We got the IPL process in place on ESA/390, and then
> I decided that the next thing to do would be to switch
> to z/Arch so that we could get rid of the AMODE 31
> architectural limit on 32-bit programs.
>
> It all worked fine, and we w
: Paul Edwards
Cc: gcc@gcc.gnu.org ; Ulrich Weigand
Subject: Re: s390 port
"Paul Edwards" wrote on 02.09.2021 16:50:35:
> Could you give me an example of an instruction
> generated by –m31 that is not expected to work
> on an AM64 system?
Well, everything related to addr
Hi Ulrich.
Below is the output as text.
Thanks. Paul.
make all-recursive
make[1]: Entering directory '/home/robertapengelly/Desktop/UDOS'
Making all in kernel
make[2]: Entering directory '/home/robertapengelly/Desktop/UDOS/kernel'
depbase=`echo irq.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\
s39
24 matches
Mail list logo
