"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
"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
"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
"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
On Thu, May 06, 2021 at 04:07:52PM +0200, Eric Botcazou wrote:
> > On the other hand, even the name of the attribute specifically
> > refers to *scalar* types, and the C standard does classsify
> > pointer types amongst the scalar type. So maybe this was
> > originally intended?
>
> I don't think
Hello,
for a few years now, GCC has supported the scalar_storage_order
attribute (and pragma) that allows specifying the storage order
(endianness) of structures. This affects both the code GCC
generates to access variables declared using the attribute,
and also the debug info: GCC emits the DW_A