English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 20 April 2017, 21:01   #21
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 859
imho better invest time in current gcc and work with it, as its being done on the other thread. maybe sas had good debugging features i dont know about and stuff, but they have been already asked and refused. maybe someone with deep insight can dig a bit deeper, but i dont believe any regular amiga fans will achieve anything there.
wawa is offline  
AdSense AdSense  
Old 20 April 2017, 21:44   #22
idrougge
Registered User
 
Join Date: Sep 2007
Location: Stockholm
Posts: 2,574
Indeed SAS/C had a good debugger, CodeProbe.
idrougge is offline  
Old 20 April 2017, 23:05   #23
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 39
Posts: 1,425
VBCC generates much more optimised code than GCC (smaller & faster). But unfortunately, most current open source software is taylored towards newer versions of GCC. Then in Amigaland much of the old open source stuff is built with SASC.

If I could pick my poison, I would try to persuade VBCC guys to tackle some current GCC 7.x and SASC 6.x compatibility modes within VBCC, so we would get the best code generation on Amiga, with the most popular compilers (GCC & SASC). Add to that the fact that VBCC is still actively developed.
gulliver is offline  
Old 20 April 2017, 23:08   #24
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 303
Quote:
Originally Posted by gulliver View Post
VBCC generates much more optimised code than GCC (smaller & faster). But unfortunately, most current open source software is taylored towards newer versions of GCC. Then in Amigaland much of the old open source stuff is built with SASC.

If I could pick my poison, I would try to persuade VBCC guys to tackle some current GCC 7.x and SASC 6.x compatibility modes within VBCC, so we would get the best code generation on Amiga, with the most popular compilers (GCC & SASC). Add to that the fact that VBCC is still actively developed.
VBCC code isn't always faster than GCC6.x.

For the game i'm working on it was at least 10% slower with vbcc.
alpine9000 is offline  
Old 20 April 2017, 23:11   #25
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 39
Posts: 1,425
Quote:
Originally Posted by alpine9000 View Post
VBCC code isn't always faster than GCC6.x.

