If I have code like this:
char foo(char *p)
{
return (p[-1]);
}
It generates a negative index, like this:
* Function foo code
L 2,=F'-1'
L 3,0(11)
SLR 15,15
IC15,0(2,3)
* Function foo epilogue
See that (2,3) - that is adding both R2 + R3.
R3 is
eally understand
your answer. :-) ).
Thanks. Paul.
-Original Message-
From: Richard Biener
Sent: Sunday, March 14, 2021 7:05 PM
To: Paul Edwards ; Paul Edwards via Gcc ; gcc@gcc.gnu.org
Subject: Re: negative indexes
On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc
wrote:
M
To: Paul Edwards ; Paul Edwards via Gcc ; gcc@gcc.gnu.org
Subject: Re: negative indexes
On March 14, 2021 6:55:32 AM GMT+01:00, Paul Edwards via Gcc
wrote:
If I have code like this:
char foo(char *p)
{
return (p[-1]);
}
It generates a negative index, like this:
* Function foo code
Would it be possible for GCC to generate code
that reserves ESI and EDI as "extended segment"
registers to hold a source and destination
"extended segment" of any operation.
This will be the upper 32-bits of a 64-bit address.
When run on a normal 80386, such code will work
fine, and ESI and EDI
Actually, what I want is a processor with ECS,
EDS and EES, as new registers, and for GCC
to target that, supporting near, far and huge
code pointers and data pointers.
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Tuesday, March 16, 2021 12:55 AM
To: GCC Development
Subj
Hi Ulrich.
Sorry for the necro - things happen slowly Down Under. :-)
Anyway, I am helping someone with their public domain
project, UDOS - https://github.com/udos-project/udos
(just a hobby, won't be big and professional like Linux)
We got the IPL process in place on ESA/390, and then
I decid
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
Hi Ulrich.
I just checked my copy of s390.md and I don’t see
LA being used for arithmetic.
If your copy of s390.md is using LA for arithmetic
then would it be possible to have an option to
use a normal mathematics instruction instead of
LA?
Do you have any more examples besides LA being
used for
>> 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
Hi Ulrich.
Thanks a lot for your reply.
Could you give me an example of an instruction
generated by –m31 that is not expected to work
on an AM64 system?
E.g. the 32-bit
LR R2,R3
will definitely work on AM64.
So what specifically won’t work? How many different
things won’t work?
Thanks. Paul.
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
> - 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
>> > 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
> 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
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.
>
We have fait accompli now:
https://gcc.gnu.org/pipermail/gcc/2021-September/237456.html
Simply switching off optimization made the negative
indexes go away, allowing more than 2 GiB to be
addressed in standard z/Arch, with "-m31".
The above request is to add "-m32" as an alias for
"-m31", but I
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
Hi Michael.
Thanks for picking up this issue. I have been working
with Jesus on this.
m31 is semantically the same as the m32 option.
The m31 option allows for 32 bit addressing and that is confusing since
the m31 option in S390 would mean 2 GiB space addressing
Indeed that's exactly what
Hi Michael.
I have sort of (I used the i370 target of GCC 3.2.3 instead
of the s390 target) reproduced Jesus's work with z/PDOS
which can be obtained from here:
http://www.pdos.org/zpdos.zip
You can see that with standard Hercules 3.13:
18:02:24 Hercules Version 3.13
18:02:24 (c)Copyright 1999
Hi.
In certain places, the i370 target of GCC 3.2.3 will use a
base + index + displacement operand.
How can I add a constraint to say that the index must be
between 0 and 0x7fff?
I want to stop 0x from being generated when I have:
char *p
p[-1];
Thanks. Paul.
--
This email has be
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
> > >
ded back in, for
that too, given that that is the correct technical nature
of the GCC-generated code?
Thanks. Paul.
"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 hardw
MVC 0(4,2),0(3)
>> MVC 88(4,13),=A(@@LC35)
>> LA1,88(,13)
>> L 15,=A(@@7)
>> BALR 14,15
>>
>>
>> @@LC32 EQU *
>> DCC'MEMTEST'
>> DCX'0'
>> @@LC3
I have a slightly modified gcc 3.2.3.
Source is available in gcc-stage* in custom.zip at http://pdos.org
Executables are available in customb.zip but everything that
is really needed is in pdos.zip
gccdos.txt has instructions to run windows.mak which
produces the gccx64.exe that I use, but has t
I normally use gcc 3.2.3 to build executables that
work with msvcrt.dll, which has 32-bit int, long and ptr.
I tried changing long to 64 bits and the new compiler
encountered the following issue when attempting to
build itself. Documented and fixed below, unless
someone has a better fix. Note that
Hi.
I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
int fff(char *x)
{
return (x[-1]);
}
It is generating:
.globl fff
fff:
.LFB2:
movl$4294967295, %eax
movsbl (%rax,%rcx),%eax
ret
My understanding is that that move of -1 into eax
does NOT s
On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek wrote:
On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote:
>> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
> Don't, gcc 3.2.3 is not supported for more than 20 years already.
And the i370 targ
t; On Wed, 7 Feb 2024 at 23:12, Jakub Jelinek wrote:
> On Wed, Feb 07, 2024 at 11:02:51PM +0800, Paul Edwards via Gcc wrote:
>
> >> I am using a slightly modified gcc 3.2.3 for x86_64 and for this code:
>
> > Don't, gcc 3.2.3 is not supported for more than 20 years alread
cc>type foo.c
> int foo(char *in)
> {
> return in[-2];
> }
>
> D:\devel\gcc\gcc>
>
>
> Note that my flavor of gcc 3.2.3 can be found in gcc-stage*.zip
> in custom.zip at http://pdos.org
>
>
>
>
> On Sat, 10 Feb 2024 at 05:34, Paul Edwards wrote:
(replying to Joe Monk)
> It appears that this is not an issue that this version of GCC is
> architected to be able to solve.
> The first 64-bit PC processor, the AMD opteron series, was launched on
> April 22, 2003.
> GCC 3.2.3 was released on April 25, 2003.
Jakub has already shown correct x64
t; TREE_CONSTANT (folded) = TREE_CONSTANT (ptrop) & TREE_CONSTANT (intop);
> return folded;
> }
>
>
>
> On Sat, 10 Feb 2024 at 05:38, Paul Edwards wrote:
>
>> Oh - I switched to -2 to make debugging easier:
>>
>> D:\devel\gcc\gcc>type foo.c
>> int foo(cha
Hello.
I have a mainframe operating system called z/PDOS-generic
available from https://pdos.org
I have ported a slightly modified gcc 3.2.3 (called
gccmvs) to it, and when run under Hercules/380
(mainframe emulator) it works fine and gccmvs is
able to reproduce itself byte-exact.
But I have a n
> But I have a new emulator called mfemul.c, and it
> isn't very mature and almost certainly has a bug in
> it that is affecting gcc 3.2.3. And since that is the only
> Any suggestions on where to stick some printfs so that
> I can start looking for a divergence, given that the
> generated code is
Hi.
I already have a mini-clone of Windows (two actually -
PDOS/386 and PDOS-generic), but both are ASCII.
I now wish to create an EBCDIC version.
I have an i370 EBCDIC version already (z/PDOS and
z/PDOS-generic), and the end result is that I have been
able to compile the gcc 3.2.3 source code o
Problem wasn't with EBCDIC. It was with the 8-character
limitation on externals traditionally seen on MVS mainframes,
causing a source file to be eliminated and a different function
called. And not something that the linker can detect as a
duplicate as a failsafe.
Fixed with this:
#define schedul
35 matches
Mail list logo
