English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 17 February 2017, 19:17   #81
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
Originally Posted by patrik View Post
What hardware did you run the benchmark on?
WinUAE, 68020, fastest possible, More compatible, NO JIT

And if switch to

WinUAE, 68020, A1200 cycle exact, More compatible, NO JIT

The results differ:

Code:
tscpsc:   18920ms
tscpgcc:  14120ms 
tscpvbcc: 14120ms
tscpgcc6: 12280ms
So gcc6 is still the fastest but tscpvbcc is on par.

Guess I have to start my A3000T and test there too^^

Bebbo
bebbo is offline  
AdSense AdSense  
Old 17 February 2017, 19:39   #82
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 869
btw. probably not the case, but if there is anything to get from it, aros uses currently binutils 2.25 for gcc 6.3.0. if needed for reference, the diffs are to find in the usual locations. what id love to see, however likely too much to hope for, would to be bundling effort to improve amiga-m68k backend being usable for both for aros and aos. i lack though the expertise to contribute to it.
wawa is offline  
Old 17 February 2017, 20:02   #83
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
Originally Posted by wawa View Post
btw. probably not the case, but if there is anything to get from it, aros uses currently binutils 2.25 for gcc 6.3.0. if needed for reference, the diffs are to find in the usual locations. what id love to see, however likely too much to hope for, would to be bundling effort to improve amiga-m68k backend being usable for both for aros and aos. i lack though the expertise to contribute to it.
I wish there were AROS for the m68k, but there isn't. But thank you for pointing it out.

The problems with gcc/binutils are:

1. m68k Amiga register usages: A6 as library base, A5 as frame pointer, A4 as data segment ref.
2. The amiga hunk file format
3. fast ram / chip ram
4. special stuff like resident
5. dunno... guess way more.

The binutils modifications can't be merged easily since many things have changed, but I have an experimental binutils 2.27. And patching binutil 2.14 was easier. (Notice: some bugs I fixed in 2.14 are still present in the current 2.27, so noone really uses that **abandoned** code)

And gcc changed a lot from 3.4.* to 4.0.0. Porting the changes to 4.0.0 is the same effort as porting them to gcc-6, so I started with gcc-6.

Bebbo

PS: I am using the gcc-6 branch, so it's atm "version 6.3.1 20170217 (GCC)"

Last edited by bebbo; 17 February 2017 at 20:30.
bebbo is offline  
Old 17 February 2017, 20:36   #84
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 869
Quote:
Originally Posted by bebbo View Post
I wish there were AROS for the m68k, but there isn't.
you really dont know that there actually is aros68k ? i even posted a comparison binary results compiled with it (6.1.0) somewhere further above.

Quote:
The problems with gcc/binutils are:


1. m68k Amiga register usages: A6 as library base, A5 as frame pointer, A4 as data segment ref.
afaik, on aros this is taken care by a set of macros, similarly/interchengable like with sdi includes. functions that need parametrizing must of course follow certain syntax.

Quote:
2. The amiga hunk file format
aros binaries are compiled as elf since aros executes both formats and elf is the currently default binary format produced ba the compiler. however aros68k binaries are subsequently converted to hunk with elf2hunk utility while preparing distfiles, and runnable on aos, as long as they dont depend on specific aros libs.

Quote:
3. fast ram / chip ram
its being taken by the usual memory definition macros (MEMF_FAST and the like).

Quote:
4. special stuff like resident
dont know details, but must be handled somehow, the kickstart image works after all.

Quote:
And gcc changed a lot from 3.4.* to 4.0.0. Porting the changes to 4.0.0 is the same effort as porting them to gcc-6, so I started with gcc-6.

Bebbo
yes. thats understandable. btw for reference, except 3.4.x from zerohero there is 4.5.x from bernd rosch on amiga.sf. aros is currently still using 4.6.4 as default and 6.3.0 optionally. btw aros build system is to a certain extent ready for different further compiler options, like llvm/clang and lately some support for linking stage optimization has been introduced. also usage of vbcc/vasm has been evaluated already some time ago, but hasnt delivered expected advantage, so put on hold. toni btw, is much better informed in the matter, assistance needed, since he is/was one of the maintainers.
wawa is offline  
Old 17 February 2017, 23:43   #85
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
Originally Posted by wawa View Post
you really dont know that there actually is aros68k ? i even posted a comparison binary results compiled with it (6.1.0) somewhere further above.
just kidding, I once tried it but not using it.

And I can't find your post: http://eab.abime.net/search.php?searchid=3707779

Quote:
...
aros is currently still using 4.6.4 as default and 6.3.0 optionally.
...
The 4.6.4 version I found via sourceforge and what's provided in gcc-4.6.4-aros.diff does not provide very much. It's basically:

* support for A4/A5 instead of A5/A6.

Everything else what was in 2.95.3 is missing. And that's plenty.

Or does that exist? Where?

Bebbo
bebbo is offline  
Old 18 February 2017, 02:21   #86
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 869
Quote:
Everything else what was in 2.95.3 is missing. And that's plenty.
thats why i said there might be some refference, but on the other hand it likely needs improvement, which if someone would focus on might be beneficial for both platforms.

