The revision history of the FSF version of GCC between the EGCS split
and the merge was retained on premerge-fsf-branch. That lets me see
that this change was committed by Richard Kenner on 1998-10-04.
Thanks Ian. I contacted Richard but unfortunately he had no
evidence of communicating with me
In GCC 3.4.6, in order to create a single executable called "gcc" that
takes C code and produces assembler, I needed to put this code into gcc.c:
#ifdef SINGLE_EXECUTABLE
{
int cnt = 0;
while (commands[i].argv[cnt] != NULL)
{
cnt++;
}
if (s
It seems to me that in addition to doing a strcmp to cc1, I would
also have needed to do a strcmp to cccp. Can someone confirm
that GCC 2.8.1 and GCC 3.4.6 differ in that respect - ie there
was an extra executable (cccp) in GCC 2.8.1 when doing that
task of converting from C to assember (ie compil
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:
Paul.
-Original Message-
From: Paul Edwards
Sent: Sunday, March 14, 2021 7:12 PM
To: gcc@gcc.gnu.org ; Richard Biener
Subject: Re: negative indexes
Hi Richard. Thanks for your reply, but if I understand
you correctly, you are saying this fix is for situations
where the size of an integ
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
000444
01:28:40 quit
01:28:40 HHCIN900I Begin Hercules shutdown
Any idea what we can do?
Thanks. Paul.
-Original Message-
From: Ulrich Weigand
Sent: Saturday, June 6, 2009 1:20 AM
To: Paul Edwards
Cc: gcc@gcc.gnu.org
Subject: Re: i370 port
Paul Edwards wrote:
In addition, tha
make[1]: *** [Makefile:406: all-recursive] Error 1
make[1]: Leaving directory '/home/robertapengelly/Desktop/UDOS'
make: *** [Makefile:326: all] Error 2
-Original Message-
From: Paul Edwards
Sent: Thursday, September 2, 2021 6:15 PM
To: Ulrich Weigand
Cc: gcc@gcc.gnu.org
Subjec
: 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
>> 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
.
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
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.
>
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
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
20:K:06=000C0001 8050327A
.&.:
18:03:13 R:0030:K:06=
BFN. Paul.
-Original Message-
From: Paul Edwards
Sent: Friday, October 1, 2021 8:01 AM
To: gcc@gcc.gnu.org
Cc: m...@suse.de
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
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
POO page 3-6.
>
> I dont see 32 bits anywhere in that process. Unless and until IBM changes
> the architecture definition to include 32 bits in address sizes, there is
> no need for a -m32 switch.
>
> Joe
>
> On Sat, Jan 28, 2023 at 12:51 PM Paul Edwards wrote:
>
>>
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
Oh - I switched to -2 to make debugging easier:
D:\devel\gcc\gcc>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:
&g
ntf("bbb piss4\n");
folded = fold (result);
if (folded == result)
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\g
(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 is doing Win64 ABI:
D:\devel\gcc\gcc>gcc-new -O2 -S foo.c
D:\devel\gcc\gcc>type foo.s
.file "foo.c"
.text
.p2align 2,,3
.globl foo
foo:
.LFB1:
movsbl -1(%rcx),%eax
ret
.LFE1:
D:\devel\gcc\gcc>
Thanks for your help.
BFN. Paul.
O
Paul.
On Wed, Mar 19, 2025 at 5:30 PM Paul Edwards wrote:
>
> 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/PDO
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
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
101 - 138 of 138 matches
Mail list logo
