Help to open-source SAS/C

[wawa]

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.

[idrougge]

Indeed SAS/C had a good debugger, CodeProbe.

[gulliver]

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.

[alpine9000]

Originally Posted by gulliver

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.

[gulliver]

Originally Posted by alpine9000

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?

[wawa]

Originally Posted by gulliver

Did you enable optimisations when compiling?

i think you have missed the benchmarking in gcc6 toolchain thread?

[alpine9000]

Originally Posted by gulliver

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).

[wawa]

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.

[alpine9000]

Originally Posted by wawa

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.

[gulliver]

Originally Posted by wawa

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.

[matthey]

Originally Posted by gulliver

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.

Originally Posted by gulliver

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.

Originally Posted by alpine9000

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.

Originally Posted by alpine9000

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.

[phx]

Originally Posted by matthey

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...

[wawa]

Originally Posted by alpine9000

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]

@phx

i think options is the right thing to have

[matthey]

Originally Posted by phx

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.

Originally Posted by phx

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.

Originally Posted by phx

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.

Originally Posted by wawa

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.

[kamelito]

It may be easier to try to got the approval to open source the Manx Compiler, IIRC the version 5.2 was not bad at producing optimized 68k even if it didn't beat SAS/C.
At least there's also Bebbo improvements on GCC see http://eab.abime.net/showthread.php?t=85474&page=15