the 6.3.0 diff should be actualy alongside 4.6.4 in the repository. ill check in a minute. do you have a diff of your version against the upstream one? might be worth comparing, especially if you introduced further patches. still it would be a job for someone actually experienced. i fear toni doesnt bother with it, but maybe someone else might.

here are all diffs, voila:
https://trac.aros.org/trac/browser/A...ols/crosstools

Last edited by wawa; 18 February 2017 at 02:26.
wawa is offline  
Old 18 February 2017, 02:56   #87
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 42
Posts: 827
Send a message via Yahoo to Samurai_Crow
And the GitHub mirror is https://github.com/ezrec/AROS-mirror...ols/crosstools
Samurai_Crow is offline  
Old 18 February 2017, 03:39   #88
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 869
btw, bebbo, you read german?

here are some comments on the subject, just in case there was something helpful:

http://amiga-news.de/de/news/comment...-00029-DE.html
wawa is offline  
Old 18 February 2017, 12:30   #89
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
Originally Posted by wawa View Post
btw, bebbo, you read german?

here are some comments on the subject, just in case there was something helpful:

http://amiga-news.de/de/news/comment...-00029-DE.html
Uhm German? Guess I do.

Thanks for pointing me/us to that german thread.

Bebbo
bebbo is offline  
Old 18 February 2017, 14:38   #90
sbergmann
Registered User
sbergmann's Avatar
 
Join Date: Mar 2015
Location: Germany
Age: 39
Posts: 23
Quote:
Originally Posted by sbergmann View Post
I started to work on a Dockerfile for building a Docker image with this toolchain: https://github.com/sebastianbergmann...ter/Dockerfile
It's now usable, see https://amiga.sebastian-bergmann.de/...ross-compiler/ for details.
sbergmann is offline  
Old 14 March 2017, 21:47   #91
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Finally an update:

The implementation to support -fbaserel and -fbaserel32 is looking good. The libraries and examples do compile, link and run.

Just pushed my changes.

Bebbo
bebbo is offline  
Old 15 March 2017, 17:31   #92
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 46
Posts: 322
Anyone can figure out why when I run

Code:
./toolchain-m68k --prefix=/home/alex/amiga/gcc6 --gcc 6 --binutils 2.14 build
I get the following errors???

Code:
DEBUG: execute "git submodule init"
DEBUG: execute "git submodule update"
fatal: reference is not a tree: 2f126be011f78b6477fc123ba1fb0886822b97f1
fatal: reference is not a tree: 79e2eaa4195f064229a6e5376bb608332c8dcf28
Unable to checkout '2f126be011f78b6477fc123ba1fb0886822b97f1' in submodule path 'submodules/clib2'
Unable to checkout '79e2eaa4195f064229a6e5376bb608332c8dcf28' in submodule path 'submodules/libdebug'
ERROR: command "git submodule update" failed with 1
alkis is offline  
Old 15 March 2017, 18:21   #93
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
./toolchain-m68k --prefix=/home/alex/amiga/gcc6 --gcc 6 --binutils 2.14 build
Maybe you misspelled alex ^^

Nah - just kidding.

Some submodules were forked and are using now a different location. So I suggest running a manual
Code:
git pull
. If the error persists, remove the submodules then
Code:
./toolchain-m68k clean
./toolchain-m68k --prefix=/home/alex/amiga/gcc6 build
(binutils-2.14 and gcc-6 are the default options now)

Bebbo
bebbo is offline  
Old 15 March 2017, 22:36   #94
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,250
Quote:
Originally Posted by bebbo View Post
Finally an update:

The implementation to support -fbaserel and -fbaserel32 is looking good. The libraries and examples do compile, link and run.
The -fbaserel option is valuable but does anyone really use -fbaserel32? The -fbaserel32 option would cause code to be slower on 68020-68060 as it uses the full extension word format with base displacement size of 32 bits (bd32,An,Rn.Size*Scale). Not only is this addressing mode slower on every 68k CPU but the code is also larger. These relative references would be 2 bytes larger than an absolute reference (the RELOCs for the absolute references may cause the executable size to grow but they do not clog the ICache or reduce performance after the program is loaded). Of course larger is also generally slower on 68k processors. Perhaps there are sometimes where RELOCs in the executable should be avoided but I expect they are rare to non-existent on the Amiga. The -fbaserel32 option should be very low priority and any documentation should clearly state that this option (also probably -resident32) are slow and normally should be avoided.

Which other AmigaOS "unofficial" GCC features have you already added or were you planning on bringing back?
matthey is offline  
Old 15 March 2017, 22:44   #95
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
Originally Posted by matthey View Post
The -fbaserel option is valuable but does anyone really use -fbaserel32? The -fbaserel32 option would cause code to be slower on 68020-68060 as it uses the full extension word format with base displacement size of 32 bits (bd32,An,Rn.Size*Scale). Not only is this addressing mode slower on every 68k CPU but the code is also larger. These relative references would be 2 bytes larger than an absolute reference (the RELOCs for the absolute references may cause the executable size to grow but they do not clog the ICache or reduce performance after the program is loaded). Of course larger is also generally slower on 68k processors. Perhaps there are sometimes where RELOCs in the executable should be avoided but I expect they are rare to non-existent on the Amiga. The -fbaserel32 option should be very low priority and any documentation should clearly state that this option (also probably -resident32) are slow and normally should be avoided.

