itszor / gcc-6502 Goto Github PK

Hi!

While coding on a host machine (Linux in my case) you enter literals in the encoding of that host machine (UTF-8, Latin-1 or whatever). So the 'hello world!' in the hello program is a string literal encoded in that encoding. When displaying such a string on a c64, the encoding is wrong, since the c64 uses petscii as it's main character encoding (screen codes are somewhat different from it). So the string literals have to translated. cc65 has a pragma for character mappings, but it seems the 'official' gcc way to handle this would be to set the execution character set to petscii (-fexec-charset switch). gcc just uses the iconv call to convert character sets, and it seems that iconv is missing important character sets, like petscii ^^ . Maybe adding a module for this would be possible:

While reading

https://forums.suse.com/showthread.php?4698-iconv-and-custom-charactersets&s=92917d7df5c0ee23d6c886e7eb829c63

I found:

http://www.gnu.org/software/libc/manual/html_node/glibc-iconv-Implementation.html#glibc-iconv-Implementation

An intermediate hack would be a small C method to convert character mappings in the 6502 specific libs.

Steps to reproduce

extern char* ext_address;

void my_function() {
    ext_address += 256; // Crashes gcc (no crash with values != 256)
}

Compile with 6502-gcc crash_6502_gcc.c -S -Os -Wall -Wextra -Werror

Expected behavior

Creates crash_6502_gcc.s and return with return code 0

Actual behavior

$ 6502-gcc crash_6502_gcc.c -S -Os -Wall -Wextra -Werror
during RTL pass: devirt
crash_6502_gcc.c: In function 'my_function':
crash_6502_gcc.c:6:1: internal compiler error: in gen_reg_rtx, at emit-rtl.c:1155
 }
 ^
unrecognized DWARF version in .debug_info at 6
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

Return code is 1

Additional info

• Fails on -Os, -Og, -O1, -O2, -O3 optimizations levels. Does not fail on -O0.
• Fails exclusively with 256, not 255 nor 257
• Same error happens when ext_address is of type extern uint16_t instead of extern char* (and stdint.h is included)

I followed step by step instructions, but compilation failed:
make[3]: Leaving directory /root/work/repos/public/gcc-6502-bits/gcc-build/6502/libgcc' /root/work/repos/public/gcc-6502-bits/gcc-build/./gcc/xgcc -B/root/work/repos/public/gcc-6502-bits/gcc-build/./gcc/ -B/root/work/repos/public/gcc-6502-bits/prefix/6502/bin/ -B/root/work/repos/public/gcc-6502-bits/prefix/6502/lib/ -isystem /root/work/repos/public/gcc-6502-bits/prefix/6502/include -isystem /root/work/repos/public/gcc-6502-bits/prefix/6502/sys-include -g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../.././gcc -I../../../gcc-6502/libgcc -I../../../gcc-6502/libgcc/. -I../../../gcc-6502/libgcc/../gcc -I../../../gcc-6502/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _fixunssfsi.o -MT _fixunssfsi.o -MD -MP -MF _fixunssfsi.dep -DL_fixunssfsi -c ../../../gcc-6502/libgcc/libgcc2.c /tmp/ccWyFLg4.s(82): Error: Range error (-128 not in [0..255]) make[2]: *** [_fixunssfsi.o] Error 1 make[2]: Leaving directory/root/work/repos/public/gcc-6502-bits/gcc-build/6502/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/root/work/repos/public/gcc-6502-bits/gcc-build'
make: *** [all] Error 2

Awesome project! I'm the author of a couple of related things... jsbeeb (a 6502 machine, the bbc micro emulator https://bbc.godbolt.org/ ), and Compiler Explorer (https://gcc.godbolt.org). Would love to put this version of GCC on the latter site.

I already build a ton of compilers for CE, and wondered what steps you took to build this patched version. A quick and naive attempt (grab source, run ./contrib/download_prerequistes) and configure with a prefix...all looks good until:

g++ -c  -DIN_GCC_FRONTEND -g -DIN_GCC    -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -Icp -I../.././gcc -I../.././gcc/cp -I../.././gcc/../include -I../.././gcc/../libcpp/include -I/home/matthew/dev/gcc-6502/host-x86_64-unknown-linux-gnu/gmp -I/home/matthew/dev/gcc-6502/gmp -I/home/matthew/dev/gcc-6502/host-x86_64-unknown-linux-gnu/mpfr -I/home/matthew/dev/gcc-6502/mpfr -I/home/matthew/dev/gcc-6502/mpc/src  -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace -I/home/matthew/dev/gcc-6502/host-x86_64-unknown-linux-gnu/isl/include -I/home/matthew/dev/gcc-6502/isl/include  -o cp/friend.o -MT cp/friend.o -MMD -MP -MF cp/.deps/friend.TPo ../.././gcc/cp/friend.c
In file included from ../.././gcc/cp/except.c:1027:0:
cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’:
cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute
cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here
cfns.gperf: At global scope:
cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const char*, unsigned int)’ used but never defined

Before I head off patching things (which I do to build GCCs for the CE site: https://github.com/mattgodbolt/compiler-explorer-image/tree/master/gcc/build/patches - the cfns patch is proably the one ... am I doing something wrong?

Cheers!

First of all, fantastic work with this port. Now to the issue.

When I compile this:

#include <stdint.h>

volatile uint8_t x = 0;

int main()
{
    x = 1;
}

with 6502-gcc -O2 -S test.c -o-, the variable is in the BSS segment (correct):

        ; ...
        .segment "CODE"
        .export main
main:
; frame size 0, pretend size 0, outgoing size 0
        lda #$01
        sta x$
        lda #$00
        sta _r0
        sta _r1
        rts
        .export x$
        .segment "BSS"
x$:
.res 1,$00

If I compile it with 6502-gcc -O2 -S test.c -o- -fwhole-program, however, it's left in the CODE segment:

        ; ...
        .segment "CODE"
        .export main
main:
; frame size 0, pretend size 0, outgoing size 0
        lda #$01
        sta x$
        lda #$00
        sta _r0
        sta _r1
        rts
x$:
        .res 1

When I compile this:

#include <stdint.h>

static volatile uint8_t x = 0;

int main()
{
    x = 1;
}

with 6502-gcc -O2 -S test.c -o-, the same happens:

        ; ...
        .segment "CODE"
        .export main
main:
; frame size 0, pretend size 0, outgoing size 0
        lda #$01
        sta x$
        lda #$00
        sta _r0
        sta _r1
        rts
x$:
        .res 1

When I compile this:

#include <stdint.h>

int main()
{
    static volatile uint8_t x = 0;
    x = 1;
}

with 6502-gcc -O2 -S test.c -o-, again:

        ; ...
        .segment "CODE"
        .export main
main:
; frame size 0, pretend size 0, outgoing size 0
        lda #$01
        sta x$1365
        lda #$00
        sta _r0
        sta _r1
        rts
x$1365:
        .res 1

So it seems that happens to all variables with internal linkage. For some systems, that wouldn't be an issue, but for others the CODE segment resides in read-only memory.

I can manually fix that by using __attribute__((section("BSS"))) in every declaration, but I feel like that should be the default behavior.

PS: It seems x64 gcc 10.2 does that too.

Hi!

It seems the c64 Linker configuration lacks the start address in the executable, a basic line to start the generated code and the stack is under the kernal rom?

Claus @ forum64.de wrote a modified cfg File that seems to work better:

http://www.forum64.de/index.php?thread/66857-gcc-6502/&postID=1047882#post1047882

He also wrote a minimal stub for the load address and a basic line to start the code (just 1 sys command to call the machine code).