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 schedule_block schdblock
#define schedule_insns schdinsns
(both functions previously appearing as SCHEDULE)
The rest of the infrastructure changes are going very
well, but not yet complete for the i386 EBCDIC Win32.
gcc-stage* in custom.zip at pdos.org has been updated
with the above change.
BFN. Paul.
On Wed, Mar 19, 2025 at 5:30 PM Paul Edwards <mutazi...@gmail.com> 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/PDOS and
> z/PDOS-generic), and the end result is that I have been
> able to compile the gcc 3.2.3 source code on z/PDOS-generic
> targeting i386 EBCDIC.
>
> Dave Pitts has already made the modifications suitable
> for gccmvs (i370) to run, but gccwin (i386) is giving this error:
>
> enter a command
> type test.c
> int main(void)
> {
> printf("hello, world\n");
> return 5;
> }
>
> enter a command
> gccwin -S -Os test.c
> about to call app at address 003F74B8
> test.c: In function `main':
> test.c:5: Internal compiler error in schedule_block, at <stdin>:1659
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> return from app is hex 1
>
> enter a command
>
>
> I don't have this issue on an ASCII machine, but it
> generates incorrect assembler (EBCDIC codes
> converted to ASCII) - a problem that can be bypassed
> by starting with EBCDIC source code (which I did,
> above). Even in steady state (working on EBCDIC
> mini-Windows-clone), I will need this problem solved.
>
> Switching off optimization works:
>
> enter a command
> gccwin -S -O0 test.c
> about to call app at address 003F74B8
> return from app is hex 0
>
> enter a command
> type test.s
> .file "test.c"
> .text
> LC0:
> .ascii "hello, world\25\0"
> .globl _main
> _main:
> pushl %ebp
> movl %esp, %ebp
> subl $8, %esp
> andl $-16, %esp
> movl $0, %eax
> subl %eax, %esp
> subl $12, %esp
> pushl $LC0
> call _printf
> addl $16, %esp
> movl $5, %eax
> leave
> ret
>
> enter a command
>
>
> The modified gcc 3.2.3 source code is in gcc-stage* in
> custom.zip at http://pdos.org
>
> The problem is almost certainly some issue arising from
> gcc source code making some ASCII assumption. That
> hasn't already been found and addressed by Dave Pitts.
>
> Any suggestions on where the problem may lie?
>
> (and yes, I realize that gcc 3.2.3 isn't officially supported -
> there are reasons I am still on this version - one being
> the i370 target which I have just used).
>
> Thanks. Paul.