For the game i'm working on it was at least 10% slower with vbcc.
Did you enable optimisations when compiling?
gulliver is offline  
Old 21 April 2017, 00:10   #26
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 859
Quote:
Originally Posted by gulliver View Post
Did you enable optimisations when compiling?
i think you have missed the benchmarking in gcc6 toolchain thread?
wawa is offline  
Old 21 April 2017, 01:06   #27
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 303
Quote:
Originally Posted by gulliver View Post
Did you enable optimisations when compiling?
Yes of course I did. I tried every optimisation option/combination vbcc and gcc had to offer. I spend considerable time looking for any performance increase I can get. I like vbcc, but for me it was too slow (and it's error messages/warnings are not at the same level as gcc).
alpine9000 is offline  
Old 21 April 2017, 02:54   #28
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 859
i have never really used vbcc, but i thinks its performance is an amiga myth. if i remember well, a while ago deadwood evaluated at least vasm (in a thread on this very forum) as option for aros, with the result that phx was even so kind to implement a few necessary extra features. the result was that no performance gain was to be observed, so its been dropped.
wawa is offline  
Old 21 April 2017, 03:07   #29
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 303
Quote:
Originally Posted by wawa View Post
i have never really used vbcc, but i thinks its performance is an amiga myth. if i remember well, a while ago deadwood evaluated at least vasm (in a thread on this very forum) as option for aros, with the result that phx was even so kind to implement a few necessary extra features. the result was that no performance gain was to be observed, so its been dropped.
I use vasm with my gcc port, and cannot measure any performance increase from running vasm with full or no optimisations. I guess the code gcc generates is not ripe for optimisations.

I still prefer vasm/vlink over the old versions of binutils that still have full amiga support.
alpine9000 is offline  
Old 21 April 2017, 03:07   #30
gulliver
BoingBagged

 
Join Date: Aug 2007
Location: The South of nowhere
Age: 39
Posts: 1,425
Quote:
Originally Posted by wawa View Post
i think you have missed the benchmarking in gcc6 toolchain thread?
Yes, I have missed it. It seems that fortunately things are changing for good.
I am happy to be corrected.

Will update my old GCC setup and start playing once I get some spare time.
gulliver is offline  
Old 21 April 2017, 06:24   #31
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,194
Quote:
Originally Posted by gulliver View Post
VBCC generates much more optimised code than GCC (smaller & faster). But unfortunately, most current open source software is taylored towards newer versions of GCC. Then in Amigaland much of the old open source stuff is built with SASC.
Maybe you were thinking of the vbcc PPC backend. The 68k backend has always been simplistic.

Quote:
Originally Posted by gulliver View Post
If I could pick my poison, I would try to persuade VBCC guys to tackle some current GCC 7.x and SASC 6.x compatibility modes within VBCC, so we would get the best code generation on Amiga, with the most popular compilers (GCC & SASC). Add to that the fact that VBCC is still actively developed.
Vbcc has some SAS/C features and file format compatibility (debugging format for example). The support could be improved to build libraries like SAS/C but it would probably not happen without AmigaOS 68k development restarting and then the 68k backend would need to be improved also. Perhaps some funding would persuade Volker to improve the 68k backend. As it is now, the Amiga and 68k situation leaves little incentive to do more than fixing bugs and significant bottlenecks.

Quote:
Originally Posted by alpine9000 View Post
I use vasm with my gcc port, and cannot measure any performance increase from running vasm with full or no optimisations. I guess the code gcc generates is not ripe for optimisations.
Most compilers do peephole optimizations in the compiler backend. Volker came up with the idea to simplify the backend by having the assembler do the peephole optimizing. This was only partially successful, especially on the 68k where the CCR is changed by most instructions. Adding peephole optimizations to the 68k backend where the assembler was unable to do them should provide a significant improvement in performance and code density. A good example is MOVEM.L with only one register which should be optimized to a MOVE.L in most cases.

The old GCC 68k compiler (<=3.4.0) did not do a good job of peephole optimizing but this may have changed. Each peephole optimization usually only provides a small performance improvement so it takes many to make a difference (or a few inside loops). I would expect a large variance in performance gains with most being small. Floating point code would probably show a larger improvement as GCC does not have the fp power of 2 compression optimization which vasm does and is common.

Quote:
Originally Posted by alpine9000 View Post
I still prefer vasm/vlink over the old versions of binutils that still have full amiga support.
Vbcc, vasm and vlink are much easier to install and use than GCC. Vbcc has so much potential which is not being realized for the 68k AmigaOS because of the simplistic 68k backend though.
matthey is online now  
Old 21 April 2017, 15:40   #32
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 950
Quote:
Originally Posted by matthey View Post
Vbcc has so much potential which is not being realized for the 68k AmigaOS because of the simplistic 68k backend though.
In reality vbcc's 68k backend is the most complex and sophisticated one, which can easily be seen when looking into the source. On the other hand the 68k is the most complex CPU to generate code for. The PPC instruction set is designed for compilers, which makes things easier.

A main problem with improving the 68k backend, besides Volker's limited time, is that there are not enough useful bug reports. In contrast to gcc, vbcc is only used by some Amiga developers, and maybe by a handful of Atari developers. Also keep in mind vbcc is a single-man project!

The advantage is that vbcc is small, has absolutely no dependencies and is probably one of the most portable compilers in the world. A simple ANSI-C compiler and stdio is sufficient to bring it up. And it doesn't force you to turn your Amiga into a Unix machine...
phx is offline  
Old 21 April 2017, 16:11   #33
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 859
Quote:
Originally Posted by alpine9000 View Post
I still prefer vasm/vlink over the old versions of binutils that still have full amiga support.
on aros, gcc syntax for 68k asm inlines (as opposite to separate asm .s files) is what bothers me, in fact. i would like it accepted what is standard in amiga sources, i think i mighth need to talk to bebbo about it, such a thing would be quite helpful also with aros gcc6.
wawa is offline  
Old 21 April 2017, 16:13   #34
wawa
Registered User
 
Join Date: Aug 2007
Location: berlin/germany
Posts: 859
@phx

i think options is the right thing to have
wawa is offline  
Old 21 April 2017, 19:13   #35
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,194
Quote:
Originally Posted by phx View Post
In reality vbcc's 68k backend is the most complex and sophisticated one, which can easily be seen when looking into the source. On the other hand the 68k is the most complex CPU to generate code for. The PPC instruction set is designed for compilers, which makes things easier.
A good x86/x86_64 backend is going to have similar complexity to a good 68k backend. ARM has so many variations and modes that it is not easy to support either, probably a big part of the reason why there is no ARM backend for vbcc which was originally created for embedded use. Even the PPC backend would not be so simple if supporting Altivec, non-standard FPUs, Cell, POWER, PowerPC-AS, CodePack, etc. A 68k backend is going to be more complex than average primarily due to lack of orthogonality with the An/Dn split (trade off for more CISC registers) and most instructions changing the CCR (trade off for reduced instructions and better code density). Some parts of a 68k backend are easier than most RISC processors like load/store multiple with MOVEM.L, easy 32 bit immediate handling and seamless 32 bit PC relative and absolute addressing. ISA changes could have further eased 68k compiler development but the only new (FPGA) 68k ISA is less orthogonal and offers nothing to simplify compiler development. The vbcc 68k backend has well known and long outstanding issues which have not been fixed. The issues range from simple (peephole optimizations where not possible for vasm) to very complex (loop optimization code). I expect this is a lack of incentive due to lack of new 68k hardware and/or financial encouragement.

Quote:
Originally Posted by phx View Post
A main problem with improving the 68k backend, besides Volker's limited time, is that there are not enough useful bug reports. In contrast to gcc, vbcc is only used by some Amiga developers, and maybe by a handful of Atari developers. Also keep in mind vbcc is a single-man project!
I am well aware of lack of Amiga development and users in general. There is a 68k Amiga death spiral which can only be exited by mass produced affordable Amiga hardware. Even financial incentive is likely not enough just as open sources are likely not enough to encourage 68k Amiga development.

Quote:
Originally Posted by phx View Post
The advantage is that vbcc is small, has absolutely no dependencies and is probably one of the most portable compilers in the world. A simple ANSI-C compiler and stdio is sufficient to bring it up. And it doesn't force you to turn your Amiga into a Unix machine...
There is a handful of us who love vbcc despite its flaws just like there is a handful of us who love the 68k Amiga despite its flaws. Both vbcc and the 68k Amiga had similar philosophies of being pure, efficient, modular, and small without the bloat. This philosophy is not mainstream and appears to be stalled.

Quote:
Originally Posted by wawa View Post
on aros, gcc syntax for 68k asm inlines (as opposite to separate asm .s files) is what bothers me, in fact. i would like it accepted what is standard in amiga sources, i think i might need to talk to bebbo about it, such a thing would be quite helpful also with aros gcc6.
I believe the old "unofficial" Amiga GCC versions (<=3.4.0) made some additions to the GCC inline format. I believe the GCC inline format then changed some also. I believe Clang/LLVM has adopted the same format. It is a good format. It would be helpful if vbcc/vasm supported the same format.
matthey is online now  
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
Please open source all the things wXR Amiga scene 380 14 May 2017 17:27
FBlit source now open. Samurai_Crow Coders. Asm / Hardware 30 01 December 2015 15:08
Open-source graphics library Don_Adan Coders. System 32 15 January 2013 22:15
NewsRog goes Open Source Paul News 0 04 December 2004 16:37
BlitzBasic - Is now open source Djay Amiga scene 2 08 February 2003 01:09

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 20:35.


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