itszor / gcc-6502 Goto Github PK
View Code? Open in Web Editor NEWA port of GCC to the 6502 processor family.
License: GNU General Public License v2.0
A port of GCC to the 6502 processor family.
License: GNU General Public License v2.0
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
I found:
An intermediate hack would be a small C method to convert character mappings in the 6502 specific libs.
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
Creates crash_6502_gcc.s
and return with return code 0
$ 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
-Os
, -Og
, -O1
, -O2
, -O3
optimizations levels. Does not fail on -O0
.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).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.