bebbo / gcc Goto Github PK
View Code? Open in Web Editor NEWThis project forked from gcc-mirror/gcc
Bebbo's gcc-6-branch for m68k-amigaos
License: GNU General Public License v2.0
gcc's Introduction
This directory contains the GNU Compiler Collection (GCC). The GNU Compiler Collection is free software. See the files whose names start with COPYING for copying permission. The manuals, and some of the runtime libraries, are under different terms; see the individual source files for details. The directory INSTALL contains copies of the installation information as HTML and plain text. The source of this information is gcc/doc/install.texi. The installation information includes details of what is included in the GCC sources and what files GCC installs. See the file gcc/doc/gcc.texi (together with other files that it includes) for usage and porting information. An online readable version of the manual is in the files gcc/doc/gcc.info*. See http://gcc.gnu.org/bugs/ for how to report bugs usefully. Copyright years on GCC source files may be listed using range notation, e.g., 1987-2012, indicating that every year in the range, inclusive, is a copyrightable year that could otherwise be listed individually.
gcc's People
Contributors
Stargazers
Watchers
Forkers
alpine9000 chris-y githubaf mbeijer cnvogelg erikarn erique neocdtv apolloteam-dev wdrijver sacredbananagcc's Issues
Profiling: functions sometimes incorrectly state 0%, depending on code-size?
I continued testing and eventually I seem to have found an example for my permanent 0% complaints ;-)
Please try the attached script.
It creates 3 C-Files with long functions (containing many identical lines just to create code) and a busy loop. The code was executed on WinUAE, A1200 Cycle-exact or match A500/A1200 speed, no JIT
All 3 functions have the same length and duration and will be called once from main. So they should consume 33.3% of time each.
with 100 identical lines all is perfect
If I increase the code size suddenly I see 2x50% and 1x 0% instead.
with 700 identical C-Lines
If I increase the code size further I can see 1x 100% and 2x 0%.
with 1400 identical C-lines
Or does the compiler fool me again?
clib2 crashing in sprintf
My attempt to get ADoom running with the gcc6 toolchain now got stuck in a runtime error that I tracked down to apparently sprintf crashing:
Repro:
Compile & execute the following:
m68k-amigaos-gcc -mcrt=clib2 -fbaserel -m68030 -m68881 -Os -Wall -fomit-frame-pointer -fomit-frame-pointer -Wimplicit -Wno-strict-prototypes -Wno-int-conversion -o hello-stdio.clib2 hello-stdio.c
with
#include <stdio.h>
#include <string.h>
int VERSION = 110;
int main()
{
int p;
char file[256];
char title[128];
printf ("success 9!\n");
sprintf (title,
" "
"The Ultimate DOOM Startup v%i.%i"
" ",
VERSION/100,VERSION%100);
printf ("success 10!\n");
printf ("%s\n",title);
return 0;
}
The executable will either get stuck in sprintf and crash eventually or crash pretty much immediately.
Possible integer remainder bug in GCC 68k backend
The official Amiga 68k Netsurf appears to have a corner case bug when using '%' (remainder). Chris Young is using the bebbo 68k compiler install with all -fbbb optimization options turned off for now. The problematic code comes from http://git.netsurf-browser.org/netsurf.git/tree/utils/hashtable.c in the function hash_get(). The following C line appear to be the problem.
c = h % ht->nchains;
The assembler generated for the 68020 seems to be missing a remainder.
...
move.b d2,d1
extb.l d1
eor.l d0,d1
move.b (a0),d2
bne.s backward
move.l a0,d2
sub.l a2,a2
move.l d1,d1 ; effectively a NOP which a compiler should never generate
divu.l (a1),d1 ; divu.l is a division giving quotient with no remainder but "c = h % ht->nchains;" C source calls for a remainder
move.l (4,a1),a0
move.l (a0,d1.l*4),a3 ; <- hit is read from here with wrong calculated address for the for loop array
tst.l a3
beq.s forward
...
It looks like the compiler tried to generate a divul.l (a1),d1:d1 instruction which gives a remainder and quotient but this is a special case of the instruction (Dr=Dq) which becomes a divu.l (a1),d1. It appears the problem is a corner case as other tests with '%' produced correct code. Compiling Netsurf for the 68000 which uses the Amiga utility.library fixes the problem of missing text in Netsurf. It would be appreciated if the GCC 68k backend code was reviewed for problems with '%', especially when a divul.l should be generated and this instruction's registers could conflict (like Dr=Dq). Thank you.
Perfomance regression (vs gcc-3.4.0)
Use this to compile:
m68k-amigaos-gcc -Wall -O3 -D_NJ_EXAMPLE_PROGRAM -noixemul -o nanojpegb nanojpeg.c
(nanojpega is from gcc-3.4.0)
run it like:
nanojpegb SusannaHoffsAustralia2008.jpg b.ppm
I get (emulated a1200)
gcc-3.4.0 - 34.58 secs
gcc6 - 38.28 secs
gcc6 (with -fbbb=-) 38.64 secs
(original c source, untouched from here: http://svn.emphy.de/nanojpeg/trunk/nanojpeg/nanojpeg.c )
PS: I used 'csh' shell to get the timings
-O0 turns inline functions into missing symbols
Compiling the following code with -O0 will yield
test_fixed.o(.text+0x38): undefined reference to `testFunction'
collect2: error: ld returned 1 exit status
Makefile:226: recipe for target 'test_fixed' failed
make: *** [test_fixed] Error 1
Compiling with optimizations turned on successfully links the code.
#include <stdio.h>
inline void testFunction(void)
{
printf("Inlined!\n");
}
int main(void)
{
testFunction();
}
resident programs crashes
The compiled program just crashes. Did I do anything wrong or is resident code broken?
/*
~/opt/m68k-amigaos_06Dec18/bin/m68k-amigaos-gcc test.c -o test -resident -O2 -Wl,-Map=test.map,--trace -noixemul -s
*/
#include <stdio.h>
int main(void)
{
printf("Hello World\n");
return 0;
}
__saveds should save/restore a4
In ADoom, there's an input handler function, amiga_video.c video_inputhandler().
This function is a callback that gets called from the OS at an unspecified time.
Since a4 might be in any state at that time, we need to restore the base-pointer into a4, thus qualify the function with __saveds.
The bug is, though, that the function prologue and exit are supposed to save and restore the previous a4. But they don't:
9979 3bac 2F43 0044 _video_inputhandler:
9980 .stabd 46,0,0
9981 .stabd 68,0,1645
9982 3bb0 0802 0003 .LFBB16:
9983 3bb4 6700 05FC lea (-16,sp),sp
9984 fmovem #3,-(sp)
9985 movem.l a6/a5/a3/a2/a1/a0/d2/d1/d0,-(sp) <<<<<<<<<<<< needs to save a4
9986 3bb8 76FF #APP
9987 3bba 2F43 0048 | 1644 "amiga_video.c" 1
9988 lea ___a4_init,a4
9989 #NO_APP
9990 3bbe 0802 001C move.l a0,a2
9991 3bc2 6600 04BC .stabd 68,0,1649
9992 3bc6 45F9 0000 move.l a0,d0
9992 0000
9993 jeq .L738
9994 3bcc 41EF 003C .stabd 68,0,1658
9995 3bd0 4E92 lea _xlate_key,a0
9996 move.l a0,d2
9997 3bd2 2942 0020 .stabd 68,0,1659
9998 lea (60,sp),a6
9999 lea _D_PostEvent,a5
10000 .stabd 68,0,1662
10001 3bd6 4A6C 03B6 lea _mouseevent.10261:W(a4),a3
10002 3bda 6600 01EC .L736:
10003 3bde 4A6C 03B4 .stabd 68,0,1650
10004 3be2 6700 0106 move.b 4(a2),d0
10005 cmp.b #1,d0
10006 jeq .L742
10007 3be6 4EB9 0000 .stabd 68,0,1661
10007 0000
10008 3bec 2400 tst.w _video_is_using_mouse:W(a4)
10009 jeq .L724
10010 cmp.b #2,d0
10011 3bee 222C 03B8 jeq .L743
10012 3bf2 B282 .L724:
10013 3bf4 6700 00F4 .stabd 68,0,1689
10014 move.l (a2),a2
10015 3bf8 7003 .stabd 68,0,1649
10016 3bfa 2F40 003C move.l a2,d0
10017 jne .L736
10018 3bfe 42AF 0048 .L738:
10019 3c02 42AF 0044 .stabd 68,0,1692
10020 clr.l d0
10021 3c06 0802 0004 movem.l (sp)+,d0/d1/d2/a0/a1/a2/a3/a5/a6 >>>>>>>>>> needs to restore a4
10022 3c0a 6600 050A fmovem (sp)+,#192
10023 lea (16,sp),sp
10024 3c0e 42AF 0040 rte
(Note that the function itself is attributes with __interrupt at the moment... I don't know if that's appropriate)
Issues with -nostartfiles
(this is more a help request to understand whats going on than a bug report)
Attempting to compile DirectoryOpus 5.92 from https://github.com/mheyer32/dopus5allamigas
I got quite far.
Download, go to 'source', then type
make os3 -j8
and it'll build everything
make os3 release debug=no
(builds the release package, but thats not needed here)
The only thing that is causing trouble is the ftp.module library. It is a library that provides its own startup code, thus is not linked via '-ramiga-lib'. It uses -nostartfiles and uses functionality from libnix, though. Unfortunately, this leads to the following linker issues and I don't have enough link-fu to solve this.
The makefile responsible here can be found under
source/Modules/ftp/makefile.os3
================ ftp_module ================
m68k-amigaos-gcc init/libinit.o init/amiga.o ftp_main.o ftp_lister.o ftp_lister_list.o ftp_lister_xfer.o ftp_lister_connect.o ftp.o ftp_arexx.o ftp_util.o ftp_recursive.o ftp_addressbook.o ftp_addrsupp.o ftp_addrformat.o ftp_protect.o ftp_module.o ftp_data.o ftp_strings.o init/68k_asm_a4_a5.o -m68020-60 -D__amigaos3__ -DCOMPDATE=26.10.2018 -D__NO_NET_API -nostartfiles -noixemul -lamiga -ldebug -o ../../bin.os3/ftp.module
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(__stdio.o):__stdio.o:(.text+0x4): multiple definition of `__initstdfio'; /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(__stdio.o):__stdio.o:(.text+0x4): first defined here
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(__stdio.o):__stdio.o:(.data+0x0): multiple definition of `__sF'; /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(__stdio.o):__stdio.o:(.data+0x0): first defined here
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(malloc.o):malloc.o:(.text+0x0): multiple definition of `malloc'; /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(malloc.o):malloc.o:(.text+0x0): first defined here
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(malloc.o):malloc.o:(.text+0xcc): multiple definition of `__initmalloc'; /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(malloc.o):malloc.o:(.text+0xcc): first defined here
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(malloc.o):malloc.o:(.text+0x108): multiple definition of `__exitmalloc'; /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/libm020/libnix.a(malloc.o):malloc.o:(.text+0x108): first defined here
collect2: error: ld returned 1 exit status
makefile.os3:37: recipe for target '../../bin.os3/ftp.module' failed
make[2]: *** [../../bin.os3/ftp.module] Error 1
makefile:127: recipe for target 'ftp' failed
make[1]: *** [ftp] Error 2
make[1]: Leaving directory '/home/matze/dopus5allamigas/source/Modules'
makefile:138: recipe for target 'modules' failed
make: *** [modules] Error 2
m68k-amigaos-objdump does not recognize extb.l
extb.l d0 seems to come out as lea d0,a4
64bit assignment of 0 seems broken
DirectoryOpus supports 64bit file sizes throughout the system.
I was wondering, though, why directories show up in the UI with a weird size assigned - they should show up as 0 (or with no size at all)
I think I tracked it down to this piece of code in here:
https://github.com/mheyer32/dopus5allamigas/blob/master/source/Program/function_files.c#L871
// Set entry type for directory
else
{
handle->recurse_entry->type=ENTRY_DIRECTORY;
handle->recurse_entry->size=0;
}
The resulting assembly
handle->recurse_entry->type=ENTRY_DIRECTORY;
4c396: 206a 0498 movea.l 1176(a2),a0
4c39a: 317c 0001 0010 move.w #1,16(a0)
handle->recurse_entry->size=0;
4c3a0: 4280 clr.l d0
4c3a2: 2140 0014 move.l d0,20(a0)
4c3a6: 2141 0018 move.l d1,24(a0)
Looks wrong. It should have been
clr.l d0
move.l d0,20(a0)
move.l d0,24(a0)
The size is using type 'UQUAD' defined on OS3 as:
#elif defined(__amigaos3__)
typedef unsigned long long UQUAD;
typedef signed long long QUAD;
#endif
matze@ubuntu-VirtualBox:~/dopus5allamigas/source/Program$ make -f makefile.os3 function_files.o
>>>>>Compiling function_files.c
Using built-in specs.
COLLECT_GCC=m68k-amigaos-gcc
Target: m68k-amigaos
Configured with: /home/matze/amigatoolchain/amiga-gcc/projects/gcc/configure --prefix=/home/matze/amigatoolchain/amiga-gcc-out --target=m68k-amigaos --enable-languages=c,c++,objc --enable-version-specific-runtime-libs --disable-libssp --disable-nls --with-headers=/home/matze/amigatoolchain/amiga-gcc/projects/newlib-cygwin/newlib/libc/sys/amigaos/include/ --disable-shared --with-stage1-ldflags='-dynamic-libgcc -dynamic-libstdc++' --with-boot-ldflags='-dynamic-libgcc -dynamic-libstdc++'
Thread model: single
gcc version 6.4.1b 20181031-212527 (GCC)
COLLECT_GCC_OPTIONS='-c' '-m68020-60' '-D' '__amigaos3__' '-D' 'USE_64BIT' '-D' '__USE_SYSBASE' '-D' '__NO_NET_API' '-D' 'COMPDATE=' '-D' 'DEBUG' '-g' '-ggdb' '-Og' '-noixemul' '-E' '-v' '-I' './../' '-I' 'init/../' '-I' '/home/matze/dopus5allamigas/source' '-I' '/home/matze/dopus5allamigas/source/Include' '-Wall' '-Wno-pointer-sign' '-Wno-attributes' '-Wno-int-conversion' '-o' 'function_files.o' '-B' '/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/'
/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/6.4.1b/cc1 -E -quiet -v -I ./../ -I init/../ -I /home/matze/dopus5allamigas/source -I /home/matze/dopus5allamigas/source/Include -iprefix /home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/ -Dmc68020 -D__mc68020__ -D__mc68020 -isystem /home/matze/amigatoolchain/amiga-gcc-out/include -isystem /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/include -Dlibnix -D__libnix__ -D__libnix -D __amigaos3__ -D USE_64BIT -D __USE_SYSBASE -D __NO_NET_API -D COMPDATE= -D DEBUG function_files.c -o function_files.o -m68020-60 -Wall -Wno-pointer-sign -Wno-attributes -Wno-int-conversion -g -ggdb -fworking-directory -Og
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/lib/gcc/m68k-amigaos/6.4.1b/include"
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/m68k-amigaos/ndk-include"
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/m68k-amigaos/sys-include"
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/m68k-amigaos/include"
ignoring nonexistent directory "init/../"
ignoring duplicate directory "/home/matze/dopus5allamigas/source"
#include "..." search starts here:
#include <...> search starts here:
./../
/home/matze/dopus5allamigas/source/Include
/home/matze/amigatoolchain/amiga-gcc-out/include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/include
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/ndk-include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/sys-include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/include
End of search list.
COMPILER_PATH=/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/:/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/6.4.1b/:/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/:/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/
LIBRARY_PATH=/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/:/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/:/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/:/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/lib/
COLLECT_GCC_OPTIONS='-c' '-m68020-60' '-D' '__amigaos3__' '-D' 'USE_64BIT' '-D' '__USE_SYSBASE' '-D' '__NO_NET_API' '-D' 'COMPDATE=' '-D' 'DEBUG' '-g' '-ggdb' '-Og' '-noixemul' '-E' '-v' '-I' './../' '-I' 'init/../' '-I' '/home/matze/dopus5allamigas/source' '-I' '/home/matze/dopus5allamigas/source/Include' '-Wall' '-Wno-pointer-sign' '-Wno-attributes' '-Wno-int-conversion' '-o' 'function_files.o' '-B' '/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/'
Uses an AREG to hold a float or double temporarily
Don't have a reduced test case yet, but here is an indication:
I got a big loop that uses more than 8 floats and more than 16 integers / pointers, so there is register pressure to move things around.
One of the thing the loop does is update a float in memory in each iteration of the loop -- in this case it decided to do this sort of sequence:
move.l _fw0,a4
...
...
move.l a4,-(sp)
fsmove.s (sp)+,fp0
fsadd.x fp4,fp0
fmove.s fp0,112(sp)
which is really nuts, as doing this on each iteration:
fsmove.s _fw0,fp0
fsadd.x fp4,fp0
fsmove.s fp0,_fw0
would use less memory access in total.
I'll try and post a short reproducible loop later, wondering if there are any tips for that.
[-fbaserel] error: unable to find a register to spill in class 'A0_REGS'
Encountered while trying to compile a file with -fbaserel.
It compiles without.
This is not super urgent - I don't even know if we can compile this library this way in general,
but I thought internal compiler errors of this sort are not to be expected in any case.
>>>>>Compiling ftp_addressbook.c
Using built-in specs.
COLLECT_GCC=m68k-amigaos-gcc
Target: m68k-amigaos
Configured with: /home/matze/amigatoolchain/amiga-gcc/projects/gcc/configure --prefix=/home/matze/amigatoolchain/amiga-gcc-out --target=m68k-amigaos --enable-languages=c,c++,objc --enable-version-specific-runtime-libs --disable-libssp --disable-nls --with-headers=/home/matze/amigatoolchain/amiga-gcc/projects/newlib-cygwin/newlib/libc/sys/amigaos/include/ --disable-shared --with-stage1-ldflags='-dynamic-libgcc -dynamic-libstdc++' --with-boot-ldflags='-dynamic-libgcc -dynamic-libstdc++'
Thread model: single
gcc version 6.4.1b 20181021-224453 (GCC)
COLLECT_GCC_OPTIONS='-c' '-mcpu=68020' '-fbaserel' '-D' '__amigaos3__' '-D' 'COMPDATE=23.10.2018' '-D' '__NO_NET_API' '-D' 'DEBUG' '-O2' '-noixemul' '-v' '-I' '../../Include' '-I' './' '-I' '../../' '-I' '/usr/local/amiga/m68k-amigaos/netinclude' '-Wall' '-o' 'ftp_addressbook.o' '-B' '/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/lib/'
/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/6.4.1b/cc1 -quiet -v -I ../../Include -I ./ -I ../../ -I /usr/local/amiga/m68k-amigaos/netinclude -imultilib libm020/libb -iprefix /home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/ -isystem /home/matze/amigatoolchain/amiga-gcc-out/include -isystem /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/include -Dlibnix -D__libnix__ -D__libnix -D __amigaos3__ -D COMPDATE=23.10.2018 -D __NO_NET_API -D DEBUG ftp_addressbook.c -quiet -dumpbase ftp_addressbook.c -mcpu=68020 -auxbase-strip ftp_addressbook.o -O2 -Wall -version -fbaserel -o /tmp/ccdFjvlx.s
GNU C11 (GCC) version 6.4.1b 20181021-224453 (m68k-amigaos)
``` compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/lib/gcc/m68k-amigaos/6.4.1b/include"
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/m68k-amigaos/ndk-include"
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/m68k-amigaos/sys-include"
ignoring nonexistent directory "/home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/m68k-amigaos/include"
ignoring nonexistent directory "/usr/local/amiga/m68k-amigaos/netinclude"
#include "..." search starts here:
#include <...> search starts here:
../../Include
./
../../
/home/matze/amigatoolchain/amiga-gcc-out/include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/include
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/ndk-include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/sys-include
/home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/include
End of search list.
GNU C11 (GCC) version 6.4.1b 20181021-224453 (m68k-amigaos)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 30fe58c468361392395558fa369ff8a9
ftp_addressbook.c:4239:1: error: unable to find a register to spill in class 'A0_REGS'
}
^
ftp_addressbook.c:4239:1: error: this is the insn:
(insn 1370 1369 1371 175 (set (reg/v:SI 3 d3 [ _n8 ])
(sign_extend:SI (mem:HI (plus:SI (reg/f:SI 4 d4 [orig:576 _GetDragInfo_re2.222_1059 ] [576])
(const_int 10 [0xa])) [14 _GetDragInfo_re2.222_1059->height+0 S2 A16]))) ftp_addressbook.c:269 79 {*68k_extendhisi2}
(nil))
ftp_addressbook.c:4239: confused by earlier errors, bailing out
makefile.os3:42: recipe for target 'ftp_addressbook.o' failed
make: *** [ftp_addressbook.o] Error 1
pragma GCC push_options & pragma GCC pop_options do not work anymore (13.Jan)
I am using push_options and pop_options to set the optimization level of single functions in order to find functions which get wrongly compiled in case of -O2.
That worked fine in GCC from 29.Dec.
( I found three functions in one source file which needed -O0)
Push and pop seem no longer to work in toolchain from 13.Jan
call gcc with -O2
// source.cpp
#pragma GCC push_options
#pragma GCC optimize ("-O0")
#pragma GCC pop_options
// all following code seems to be compiled with -O0, although "pop_options" should have restored the -O2 setting from the commandline
Optimizer questions
Some general questions:
- I saw the compiler generate a mulu.l instruction
for
void putPixel320(int16 x, int16 y, byte drawMask, byte color, byte priority, byte control) const {
// Set pixel for visual, priority and control map directly, those are not upscaled
const uint offset = y * 320 + x;
if (drawMask & GFX_SCREEN_MASK_VISUAL) {
_displayScreen[offset] = color;
}
if (drawMask & GFX_SCREEN_MASK_PRIORITY) {
_priorityScreen[offset] = priority;
}
if (drawMask & GFX_SCREEN_MASK_CONTROL) {
_controlScreen[offset] = control;
}
}
With -Ofast and -m68020-60
I don't know if mulu is that fast on 68030, but shouldn't it be faster to do two shifts instead:
void REGPARM putPixel320(int16 x, int16 y, byte drawMask, byte color, byte priority, byte control) const {
// Set pixel for visual, priority and control map directly, those are not upscaled
const uint offset = ((uint)y << 8) + ((uint)y << 6) + x;
...
}
I was somehow expecting the optimizer to do this kind of optimization on its own.
-
byte and short stack arguments are both using move.l to be push/popped onto the stack... isn't that suboptimal ?
-
If I use uint16 in above example, the compiler will extend x and y no longer using ext.l, but instead
and.l 0xFFFF, d0
and.l 0xFFFF, d1
instead (which is somehow expected as ext.l does signed-extend).
But is that the most effective way? I would have expected the 0xFFFF to be placed into some temp. register instead of using it twice as immediate argument. Or maybe some other more efficient method even.
It seems the need to use and.l is a side effect of passing x and y as longwords on the stack, so x an y are popped off the stack with potentially garbage in the upper 16 bits.
This is all C++ code and the functions mentioned above are member functions.
Profiling: everything starts with exit()
Please see the tiny example. The generated profiling tree starts with exit(). Is that normal? I would have expected main() to be on top...
compiler crash when compiling ScummVM with optimizations on
I'm attempting to compile ScummVM for Amiga OS3 ( https://github.com/mntmn/scummvm-amigaos3 ), but it fails when one attempts to compile with -O3 or -Ofast
It must have something to do with the -m68030 compiler switch. Take it out and it compiles just fine.
matze@ubuntu-VirtualBox:~/scummvm-amigaos3$ make common/rational.o fatal: No names found, cannot describe anything. C++ common/rational.o Using built-in specs. COLLECT_GCC=m68k-amigaos-g++ Target: m68k-amigaos Configured with: /home/matze/amigatoolchain/amiga-gcc/projects/gcc/configure --prefix=/home/matze/amigatoolchain/amiga-gcc-out --target=m68k-amigaos --enable-languages=c,c++,objc --enable-version-specific-runtime-libs --disable-libssp --disable-nls --with-headers=/home/matze/amigatoolchain/amiga-gcc/projects/newlib-cygwin/newlib/libc/sys/amigaos/include/ --disable-shared : (reconfigured) /home/matze/amigatoolchain/amiga-gcc/projects/gcc/configure --prefix=/home/matze/amigatoolchain/amiga-gcc-out --target=m68k-amigaos --enable-languages=c,c++,objc --enable-version-specific-runtime-libs --disable-libssp --disable-nls --with-headers=/home/matze/amigatoolchain/amiga-gcc/projects/newlib-cygwin/newlib/libc/sys/amigaos/include/ --disable-shared Thread model: single gcc version 6.4.1b 20180729-214001 (GCC) COLLECT_GCC_OPTIONS='-MMD' '-MF' 'common/.deps/rational.d' '-MQ' 'common/rational.o' '-MP' '-Wall' '-v' '-Wextra' '-Wno-unused-parameter' '-Wno-empty-body' '-fno-access-control' '-Ofast' '-Wuninitialized' '-noixemul' '-mcpu=68030' '-m68881' '-fomit-frame-pointer' '-Wno-long-long' '-Wno-multichar' '-Wno-unknown-pragmas' '-Wno-reorder' '-Wpointer-arith' '-Wcast-qual' '-Wshadow' '-Wnon-virtual-dtor' '-Wwrite-strings' '-fno-exceptions' '-fcheck-new' '-D' 'HAVE_CONFIG_H' '-D' 'RELEASE_BUILD' '-D' 'FORBIDDEN_SYMBOL_ALLOW_ALL' '-D' 'DATA_PATH="/usr/local/share/scummvm"' '-D' 'PLUGIN_DIRECTORY="/usr/local/lib/scummvm"' '-D' 'ENABLE_SCUMM=STATIC_PLUGIN' '-D' 'ENABLE_SCUMM_7_8' '-D' 'ENABLE_AGI=STATIC_PLUGIN' '-D' 'ENABLE_AGOS=STATIC_PLUGIN' '-D' 'ENABLE_DREAMWEB=STATIC_PLUGIN' '-D' 'ENABLE_KYRA=STATIC_PLUGIN' '-D' 'ENABLE_LURE=STATIC_PLUGIN' '-D' 'ENABLE_QUEEN=STATIC_PLUGIN' '-D' 'ENABLE_SCI=STATIC_PLUGIN' '-D' 'ENABLE_SCI32' '-D' 'ENABLE_SKY=STATIC_PLUGIN' '-D' 'ENABLE_SWORD1=STATIC_PLUGIN' '-D' 'ENABLE_TINSEL=STATIC_PLUGIN' '-I' '.' '-I' '.' '-I' './engines' '-c' '-o' 'common/rational.o' /home/matze/amigatoolchain/amiga-gcc-out/libexec/gcc/m68k-amigaos/6.4.1b/cc1plus -quiet -v -I . -I . -I ./engines -MMD common/rational.d -MF common/.deps/rational.d -MP -MQ common/rational.o -D__HAVE_68881__ -isystem /home/matze/amigatoolchain/amiga-gcc-out/include -isystem /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/include -Dlibnix -D__libnix__ -D__libnix -D HAVE_CONFIG_H -D RELEASE_BUILD -D FORBIDDEN_SYMBOL_ALLOW_ALL -D DATA_PATH="/usr/local/share/scummvm" -D PLUGIN_DIRECTORY="/usr/local/lib/scummvm" -D ENABLE_SCUMM=STATIC_PLUGIN -D ENABLE_SCUMM_7_8 -D ENABLE_AGI=STATIC_PLUGIN -D ENABLE_AGOS=STATIC_PLUGIN -D ENABLE_DREAMWEB=STATIC_PLUGIN -D ENABLE_KYRA=STATIC_PLUGIN -D ENABLE_LURE=STATIC_PLUGIN -D ENABLE_QUEEN=STATIC_PLUGIN -D ENABLE_SCI=STATIC_PLUGIN -D ENABLE_SCI32 -D ENABLE_SKY=STATIC_PLUGIN -D ENABLE_SWORD1=STATIC_PLUGIN -D ENABLE_TINSEL=STATIC_PLUGIN common/rational.cpp -quiet -dumpbase rational.cpp -mcpu=68030 -m68881 -auxbase-strip common/rational.o -Ofast -Wall -Wextra -Wno-unused-parameter -Wno-empty-body -Wuninitialized -Wno-long-long -Wno-multichar -Wno-unknown-pragmas -Wno-reorder -Wpointer-arith -Wcast-qual -Wshadow -Wnon-virtual-dtor -Wwrite-strings -version -fno-access-control -fomit-frame-pointer -fno-exceptions -fcheck-new -o /tmp/ccLq5pA4.s GNU C++14 (GCC) version 6.4.1b 20180729-214001 (m68k-amigaos) compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring duplicate directory "." #include "..." search starts here: #include <...> search starts here: . ./engines /home/matze/amigatoolchain/amiga-gcc-out/include /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/libnix/include /home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/include/c++ /home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/include/c++/m68k-amigaos /home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/include/c++/backward /home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/include /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/ndk-include /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/sys-include /home/matze/amigatoolchain/amiga-gcc-out/m68k-amigaos/include End of search list. GNU C++14 (GCC) version 6.4.1b 20180729-214001 (m68k-amigaos) compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version 3.1.2-p11, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: b2ddec978943eef22adb0f07904623ff common/rational.cpp: In member function 'int Common::Rational::toInt() const': common/rational.cpp:261:1: error: unrecognizable insn: } ^ (insn 22 11 12 (parallel [ (set (reg/i:SI 0 d0) (div:SI (reg/i:SI 0 d0) (mem:SI (reg/f:SI 8 a0 [orig:34 this ] [34]) [1 this_2(D)->_denom+0 S4 A16]))) (set (reg:SI 1 d1 [37]) (mod:SI (reg/i:SI 0 d0) (mem:SI (plus:SI (reg/f:SI 8 a0 [orig:34 this ] [34]) (const_int 4 [0x4])) [1 this_2(D)->_denom+0 S4 A16]))) ]) -1 (nil)) common/rational.cpp:261:1: internal compiler error: in extract_insn, at recog.c:2293
-flto leads to internal compiler error: Segmentation fault
I tried compiling+linking githubaf/SAM with the new option -flto with the toolchain from Jan 14th. The linking stage chrashed.
Tested on Ubuntu 16.04.5 LTS
/home/developer/opt/m68k-amigaos_14Jan19/bin/m68k-amigaos-gcc -o sam reciter.o sam.o debug.o endian.o sdlwrapper.o portaudio_audev.o render.o render000.o render020.o main.o portaudio_ahidev.o portaudio.o subtask_support.o amiga_version.o stopwatch.o -g -noixemul -m68000 -Wl,-Map=sam.map,--trace -ldebug -resident -flto
src/render2.c:38:22: warning: type of 'sampledConsonantFlags' does not match original declaration [-Wlto-type-mismatch]
extern unsigned char sampledConsonantFlags[256];
^
src/RenderTabs.h:88:15: note: array types have different bounds
unsigned char sampledConsonantFlags[] =
^
src/RenderTabs.h:88:15: note: 'sampledConsonantFlags' was previously declared here
src/amiga/portaudio/portaudio_ahidev.c: In function 'Pa_CloseStream_ahidev':
src/amiga/portaudio/portaudio_ahidev.c:785:1: internal compiler error: Segmentation fault
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
lto-wrapper: fatal error: /home/developer/opt/m68k-amigaos_14Jan19/bin/m68k-amigaos-gcc returned 1 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
Makefile.amiga:52: recipe for target 'sam' failed
make: *** [sam] Error 1
O[x] causing internal compiler error
CFLAGS = -O3 -fbaserel32 -mcrt=clib2 -m68030 -m68881 -Wimplicit -Wno-strict-prototypes -Wno-int-conversion -I $(SDK_ROOT)/ndk/include
CFLAGS += -DCPU=68030 -DNOICONS -DSTRINGMERGE -DABSFUNCPOINTER -DDATA=NEAR -DVERBOSE \
-DPARM=REG -D__BIG_ENDIAN__ -DNORMALUNIX -DIGNORE=79 \
-Dstrcasecmp=stricmp -Dstrncasecmp=strnicmp -Diabs=abs\
-DMATH=IEEE
amiga_system.c: In function ‘I_Init’:
amiga_system.c:43:1: error: unrecognizable insn:
}
^
(insn 107 67 68 (parallel [
(set (reg/f:SI 15 sp)
(plus:SI (reg/f:SI 15 sp)
(const_int 8 [0x8])))
(set (reg:SI 2 d2)
(mem/c:SI (reg:SI 15 sp) [12 S4 A16]))
(set (reg:SI 10 a2)
(mem/c:SI (plus:SI (reg:SI 15 sp)
(const_int 4 [0x4])) [12 S4 A16]))
(set (reg:SI 14 a6)
(mem/c:SI (plus:SI (reg:SI 15 sp)
(const_int 8 [0x8])) [12 S4 A16]))
]) -1
(nil))
amiga_system.c:43:1: internal compiler error: in extract_insn, at recog.c:2287
0xc5116b _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:108
0xc511ac _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:116
0xc013fa extract_insn(rtx_insn*)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2287
0xc010ce extract_insn_cached(rtx_insn*)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/recog.c:2178
0x953bd9 cleanup_subreg_operands(rtx_insn*)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:3106
0x953594 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2907
0x951988 final(rtx_insn*, _IO_FILE*, int)
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2045
0x956492 rest_of_handle_final
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4448
0x95668e execute
/home/matze/amigatoolchain/gcc-6.2/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4523
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
Makefile:202: recipe for target 'amiga_system.o' failed
make: *** [amiga_system.o] Error 1
Guru with -fbbb=z
get https://www.lua.org/ftp/lua-5.3.5.tar.gz
tar xvf the thing.
cd lua-5.3.5/src
make generic CC=m68k-amigaos-gcc CFLAGS="-O3 -fbbb=abcsefilmprz -fomit-frame-pointer" AR="m68k-amigaos-ar r" RANLIB=m68k-amigaos-ranlib LDFLAGS="-noixemul -s"
if you remove the 'z' it runs ok, with 'z' you get Guru 8000 0005
(A1200 3.1)
I tried updating the toolchain a few mins ago but libnix is breaking the build, so it's about a week's old (the toolchain)
make[3]: *** [extra/allocvec.o] Error 1
make[3]: Leaving directory '/home/alex/t/amiga-gcc/build/libnix/lib/nix13'
/home/alex/t/amiga-gcc/build/libnix/sources/Makefile:38: recipe for target 'nix13' failed
gprof: issues with C++ code?
I'm trying -pg with scummvm, but get weird results which I think are already present in the output of gprof.
What seems to happen is that the wrong functions get attributed in many places. For instance, i can see a function named 'undrawMouse' in the wrong place in the callgraph (being called by main() and using up high amounts of the time), but that is impossible.
ScummVM makes use of function pointers, virtual functions and templates. Is there a chance any of this is confusing the address->symbol resolve?
I made sure to use -fno-omit-frame-pointers and passed -pg and -g -ggdb to both, compiler and linker.
I used the same methodology on ADoom/DoomAttack and seem to get sensible results there.
It does not seem to matter if I use -O0 or use higher optimization levels.
If you need more data/files or instructions on how to reproduce with ScummVM, let me know.
-mregparm makes malloc() fail
Even the simplest program fails to allocate memory:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
void *ptr = malloc(0x400);
if (!ptr) {
printf("Allocation failed!\n");
}
}
In libnix malloc.c I can see:
https://github.com/bebbo/libnix/blob/master/sources/nix/stdlib/malloc.c
void __initmalloc(void)
{
...
}
void __exitmalloc(void)
{
...
}
ADD2EXIT(__exitmalloc,-50);
ADD2INIT(__initmalloc,-50);
Is it possible the effect that ADD2INIT/EXIT should have had is being ignored and thus, malloc just bails out?
Latest commit broke toolchain build (libgcc)
broke the libgcc build target:
libtool: compile: /home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/./gcc/xgcc -shared-libgcc -B/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/./gcc -nostdinc++ -L/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/src -L/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/src/.libs -L/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/libsupc++/.libs -B/home/matze/test4/m68k-amigaos/bin/ -B/home/matze/test4/m68k-amigaos/lib/ -isystem /home/matze/test4/m68k-amigaos/include -isystem /home/matze/test4/m68k-amigaos/ndk-include -isystem /home/matze/test4/m68k-amigaos/sys-include -I/home/matze/amigatoolchain/amiga-gcc/projects/gcc/libstdc++-v3/../libgcc -I/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/include/m68k-amigaos -I/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/include -I/home/matze/amigatoolchain/amiga-gcc/projects/gcc/libstdc++-v3/libsupc++ -std=gnu++11 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -frandom-seed=ctype_members.lo -Os -fomit-frame-pointer -c ctype_members.cc -o ctype_members.o
In file included from /home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/include/bits/locale_facets.h:2651:0,
from /home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/include/locale:40,
from /home/matze/amigatoolchain/amiga-gcc/projects/gcc/libstdc++-v3/src/c++11/locale-inst.cc:38,
from /home/matze/amigatoolchain/amiga-gcc/projects/gcc/libstdc++-v3/src/c++11/wlocale-inst.cc:35:
/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/include/bits/locale_facets.tcc: In member function '_InIter std::num_get<_CharT, _InIter>::do_get(std::num_get<_CharT, _InIter>::iter_type, std::num_get<_CharT, _InIter>::iter_type, std::ios_base&, std::ios_base::iostate&, bool&) const [with _CharT = wchar_t; _InIter = std::istreambuf_iterator<wchar_t, std::char_traits<wchar_t> >]':
/home/matze/amigatoolchain/amiga-gcc/build-Linux/gcc/m68k-amigaos/libstdc++-v3/include/bits/locale_facets.tcc:686:5: internal compiler error: in validate_change_1, at recog.c:220
}
^
-O2 generates incorrect code
When turning on optimization -O2 some incorrect code is generated. In the provided source files 3 functions must be excluded fom comiplation with -O2
WaveCallback()
Wavegen()
PlaySilence()
All three functions contain code that accesses a global pointer,
for instance PlaySilence()
*out_ptr++ = value;
*out_ptr++ = value >> 8;
It seems that some values are lost. (The generated wave-File in my examlpe contains less samples than expected and sound high pitched and to fast (Mickey Mouse voise)
The compiled file works niceley when compiled with Krystof's gcc 2.95.3.
compile with
/home/developer/opt/m68k-amigaos_gcc6/bin/m68k-amigaos-gcc -g -O2 -c -m68000 -Wall wavegen_O2_O0_preproc.cpp -Wa,-adhln
and
/home/developer/opt/m68k-amigaos_gcc6/bin/m68k-amigaos-gcc -g -O2 -c -m68000 -Wall wavegen_O2_preproc.cpp -Wa,-adhln
Weird interaction of register parameters with stack management
GCC tries to eliminate RTS (via early stack cleanup and JMP) when a function call is the last thing a function does. This does not work well with function calls that take register parameters as the early stack cleanup overwrites the registers needed for the function call.
(compiled with
CFLAGS = -mcrt=clib2 -v -fbbb=Vabcefimprs -Ofast -fbaserel -fstrength-reduce -m68030 -m68881 -fomit-frame-pointer -Werror -Wimplicit -Wstrict-prototypes )
extern void I_MarkRect(REG(d0, int left), REG(d1, int top), REG(d2, int width), REG(d3, int height));
void V_DrawBlock(int x, int y, int scrn, int width, int height, byte* src)
{
byte* dest;
int height0;
DEBUGPRINT(("V_DrawBlock %d, %d , %d, %d, %d, %p\n", x, y, scrn, width, height, src));
#ifdef RANGECHECK
if (x < 0 || x + width > SCREENWIDTH || y < 0 || y + height > SCREENHEIGHT || (unsigned)scrn > 4) {
I_Error("Bad V_DrawBlock");
}
#endif
height0 = height;
dest = screens[scrn] + y * SCREENWIDTH + x;
while (height--) {
memcpy(dest, src, width);
src += width;
dest += SCREENWIDTH;
}
DEBUGPRINT(("V_DrawBlock height0 %d\n", height0));
if (scrn == 0)
I_MarkRect(x, y, width, height0); // I see wrong values passed into this function
}
00034d10 <_V_DrawBlock>:
34d10: 598f subql #4,%sp
34d12: 48e7 3f36 moveml %d2-%d7/%a2-%a3/%a5-%a6,%sp@-
34d16: 2e2f 0030 movel %sp@(48),%d7
34d1a: 2f6f 0034 0028 movel %sp@(52),%sp@(40)
34d20: 2a6f 0038 moveal %sp@(56),%a5
34d24: 242f 003c movel %sp@(60),%d2
34d28: 262f 0040 movel %sp@(64),%d3
34d2c: 2a2f 0044 movel %sp@(68),%d5
34d30: 2f05 movel %d5,%sp@-
34d32: 2f03 movel %d3,%sp@-
34d34: 2f02 movel %d2,%sp@-
34d36: 2f0d movel %a5,%sp@-
34d38: 2f2f 0038 movel %sp@(56),%sp@-
34d3c: 2f07 movel %d7,%sp@-
34d3e: 4879 0003 4cc0 pea 34cc0 <_V_DrawPatchInDirectFlipped+0x214>
34d44: 47f9 0003 cc20 lea 3cc20 <_printf>,%a3
34d4a: 4e93 jsr %a3@
34d4c: 2079 0000 674c moveal 674c <___iob>,%a0
34d52: 2f28 0004 movel %a0@(4),%sp@-
34d56: 4df9 0003 d50c lea 3d50c <_fflush>,%a6
34d5c: 4e96 jsr %a6@
34d5e: 4fef 0020 lea %sp@(32),%sp
34d62: 4a87 tstl %d7
34d64: 6d24 blts 34d8a <_V_DrawBlock+0x7a>
34d66: 2839 0000 72b4 movel 72b4 <_SCREENWIDTH>,%d4
34d6c: 2007 movel %d7,%d0
34d6e: d082 addl %d2,%d0
34d70: b880 cmpl %d0,%d4
34d72: 6d16 blts 34d8a <_V_DrawBlock+0x7a>
34d74: 4aaf 0028 tstl %sp@(40)
34d78: 6d10 blts 34d8a <_V_DrawBlock+0x7a>
34d7a: 202f 0028 movel %sp@(40),%d0
34d7e: d083 addl %d3,%d0
34d80: b0b9 0000 72b0 cmpl 72b0 <_SCREENHEIGHT>,%d0
34d86: 6f00 0082 blew 34e0a <_V_DrawBlock+0xfa>
34d8a: 4879 0003 4ce5 pea 34ce5 <_V_DrawPatchInDirectFlipped+0x239>
34d90: 4eb9 0000 25f8 jsr 25f8 <_I_Error>
34d96: 2839 0000 72b4 movel 72b4 <_SCREENWIDTH>,%d4
34d9c: 588f addql #4,%sp
34d9e: 4c2f 046057
34da0: 4800 nbcd %d0
34da2: 0028 d887 d8b0 orib #-121,%a0@(-10064)
34da8: ddb0 0000 addl %d6,%a0@(00000000,%d0:w)
34dac: 5cb8 4a83 addql #6,19075
34db0: 6720 beqs 34dd2 <_V_DrawBlock+0xc2>
34db2: 2c03 movel %d3,%d6
34db4: 45f9 0003 d22c lea 3d22c <_memcpy>,%a2
34dba: 2f02 movel %d2,%sp@-
34dbc: 2f05 movel %d5,%sp@-
34dbe: 2f04 movel %d4,%sp@-
34dc0: 4e92 jsr %a2@
34dc2: da82 addl %d2,%d5
34dc4: d8b9 0000 72b4 addl 72b4 <_SCREENWIDTH>,%d4
34dca: 5386 subql #1,%d6
34dcc: 4fef 000c lea %sp@(12),%sp
34dd0: 66e8 bnes 34dba <_V_DrawBlock+0xaa>
34dd2: 2f03 movel %d3,%sp@-
34dd4: 4879 0003 4cf5 pea 34cf5 <_V_DrawPatchInDirectFlipped+0x249>
34dda: 4e93 jsr %a3@
34ddc: 2079 0000 674c moveal 674c <___iob>,%a0
34de2: 2f28 0004 movel %a0@(4),%sp@-
34de6: 4e96 jsr %a6@
34de8: 4fef 000c lea %sp@(12),%sp
34dec: 4a8d tstl %a5
34dee: 6708 beqs 34df8 <_V_DrawBlock+0xe8>
34df0: 4cdf 6cfc moveml %sp@+,%d2-%d7/%a2-%a3/%a5-%a6
34df4: 588f addql #4,%sp
34df6: 4e75 rts
34df8: 222f 0028 movel %sp@(40),%d1 ; x
34dfc: 2007 movel %d7,%d0 ; y
(assumed d2 and d3 still hold width/height??)
// GCC tries to save on RTS's, cleans up its stack, but this seems to override d2/d3 and thus I_MarkRect gets called with wrong values. I think, in this case this optimization cannot be done in this way.
34dfe: 4cdf 6cfc moveml %sp@+,%d2-%d7/%a2-%a3/%a5-%a6
34e02: 588f addql #4,%sp
34e04: 4ef9 0000 8868 jmp 8868 <_I_MarkRect>
34e0a: 7004 moveq #4,%d0
34e0c: b08d cmpl %a5,%d0
34e0e: 648e bccs 34d9e <_V_DrawBlock+0x8e>
34e10: 4879 0003 4ce5 pea 34ce5 <_V_DrawPatchInDirectFlipped+0x239>
34e16: 4eb9 0000 25f8 jsr 25f8 <_I_Error>
34e1c: 2839 0000 72b4 movel 72b4 <_SCREENWIDTH>,%d4
34e22: 588f addql #4,%sp
34e24: 6000 ff78 braw 34d9e <_V_DrawBlock+0x8e>
[Compiler internal error] error: insn does not satisfy its constraints
Looks like bebbo/amigaos-cross-toolchain#34 but I think it's a different error.
git clone https://github.com/alexalkis/a68k
m68k-amigaos-gcc -mcrt=nix13 -fbaserel -m68000 -msmall-code -o foo *.c
Symtab.c: In function ‘SubArgs’:
Symtab.c:494:1: error: insn does not satisfy its constraints:
}
^
(insn 388 6 75 (set (reg:SI 9 a1)
(plus:SI (reg/v/f:SI 2 d2 [orig:32 s ] [32])
(const_int 2 [0x2]))) 141 {addsi3_internal}
(nil))
Symtab.c:494:1: internal compiler error: in final_scan_insn, at final.c:2923
0xc33e59 _fatal_insn(char const, rtx_def const*, char const*, int, char const*)
/home/alex/t/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:108
0xc33eb9 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alex/t/amigaos-cross-toolchain/submodules/gcc-6/gcc/rtl-error.c:118
0x934046 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/alex/t/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2923
0x93235a final(rtx_insn*, _IO_FILE*, int)
/home/alex/t/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:2045
0x936ea9 rest_of_handle_final
/home/alex/t/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4455
0x9370a8 execute
/home/alex/t/amigaos-cross-toolchain/submodules/gcc-6/gcc/final.c:4530
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
fbbb e Optimization creates problems
There still seems to be a problem with your "e" optimitazion.
I must currently compile 3 cpp-files for espeak without 'e' to get a correct running extecutable.
The problem became visible when I experimented with your new profiling and changed all static functions to non-static functions.
Now I have to compile with -O2 -fbbb=abcfilmprsz # without 'e'
instead of just -O2 to get a correct executable.
I attached the shortest file preprocrecessed and the generated good and bad assembly files.
Compiler etc from 24.October.
broken interaction of inlining and -fbbb optimizations
When refactoring the timing code for ADoom a bit ( mheyer32/ADoom@924af3f )
I started getting crashes and hangs.. and nothing in the new code indicated such problem.
Eventually I boiled it down to a call to print_timers() in amiga_video.c. Get rid of the call and the crashes are gone. I noticed that the crashes were also gone with -fbbb=- or when preventing inlining of the function.
Looking at the assembly it looks like the compiler decided to inline the functions at the call site. This is fine....its only ever getting called from there.
The difference is that with the fbbb optimizations enabled, the inlined code stores the address of _total_frames in a4 without restoring a4 to the base pointer - wreaking havoc later on:
7949 .L595:
7950 354e 1C39 0000 lea _total_frames,a4 <<<<<<<<<<<<<<<< here
7950 01AA
7951 3554 49C6 move.l (a4),d0
7952 3556 2079 0000 .LBB866:
7952 12C0
7953 355c 2A08 .LBB867:
7954 355e E58D .stabd 68,0,1976
7955 3560 DA88 moveq #9,d1
7956 3562 E78D cmp.l d0,d1
7957 3564 2203 jcc .L555
7958 3566 4C02 1800 .stabd 68,0,1977
7959 356a 2441 move.l d0,-(sp)
7960 356c 2679 0000 pea .LC85
7960 12BC
7961 3572 4C04 3800 jsr _printf
7962 3576 220D .stabd 68,0,1978
7963 3578 4C01 2800 lea _PrintTime,a2
7964 357c 2800 move.l (a4),d1
7965 357e 2209 lea .LC86,a0
7966 3580 E3AC move.l _blit_time,d0
7967 3582 2200 jsr (a2)
7968 3584 EFA9 move.l (a4),d1
7969 3586 EDA8 .stabd 68,0,1979
7970 3588 49F0 59B0 lea .LC87,a0
7970 0000 1420
7971 3590 D5EC 0000 move.l _safe_time,d0
7972 3594 4EB9 0000 jsr (a2)
7972 0000
7973 move.l (a4),d1
7974 .stabd 68,0,1980
7975 lea .LC88,a0
7976 move.l _c2p_time,d0
7977 jsr (a2)
7978 move.l (a4),d1
7979 .stabd 68,0,1981
7980 359a 2C79 0000 lea .LC89,a0
7980 0000
7981 35a0 41EF 0030 move.l _video_safe_time,d0
7982 jsr (a2)
7983 35a4 4EAE FFC4 move.l (a4),d1
7984 .stabd 68,0,1982
7985 lea .LC90,a0
7986 move.l _video_disp_time,d0
7987 jsr (a2)
7988 clr.l (a4)
7989 .stabd 68,0,1989
7990 clr.l _blit_time
7991 35a8 202F 0034 .stabd 68,0,1990
7992 35ac D0B9 0000 clr.l _safe_time
7992 03A4
7993 35b2 90AF 002C .stabd 68,0,1991
7994 35b6 23C0 0000 clr.l _c2p_time
7994 03A4
7995 .stabd 68,0,1993
7996 35bc 33FC 0001 clr.l _wpa8_time
7996 0000 0496
7997 .stabd 68,0,1994
7998 clr.l _lock_time
7999 35c4 4A79 0000 .stabd 68,0,1995
7999 0490
8000 35ca 6700 FB26 clr.l _video_safe_time
8001 35ce 6000 FCD6 .stabd 68,0,1996
8002 clr.l _video_disp_time
8003 addq.l #8,sp
8004 .LBE867:
8005 35d2 2439 0000 .LBE866:
8005 0000
8006 35d8 2003 .stabd 68,0,1491
8007 35da 4C02 0800 movem.l (sp)+,d2/d3/d4/d5/d6/d7/a2/a3/a5/a6
8008 35de 2440 lea (16,sp),sp
8009 rts
With the fbbb optimizations disabled the code looks like this:
8004 36c8 1E39 0000 .L595:
8004 01A9
8005 36ce 49C7 .LBB866:
8006 .LBB867:
8007 36d0 1C39 0000 .stabd 68,0,1976
8007 01AA
8008 36d6 49C6 move.l _total_frames,d0
8009 36d8 2079 0000 moveq #9,d1
8009 12C0
8010 36de 2A08 cmp.l d0,d1
8011 36e0 E58D jcc .L555
8012 36e2 DA88 .stabd 68,0,1977
8013 36e4 E78D move.l d0,-(sp)
8014 36e6 2203 pea .LC85
8015 36e8 4C02 1800 jsr _printf
8016 36ec 2441 .stabd 68,0,1978
8017 36ee 2679 0000 lea _PrintTime,a3
8017 12BC
8018 36f4 4C04 3800 move.l _total_frames,d1
8019 36f8 220D lea .LC86,a0
8020 36fa 4C01 2800 move.l _blit_time,d0
8021 36fe 2800 jsr (a3)
8022 3700 2209 .stabd 68,0,1979
8023 3702 E3AC move.l _total_frames,d1
8024 3704 2200 lea .LC87,a0
8025 3706 EFA9 move.l _safe_time,d0
8026 3708 EDA8 jsr (a3)
8027 370a 49F0 59B0 .stabd 68,0,1980
8027 0000 1420
8028 3712 D5EC 0000 move.l _total_frames,d1
8029 3716 4EB9 0000 lea .LC88,a0
8029 0000
8030 move.l _c2p_time,d0
8031 jsr (a3)
8032 .stabd 68,0,1981
8033 move.l _total_frames,d1
8034 lea .LC89,a0
8035 move.l _video_safe_time,d0
8036 jsr (a3)
8037 371c 2C79 0000 .stabd 68,0,1982
8037 0000
8038 3722 41EF 0030 move.l _total_frames,d1
8039 lea .LC90,a0
8040 3726 4EAE FFC4 move.l _video_disp_time,d0
8041 jsr (a3)
8042 .stabd 68,0,1987
8043 clr.l _total_frames
8044 .stabd 68,0,1989
8045 clr.l _blit_time
8046 .stabd 68,0,1990
8047 clr.l _safe_time
8048 372a 202F 0034 .stabd 68,0,1991
8049 372e D0B9 0000 clr.l _c2p_time
8049 03A4
8050 3734 90AF 002C .stabd 68,0,1993
8051 3738 23C0 0000 clr.l _wpa8_time
8051 03A4
8052 .stabd 68,0,1994
8053 373e 33FC 0001 clr.l _lock_time
8053 0000 0496
8054 .stabd 68,0,1995
8055 clr.l _video_safe_time
8056 3746 4A79 0000 .stabd 68,0,1996
8056 0490
8057 374c 6700 FAF8 clr.l _video_disp_time
8058 3750 6000 FCB4 addq.l #8,sp
8059 .LBE867:
8060 .LBE866:
8061 .stabd 68,0,1491
8062 3754 2439 0000 movem.l (sp)+,d2/d3/d4/d5/d6/d7/a2/a3/a5/a6
8062 0000
8063 375a 2003 lea (16,sp),sp
8064 375c 4C02 0800 rts
Generates unsupported CAS instructions
The compiler generates CAS instructions for 020+ targets. Amiga hardware cannot handle this instruction reliably. PR #32 fixes this issue by disabling CAS generation.
Trashed registers when optimizing register-passed float/double arguments
Consider that piece of code:
#if 0
/opt/amiga/bin/m68k-amigaos-gcc-6.4.1b -Wall -O1 -fomit-frame-pointer -ffast-math -funroll-all-loops -funsafe-math-optimizations -m68030 -m68881 -S $0 -o -
exit
#endif
float f1(float a __asm("fp0"));
float f2(float a __asm("fp0"));
float f3(float a __asm("fp0")) {
float v1 = f1(a), v2 = f2(a);
return v1+v2;
}
And compile it (just 'sh' it) and inspect the generated asm:
$ sh bug_gcc6/tst.c
#NO_APP
.text
.align 2
.globl _f3
_f3:
move.l d2,-(sp)
jsr _f1 ; <===== fp0 transhed!!
move.l d0,d2
jsr _f2 ; <===== bug!!! f2 will use a trashed argument
fsmove.s d2,fp0
fsadd.s d0,fp0
fmove.s fp0,d0
move.l (sp)+,d2
rts
The asm code is totally broken. the value of fp0 in f3() isn't preserved and reused to call f2(). Actually f2 is called with garbage in fp0. It looks like the optimizer did remove some important code because when compiling with -O0, one gets a correct asm:
_f3:
lea (-12,sp),sp
fmove.s fp0,(sp)
fmove.s (sp),fp0
jsr _f1
move.l d0,8(sp)
fmove.s (sp),fp0
jsr _f2
move.l d0,4(sp)
fmove.s 8(sp),fp0
fadd.s 4(sp),fp0
fmove.s fp0,d0
lea (12,sp),sp
rts
Notice that this issue doesn't happen when using doubles, but another trouble occurs: one fp-reg isn't preserved!
_f3:
fmovem #20,-(sp) ; <=== pushes fp4 onto stack, but not fp2!!!
fmove.x fp0,fp4
jsr _f1
move.l d1,-(sp)
move.l d0,-(sp)
fmove.d (sp)+,fp2 ; <=== fp2 is modified but not preserved in the prologue of the function
fmove.x fp4,fp0
jsr _f2
move.l d1,-(sp)
move.l d0,-(sp)
fmove.d (sp)+,fp0
fadd.x fp2,fp0
fmove.d fp0,-(sp)
move.l (sp)+,d0
move.l (sp)+,d1
fmovem (sp)+,#40
rts
BTW:
-
why does gcc always wants to return floats (and double) in d0(/d1) ? this requires lots of useless stack-moves. It would have been better if gcc returned float/doubles in fp0 when fpu code is generated.
-
even with double being returned in d0/d1, the above code looks sub-optimal (in addition of being bogus). Once d0/d1 are pushed onto the stack, they don't need to be pop'ed immediately to fp2. If it was differed upto the fadd one woudn't need fp2 at all (fadd.d (sp)+,fp0 doesn't need an fp-reg).
Actually using the stack instead of fp-regs to store the temporary results of fpu computation makes sense since 1) it prevents allocating an extra fp-reg to hold the temporary value (which is no reused) and 2) gcc already uses the stack to converrt data-regs info fp-regs.
-mregparm has issues
Both, -mcrt=clib2 and -noixemul have crashing issues in combination with -mregparm=4.
I can't pin it down yet, but opening this issue for tracking.
crash probably cause of float/double code (?)
clone this https://github.com/glouw/dungen
At arround line 292 on Map.c, change to:
static float mag(const Point a)
{
#ifdef __AMIGA
return sqrt(a.x * a.x + a.y * a.y);
#else
return sqrtf(a.x * a.x + a.y * a.y);
#endif
}
make CC=m68k-amigaos-gcc CFLAGS=-noixemul
Executable crashes on (emulated) A1200 (8000 000B)
__floatunsisf is bogus / HUNK_SYMBOL offsets do not match functions
It appears that the HUNK_SYMBOL function offsets sometimes do not match the offset at the beginning of the function. This may be part of the cause of debuggers and disassemblers not being able to load symbols in some compiled executables. FindHit/FindHunkOffset type programs do not return reliable information either. The GCC6 compile of Netsurf appears to have incorrect function symbol offsets.
http://www.cy2.uk/tmp/netsurf_os3-gcc6.lha
Be warned that this executable has MuForce hits and may crash while the older GCC compile is clean with no problems. Maybe you can spot some of your compiler bugs while looking into the problem.
Example debugger which will not load symbols is BDebug from the Barfly package.
http://aminet.net/dev/asm/BarflyDisk2_00.lha
Edit: BDebug has a bug where it does not show proper start or sizes of hunks. The GCC6 generated offsets I can now verify as correct. There is still a problem with symbols not loading from the GCC6 executable in any debugger or disassembler output but I have no valid clues why so I will close the topic. There are also MuForce hits and crashes in Netsurf likely caused by compiler bugs.
Question from notes on Apollo core forum
In a discussion thread here: http://www.apollo-core.com/knowledge.php?b=2¬e=12425
Gunnar makes a comment which I have pasted below. Does this still apply to the current gcc?
Thanks
======Comment============================================
GCC and other C compiler sometimes create relative bad results.
Lets give an example:
Below is part of the main render function in NEO-GEO emulator.
L73:
bfextu d1{#4:#4},d0
tst.b d0
jeq L74
and.l #255,d0
move.w 2(a2,d0.l*4),18(a0)
L74:
bfextu d1{#8:#4},d0
tst.b d0
jeq L75
and.l #255,d0
move.w 2(a2,d0.l*4),20(a0)
L75:
bfextu d1{#12:#4},d0
tst.b d0
jeq L76
and.l #255,d0
move.w 2(a2,d0.l*4),22(a0)
This code uses 5 instructions per pixel.
The BFEXTU does set the flags correctly.
GCC is nor aware if this - and put there an extra TST instruction to create the flags. This instruction is NOT needed and useless.
Then GCC puts there a AND.L #$FF,D0 to limit the result to BYTE range. The extracted value of BFEXTU is by the parameter already limited to Byte range. This means this AND is totally unneeded.
In short: of the 5 instruction - 2 are useless.
That GCC throws on 68K huge number of unneeded TST instructions is a known bug in GCC - which is caused by the laziness of the GCC developers - they simply did not care to implement a tracking of the flags created by instructions.
-pg and -fbaserel incompatible?
I'm getting below error messages, is this to be expected?
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: gmon.o: baserelative text relocation to "__stext"
doomsound_midi.library: .text reloc for __stext is out of range: 00000000
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: gmon.o: baserelative text relocation to "__stext"
doomsound_midi.library: .text reloc for __stext is out of range: 00000000
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: gmon.o: baserelative text relocation to "__stext"
doomsound_midi.library: .text reloc for __stext is out of range: 00000000
/home/matze/amigatoolchain/amiga-gcc-out/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: gmon.o: baserelative text relocation to "__etext"
doomsound_midi.library: .text reloc for __etext is out of range: 00000000
Float/double wrong math
Ok, I've been beaten by messy libraries setup on my part, so first things first.
Sorry for the source code, it's a convert from basic :)
Anyways, on Friday a total lunar eclipse will happen. (On 27/7)
If you run the le_bug you'll get 28/7, if you run the le you'll get 27/7
The funny thing is that when I was adding/removing printfs to find where is goes wrong, it was giving the correct display of 27. Add/remove some more printfs and then 28 and then 27 again.
Finally, I switched to no optimisations and got it steady on 27. (I was using -O3 till then).
the value of variable b (line 109) was changing (by 1) without touching it.
PS: the code runs fine in linux
clobbered register in parallel insn is not treated correctly.
int rand(void)
{ return (a=a*1103515245+12345)%RAND_MAX; }
generates bogus code with -m68020 -O0 since the trashing of reg d1 is not handled correctly and thus a new load is optimized away as redundand load
Amiga specific attributes getting ignored
void REGARGS (*c2p)(REG(a0, const UBYTE* chunky),
REG(a1, UBYTE* raster),
REG(a2, const UBYTE* chunky_end)) = NULL;
amiga_video.c:68:5: warning: `__regparm__' attribute only applies to functions [-Wattributes]
REG(a2, const UBYTE* chunky_end)) = NULL;
static UWORD CHIP emptypointer[] = {
0x0000, 0x0000, /* reserved, must be NULL */
0x0000, 0x0000, /* 1 row of image data */
0x0000, 0x0000 /* reserved, must be NULL */
};
amiga_video.c:148:1: warning: ‘__chip__’ attribute directive ignored [-Wattributes]
CHIP static UWORD emptypointer[] = {
^~~~
static struct InputEvent* SAVEDS INTERRUPT REGARGS video_inputhandler(REG(a0, struct InputEvent* ie),
REG(a1, APTR data));
amiga_video.c:164:71: warning: ‘__saveds__’ attribute directive ignored [-Wattributes]
REG(a1, APTR data));
^~~
static void SAVEDS INTERRUPT video_flipscreentask(void)
{
}
amiga_video.c:399:1: warning: ‘__saveds__’ attribute directive ignored [-Wattributes]
{
^
-fbbb= output in m68k-amigaos-gcc --help=target bad formated
The text of -fbbb part in m68k-amigaos-gcc --help=target output is unreadable because it is bad formated
Linux 4.4.0-109-generic #132-Ubuntu SMP Tue Jan 9 19:52:39 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Nonsense linker paths
I've built gcc6 based off of your patches , and I obviously understand there might be something different in the way I'm building it because of this but the old gcc4.3 built using the correct paths and the same options so I think gcc6 ought to too :) I'm building as a cross-compiler if that makes a difference.
When gcc comes to linking anyting it tried to access the following path:
/opt/netsurf/m68k-unknown-amigaos/cross/m68k-amigaos/clib2/lib//opt/netsurf/m68k-unknown-amigaos/cross/lib/gcc/m68k-unknown-amigaos/6.4.0/../../../../m68k-unknown-amigaos/lib/ncrt0.o
Obviously this path is complete nonsense because the initial bit (I've since fixed the m68k-amigaos/m68k-unknown-amigaos difference in my patches) has been prepended to something else which would also work as a complete path.
It should probably be /opt/netsurf/m68k-unknown-amigaos/cross/m68k-(unknown-)amigaos/clib2/lib/ncrt0.o (that is to say, the first part of the path before it has appended the complete path again is correct, but missing the object filename) but I can't figure out how to fix the path, other than it is probably related to amiga_m68k_prefix_func() or the sdk_root specs.
ICE (segfault)
Built the m68k cross-toolchain from your fork with --gcc=6 --bibutils=2.14 .
Trying to build uhexen2 source (https://sf.net/p/uhexen2/ or github mirror at
https://github.com/svn2github/uhexen2.git) with this, gcc segfaults in our cl_demo.c:
cd uhexen2/engine/hexen2/
m68k-amigaos-gcc -c -I. -I../h2shared -I../../common -I../../oslibs/amigaos/include -Wall -O2 -DNDEBUG=1 -ffast-math -fomit-frame-pointer -noixemul -m68020-60 -o cl_demo.o cl_demo.c
*** Error in `/home/me/m68k/libexec/gcc/m68k-amigaos/6.3.1b/cc1': malloc(): memory corruption: 0x0000000003b896b0 ***
*** Error in `/home/me/m68k/libexec/gcc/m68k-amigaos/6.3.1b/cc1': malloc(): memory corruption: 0x0000000003b896b0 ***
*** Error in `/home/me/m68k/libexec/gcc/m68k-amigaos/6.3.1b/cc1': malloc(): memory corruption (fast): 0x0000000003ba96a0 ***
m68k-amigaos-gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Attached the preprocessed source here.
cl_demo.i.zip
Linker issues with larger projects
Attached you'll find the whole ADoom project that I'm trying to compile for a while now. I've come as far as to the linking stage, but there's always some issues with relocations that I cannot seem to find a way around.
No amount of permutations of -mcrt=clib2, -noixemul, -fbaserel, -fbaserel32 (or the lack of -fbaserel) got me anywhere - there's always some object files the linker complains about, be it objects from the project itself or objects from the c runtime libs.
Since I'm dependent on libnet, I'm stuck with -mcrt=clib2. -fbaserel32 is not a good solution. Its slow, not supported by vasm and not a good solution in general (32bit offsets to a 32bit base - we could use absolutes in that case and be faster)
Thanks for your help!
copying small structs broken -O0 vs O3, maybe related to -fbaserel
Consider this code in ADoom, m_menu:
If the code worked, we should not see a "ReadThis" menu entry. Yet, in -O0 mode a 'ReadThis' menu entry is visible in the main menu, while in -On mode, the last menu entry is just 'Quit'. The -O0 version is broken.
switch (gamemode) {
case commercial:
// This is used because DOOM 2 had only one HELP
// page. I use CREDIT as second page now, but
// kept this hack for educational purposes.
MainMenu[readthis] = MainMenu[quitdoom];
MainDef.numitems--;
MainDef.y += 8;
NewDef.prevMenu = &MainDef;
ReadDef1.routine = M_DrawReadThis1;
ReadDef1.x = 330;
ReadDef1.y = 165;
ReadMenu1[0].routine = M_FinishReadThis;
break;
In -O0 it seems the code is broken, copying the menu entry onto itself??
5375 2842 41EC 0094 .L309:
5376 2846 43EC 0094 .stabd 68,0,1536
5377 284a 2290 lea _MainMenu:W(a4),a0 <<<<<<<< something is wrong here, these need to be two different addresses
5378 284c 5889 lea _MainMenu:W(a4),a1 <<<<<<<<
5379 284e 5888 move.l (a0),(a1)
5380 2850 2290 addq.l #4,a1
5381 2852 5889 addq.l #4,a0
5382 2854 5888 move.l (a0),(a1)
5383 2856 2290 addq.l #4,a1
5384 2858 5889 addq.l #4,a0
5385 285a 5888 move.l (a0),(a1)
5386 285c 2290 addq.l #4,a1
5387 285e 5889 addq.l #4,a0
5388 2860 5888 move.l (a0),(a1)
5389 2862 3290 addq.l #4,a1
5390 2864 5489 addq.l #4,a0
5391 2866 5488 move.w (a0),(a1)
5392 addq.l #2,a1
5393 2868 3039 0000 addq.l #2,a0
5393 0100
5394 286e 5340 .stabd 68,0,1537
5395 2870 33C0 0000 move.w _MainDef,d0
5395 0100
5396 subq.w #1,d0
5397 2876 3039 0000 move.w d0,_MainDef
5397 0110
5398 287c 5040 .stabd 68,0,1538
5399 287e 33C0 0000 move.w _MainDef+16,d0
5399 0110
5400 addq.w #8,d0
5401 2884 41EC 0100 move.w d0,_MainDef+16
5402 2888 23C8 0000 .stabd 68,0,1539
5402 01CE
5403 lea _MainDef:W(a4),a0
5404 288e 23FC 0000 move.l a0,_NewDef+2
5404 0888 0000
5404 02A2
5405 .stabd 68,0,1540
5406 2898 33FC 014A move.l #_M_DrawReadThis1,_ReadDef1+10
5406 0000 02A6
5407 .stabd 68,0,1541
5408 28a0 33FC 00A5 move.w #330,_ReadDef1+14
5408 0000 02A8
5409 .stabd 68,0,1542
5410 28a8 23FC 0000 move.w #165,_ReadDef1+16
5410 106C 0000
5410 0290
5411 .stabd 68,0,1543
5412 28b2 6010 move.l #_M_FinishReadThis,_ReadMenu1+12
5413 .stabd 68,0,1
In release mode, the code seems to work better, but I have my doubts about it, too.
The first move addresses _MainMenu a4-relative (which seems to be ok), but the other lea/moves
do not use a4 as basis. Is that correct?
1537:m_menu.c **** MainDef.numitems--;
4652 .stabd 68,0,1536
4653 225a 5350 move.l _MainMenu+90:W(a4),_MainMenu+72:W(a4)
1538:m_menu.c **** MainDef.y += 8;
4654 lea _MainMenu+94,a1
4655 225c 506C 03AC move.l (a1),_MainMenu+76
1539:m_menu.c **** NewDef.prevMenu = &MainDef;
4656 lea _MainMenu+98,a1
4657 2260 2948 02D2 move.l (a1),_MainMenu+80
1540:m_menu.c **** ReadDef1.routine = M_DrawReadThis1;
4658 lea _MainMenu+102,a1
4659 2264 297C 0000 move.l (a1),_MainMenu+84
4659 0348 020E
1541:m_menu.c **** ReadDef1.x = 330;
4660 lea _MainMenu+106,a1
4661 226c 397C 014A move.w (a1),_MainMenu+88
4661 0212
1542:m_menu.c **** ReadDef1.y = 165;
4662 .stabd 68,0,1537
4663 2272 397C 00A5 subq.w #1,(a0)
4663 0214
1543:m_menu.c **** ReadMenu1[0].routine = M_FinishReadThis;
4664 .stabd 68,0,1538
4665 2278 297C 0000 addq.w #8,_MainDef+16:W(a4)
4665 2194 0224
1544:m_menu.c **** break;
Register parameter do not seem to be forwarded onto stack
The function I_MarkRect receives parameters via registers. But when it calls into printf, it forgets to put the parameters properly on the stack, resulting in weird output. Strangely enough, though, the first two parameters left and top are getting printed correctly.
The example was compiled with -mcrt-clib2 -Ofast -fbaserel
void I_MarkRect(REG(d0, int left), REG(d1, int top), REG(d2, int width), REG(d3, int height))
{
printf("I_MarkRect %d, %d, %d, %d \n", left, top, width, height);
M_AddToBox(dirtybox, left, top);
M_AddToBox(dirtybox, left + width - 1, top + height - 1);
}
generated assembly:
00008860 <_I_MarkRect>:
8860: 48e7 3036 moveml %d2-%d3/%a2-%a3/%a5-%a6,%sp@-
8864: 2440 moveal %d0,%a2
8866: 2641 moveal %d1,%a3
8868: 4879 0000 8842 pea 8842 <_I_SetPalette+0x46> <------------ I suppose this is the format string
886e: 4eb9 0003 c914 jsr 3c914 <_printf>
8874: 2079 0000 674c moveal 674c <___iob>,%a0
887a: 2f28 0004 movel %a0@(4),%sp@-
887e: 4eb9 0003 d200 jsr 3d200 <_fflush>
8884: 220b movel %a3,%d1
8886: 200a movel %a2,%d0
8888: 41ec a58a lea %a4@(-23158),%a0
888c: 4eb9 0001 a2cc jsr 1a2cc <_M_AddToBox>
8892: 508f addql #8,%sp
8894: 41f3 38ff lea %a3@(ffffffffffffffff,%d3:l),%a0
8898: 2208 movel %a0,%d1
889a: 41f2 28ff lea %a2@(ffffffffffffffff,%d2:l),%a0
889e: 2008 movel %a0,%d0
88a0: 41f9 0000 2588 lea 2588 <_dirtybox>,%a0
88a6: 4cdf 6c0c moveml %sp@+,%d2-%d3/%a2-%a3/%a5-%a6
88aa: 4ef9 0001 a2cc jmp 1a2cc <_M_AddToBox>
register renaming + dead assignment elimination seems broken
When compiling Adoom with -O2 or above, triggering the first secret door in the first level, a crash happens.
I was able to track it down to a function call inside
p_doors.c
int EV_DoDoor(line_t* line, vldoor_e type)
{
}
in this function you'll notice multiple sequences of this kind:
1e77e: 7001 moveq #1,%d0
1e780: 2740 001c movel %d0,%a3@(28)
1e784: 2049 moveal %a1,%a0
1e786: 2f49 0028 movel %a1,%sp@(40)
1e78a: 2a46 moveal %d6,%a5
1e78c: 4e95 jsr %a5@
But looking around, there seems to be no place where d6 is actually assigned. So the jump ends up in nirvana. I believe that the optimizer tried to store a function address into d6 outside the loop.
When enabling verbose -fbbb output, I can see "eliminate dead assign to d6" which seems to be highly suspicious.
:bbb: in 'EV_DoDoor'
:bbb: ENTER
**:bbb: (e) 12: eliminate dead assign to d6**
:bbb: (r) opt_reg_rename a1 -> a0 (3 locs, start at 40)
40 41 43
:bbb: (r) opt_reg_rename a1 -> a0 (2 locs, start at 83)
83 84
:bbb: (r) opt_reg_rename a1 -> a0 (2 locs, start at 125)
125 126
:bbb: inline weight = 119 EV_DoDoor
g++ produced executable locks amiga
#include <iostream>
int main() {
std::cout << "Hello\n";
return 0;
}
compiled with
m68k-amigaos-g++ -O3 -noixemul -o num foo.cpp
locks up amiga (a1200 in fs-uae)
64bit math
`#include <stdio.h>
#include <stdlib.h>
typedef unsigned long long u64;
u64 fib(int n)
{
if (n==1 || n==2)
return 1;
return fib(n-1)+fib(n-2);
}
int main(int argc, char *argv[])
{
int inp;
if (argc==2) {
inp = atol(argv[1]);
} else {
inp = 10;
}
printf("%lld\n", fib(inp));
return 0;
}
`
Compile with: m68k-amigaos-gcc -noixemul -O2 -o print64 print64.c
gives wrong result on argument 5 (correct for 1-4)
If you add -lm at the end, doesn't work correctly for any argument.
With -O0 seems to be correct.
Problem with "e" optimization
Some heisenbugs I've got here:
With 'e' optimization enabled, playerListInit()'s loop runs more than it should and game hangs. If I uncomment bobNewInit or put logWrite around them with loop counter printing, everything works fine. CC_FLAGS = -std=gnu11 $(INCLUDES) -DAMIGA -noixemul -Wall -Wextra -fomit-frame-pointer -O3
gsgame_player.c.txt
gsgame_player.with-e.S.txt
gsgame_player.no-e.S.txt
having trouble with .library
Compiling https://github.com/mheyer32/dopus5allamigas
via
cd source
make os3 [release] [debug=no]
Produces a dopus.library file that upon loading via OpenLibrary() will crash the system.
Something seems to be 'off' with the library. When running with WinUAEEnforcer, I can see some code will attempt to read from a bunch of low-memory addresses like 38,39,3a, 3b, 3e etc and eventually also write there.
Is there something not right in the way it is linked or compiled?
Sorry for not having any more precise to go on, I'll attach the binary containing debug data,
The library is using its own startup files, has const data, a few preinitialized variables etc... is theer anything obviously wrong with it?
Optimization causes incorrect code(?)
ADoom is using a function declared as extern, implemented in assembly. Parameters are passed via registers:
void V_DrawPatch(REG(d0, int x), REG(d1, int y), REG(d2, int scrn), REG(a0, patch_t* patch));
But calling that function from C code caused me a lot of grief and debugging. I first thought that the assembly function contained broken code, but it does not. With -O0 the code will run.
It turned out that the 'patch' pointer never arrived healthy in the assembler function.
void STlib_updateBinIcon(st_binicon_t* bi, boolean refresh)
{
int x;
int y;
int w;
int h;
if (*bi->on && (bi->oldval != *bi->val || refresh)) {
x = bi->x - SWAPSHORT(bi->p->leftoffset);
y = bi->y - SWAPSHORT(bi->p->topoffset);
w = SWAPSHORT(bi->p->width);
h = SWAPSHORT(bi->p->height);
if (y - ST_Y < 0)
I_Error("updateBinIcon: y - ST_Y < 0");
if (*bi->val) {
DEBUGPRINT(("V_DrawPatch for %p", bi->p));
// CALLED HERE:
V_DrawPatch(bi->x, bi->y, FG, bi->p);
} else {
DEBUGSTEP();
V_CopyRect(x, y - ST_Y, BG, w, h, x, y, FG);
}
bi->oldval = *bi->val;
}
}
Looking at the gcc produced assembly code revealed nothing:
217:st_lib.c **** DEBUGPRINT(("V_DrawPatch for %p", bi->p));
1068 .stabd 68,0,217
1069 04a8 2F2A 0014 move.l 20(a2),-(sp)
1070 04ac 4879 0000 pea .LC5
1070 0448
1071 04b2 4EB9 0000 jsr _printf
1071 0000
1072 04b8 2079 0000 move.l ___iob,a0
1072 0000
1073 04be 2F28 0004 move.l 4(a0),-(sp)
1074 04c2 4EB9 0000 jsr _fflush
1074 0000
218:st_lib.c **** V_DrawPatch(bi->x, bi->y, FG, bi->p);
1075 .stabd 68,0,218
1076 04c8 206A 0014 move.l 20(a2),a0
1077 04cc 4282 clr.l d2
1078 04ce 222A 0004 move.l 4(a2),d1
1079 04d2 2012 move.l (a2),d0
1080 04d4 4EB9 0000 jsr _V_DrawPatch
1080 0000
1081 04da 4FEF 000C lea (12,sp),sp
Looking at the disassembly produced by m68k-objdump didn't show anything interesting either:
00034d04 <_STlib_updateBinIcon>:
34d04: 48e7 3c34 moveml %d2-%d5/%a2-%a3/%a5,%sp@-
34d08: 246f 0020 moveal %sp@(32),%a2
34d0c: 206a 0010 moveal %a2@(16),%a0
34d10: 4a90 tstl %a0@
34d12: 677a beqs 34d8e <_STlib_updateBinIcon+0x8a>
34d14: 206a 000c moveal %a2@(12),%a0
34d18: 2210 movel %a0@,%d1
34d1a: b2aa 0008 cmpl %a2@(8),%d1
34d1e: 6700 00e8 beqw 34e08 <_STlib_updateBinIcon+0x104>
34d22: 2a52 moveal %a2@,%a5
34d24: 206a 0014 moveal %a2@(20),%a0
34d28: 3628 0004 movew %a0@(4),%d3
34d2c: 3028 0006 movew %a0@(6),%d0
34d30: e058 rorw #8,%d0
34d32: 266a 0004 moveal %a2@(4),%a3
34d36: 96c0 subaw %d0,%a3
34d38: 3418 movew %a0@+,%d2
34d3a: 3810 movew %a0@,%d4
34d3c: 70e0 moveq #-32,%d0
34d3e: d0b9 0000 7280 addl 7280 <_SCREENHEIGHT>,%d0
34d44: 2a0b movel %a3,%d5
34d46: 9a80 subl %d0,%d5
34d48: 6b00 00ee bmiw 34e38 <_STlib_updateBinIcon+0x134>
34d4c: 4a81 tstl %d1
34d4e: 6744 beqs 34d94 <_STlib_updateBinIcon+0x90>
34d50: 2f2a 0014 movel %a2@(20),%sp@-
34d54: 4879 0003 4cf0 pea 34cf0 <_STlib_initBinIcon+0x38>
34d5a: 4eb9 0003 c2d8 jsr 3c2d8 <_printf>
34d60: 2079 0000 6720 moveal 6720 <___iob>,%a0
34d66: 2f28 0004 movel %a0@(4),%sp@-
34d6a: 4eb9 0003 cbc4 jsr 3cbc4 <_fflush>
34d70: 206a 0014 moveal %a2@(20),%a0 ; patch address
34d74: 4282 clrl %d2 ; 'screen'
34d76: 222a 0004 movel %a2@(4),%d1 ; X
34d7a: 2012 movel %a2@,%d0 ; Y
34d7c: 4eb9 0000 19e0 jsr 19e0 <_V_DrawPatch>
34d82: 4fef 000c lea %sp@(12),%sp
34d86: 206a 000c moveal %a2@(12),%a0
34d8a: 2550 0008 movel %a0@,%a2@(8)
34d8e: 4cdf 2c3c moveml %sp@+,%d2-%d5/%a2-%a3/%a5
34d92: 4e75 rts
I then used WinUAE to debug the issue. I found that it would always call V_DrawPatch with 0x4000600 in A0, so I set a breakpoint in that condition and waited. Et voila:
403FDFA2 48e7 2036 MOVEM.L D2/A2-A3/A5-A6,-(A7)
403FDFA6 246f 001c MOVEA.L (A7, $001c) == $404b65c0,A2
403FDFAA 206a 0010 MOVEA.L (A2, $0010) == $40412fa4,A0
403FDFAE 4a90 TST.L (A0)
403FDFB0 6700 0096 BEQ.W #$0096 == $403fe048 (T)
403FDFB4 222a 0008 MOVE.L (A2, $0008) == $40412f9c,D1
403FDFB8 206a 000c MOVEA.L (A2, $000c) == $40412fa0,A0
403FDFBC 2010 MOVE.L (A0),D0
403FDFBE b081 CMP.L D1,D0
403FDFC0 6700 008e BEQ.W #$008e == $403fe050 (T)
403FDFC4 74ff MOVE.L #$ffffffff,D2
403FDFC6 b480 CMP.L D0,D2
403FDFC8 677e BEQ.B #$0000007e == $403fe048 (T)
403FDFCA b481 CMP.L D1,D2
403FDFCC 675c BEQ.B #$0000005c == $403fe02a (T)
403FDFCE 206a 0014 MOVEA.L (A2, $0014) == $40412fa8,A0
403FDFD2 2070 1c00 MOVEA.L (A0, D1.L*4, $00) == $040005fc,A0
403FDFD6 3028 0004 MOVE.W (A0, $0004) == $04000604,D0
403FDFDA e058 ROR.W #$00000008,D0
403FDFDC 2a52 MOVEA.L (A2),A5
403FDFDE 9ac0 SUBA.W D0,A5
403FDFE0 3028 0006 MOVE.W (A0, $0006) == $04000606,D0
403FDFE4 e058 ROR.W #$00000008,D0
403FDFE6 266a 0004 MOVEA.L (A2, $0004) == $40412f98,A3
403FDFEA 96c0 SUBA.W D0,A3
403FDFEC 3018 MOVE.W (A0)+,D0
403FDFEE e058 ROR.W #$00000008,D0
403FDFF0 3c40 MOVEA.W D0,A6
403FDFF2 3010 MOVE.W (A0),D0
403FDFF4 e058 ROR.W #$00000008,D0
403FDFF6 3040 MOVEA.W D0,A0
403FDFF8 70e0 MOVE.L #$ffffffe0,D0
403FDFFA d0b9 4041 3dd8 ADD.L $40413dd8,D0
403FE000 220b MOVE.L A3,D1
403FE002 9280 SUB.L D0,D1
403FE004 2001 MOVE.L D1,D0
403FE006 6d58 BLT.B #$00000058 == $403fe060 (F)
403FE008 42a7 CLR.L -(A7)
403FE00A 2f0b MOVE.L A3,-(A7)
403FE00C 2f0d MOVE.L A5,-(A7)
403FE00E 2f08 MOVE.L A0,-(A7)
403FE010 2f0e MOVE.L A6,-(A7)
403FE012 4878 0004 PEA.L $00000004
403FE016 2f00 MOVE.L D0,-(A7)
403FE018 2f0d MOVE.L A5,-(A7)
403FE01A 4eb9 403f d448 JSR $403fd448
403FE020 206a 000c MOVEA.L (A2, $000c) == $40412fa0,A0
403FE024 2010 MOVE.L (A0),D0
403FE026 4fef 0020 LEA.L (A7, $0020) == $404b65c4,A7
403FE02A 206a 0014 MOVEA.L (A2, $0014) == $40412fa8,A0 ; patch address
403FE02E 2070 0c00 MOVEA.L (A0, D0.L*4, $00) == $04000604,A0 ; ????
403FE032 4282 CLR.L D2 ; screen
403FE034 222a 0004 MOVE.L (A2, $0004) == $40412f98,D1 ; Y
403FE038 2012 MOVE.L (A2),D0 ; X
403FE03A 4eb9 4044 e488 JSR $4044e488 ; call V_DrawPatch
403FE040 206a 000c MOVEA.L (A2, $000c) == $40412fa0,A0
403FE044 2550 0008 MOVE.L (A0),(A2, $0008) == $40412f9c
403FE048 4cdf 6c04 MOVEM.L (A7)+,D2/A2-A3/A5-A6
403FE04C 588f ADDA.L #$00000004,A7
403FE04E 4e75 RTS
How in the world did the
403FF5DE 2070 0c00 MOVEA.L (A0, D0.L*4, $00) == $04000604,A0
line squeezed in there and why?
I also wonder how the code that objdump disassembled is so different from what is apparently running on the Amiga? One of the jsr's (to fflush?) seems to be missing... this is all very confusing.
Attaching the preprocessed source:
st_lib.txt
-msmall-code not working with ADoom
Out of interest I tried compiling ADoom with -msmall-code. It compiles, links (albeit with a few linker warnings ala "INFO: using long jump from amiga_main.o to d_main.o:_D_DoomMain").
But when you try to eventually start the executable, it just crashes :-/
Is -msmall-code expected to 'just work' or do I just have wrong expectations?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.