Which other AmigaOS "unofficial" GCC features have you already added or were you planning on bringing back?
baserel32 is no additional effort if baserel is done, plus you can create huge location independent programs, just combine it with pcrel => no reloc at all.

What features are missing?

Bebbo
bebbo is offline  
Old 16 March 2017, 00:09   #96
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,250
Quote:
Originally Posted by bebbo View Post
baserel32 is no additional effort if baserel is done, plus you can create huge location independent programs, just combine it with pcrel => no reloc at all.
As long as -fbaserel32 is very easy to implement and documented that it is slower in practically every case, then it wouldn't hurt to have it for compatibility. Do PC relative accesses out of 16 bit range (+-32kB) in the code use the 68020 (d32,PC,Rn.Size*Scale) addressing modes (easier but slower and bigger code) or convert to using absolute addressing mode with RELOCs? If GCC converts to using the faster absolute addressing mode then you are unlikely to have RELOC free programs anyway as it is more common for the code of large programs to grow past ~64kB than the static (global) variable data.

I proposed in an enhanced 68k (68kF) ISA to add shorter PC relative addressing modes for (d32,PC) and (d24,PC,Rn.Size*Scale) which could be as fast and as small as using the absolute addressing mode with RELOC. This would allow PC relative code without RELOCs in most cases but it would not be possible to add the same short encodings for (bd,An,Rn.Size*Scale).

Quote:
Originally Posted by bebbo View Post
What features are missing?
http://cahirwpz.users.sourceforge.ne...aos/index.html
matthey is offline  
Old 16 March 2017, 01:14   #97
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
So missing at the moment:

2.7 -mstackcheck
2.8 -mstackextend
2.9 -mfixedstack
2.10 -mrestore-a4
2.11 -malways-restore-a4
2.13 -frepo

3.1 chip
3.2 saveds
3.3 interrupt
3.4 stackext

Not very important to me :-)

Bebbo
bebbo is offline  
Old 21 March 2017, 10:42   #98
bebbo
Registered User

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 121
Quote:
Originally Posted by nogginthenog View Post
I don't have libnix built yet but GCC 6.2.1 produces this:

Code:
_strcpy:
        move.l a2,-(sp) |,
        move.l a0,d0    | dst, dst
        move.l a0,a2    | dst, ivtmp.11
.L2:
        move.b (a1)+,d1 | MEM[base: src_8, offset: 4294967295B], _9
        move.b d1,(a2)+ | _9, MEM[base: _14, offset: 0B]
        jne .L2 |
        move.l (sp)+,a2 |,
        rts

The current version is now producing better code for:

Code:
__attribute__((__regparm__(2))) char * strcpy(char *dst, const char *src) {
  char *ret = dst;
  while(*dst++=*src++)
    ;
  return ret;
}
m68k-amigaos-gcc -S -fomit-frame-pointer -O3 strcpy.c -o strcpy.s

Code:
_strcpy:
        move.l a0,d0
.L2:
        move.b (a1)+,d1
        move.b d1,(a0)+
        jne .L2
        rts
Still not the best code, but better than previous.
bebbo is offline  
Old 21 March 2017, 18:29   #99
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,250
Quote:
Originally Posted by bebbo View Post
Code:
_strcpy:
        move.l a0,d0
.L2:
        move.b (a1)+,d1
        move.b d1,(a0)+
        jne .L2
        rts
Still not the best code, but better than previous.
This is good enough to compete for best 68k code generation quality from any Amiga compiler ever. If the code generation was consistently this good with few bugs, it would be a miracle after all these years.
matthey is offline  
Old 21 March 2017, 18:35   #100
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 46
Posts: 322
Quote:
Originally Posted by bebbo View Post
m68k-amigaos-gcc -S -fomit-frame-pointer -O3 strcpy.c -o strcpy.s

Code:
_strcpy:
        move.l a0,d0
.L2:
        move.b (a1)+,d1
        move.b d1,(a0)+
        jne .L2
        rts
A tad better than gcc-3.4.0
Code:
#NO_APP
        .text
        .even
        .globl  _strcpy
_strcpy:
        movel a0,d1
        .even
L2:
        moveb a1@+,d0
        moveb d0,a0@+
        jne L2
        movel d1,d0
        rts
alkis is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
New GCC based dev toolchain for AmigaOS 3.x cla Coders. Releases 4 12 October 2016 22:28
Issue with photon/xxxx WinUAE Toolchain arpz Coders. Asm / Hardware 2 26 September 2015 22:33
New 68k gcc toolchain arti Coders. C/C++ 17 31 July 2015 03:59
Hannibal's WinUAE Demo Toolchain 5 Bobic Amiga scene 1 23 July 2015 21:04
From gcc to vbcc. Cowcat Coders. General 9 06 June 2014 14:45

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 12:36.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.22258 seconds with 15 queries