View Single Post
Old 17 September 2015, 07:57   #177
Registered User
Join Date: Jan 2010
Location: Kansas
Posts: 873
Originally Posted by ReadOnlyCat View Post
Basic as in ...?
I'm not sure what you mean by that. Could you elaborate?
Basic as in simple, not highly refined, not perfected, rough around the edges, etc. What is there is for the most part good and correct. However, Dr. Volker Barthelmann had this idea that a good portion of the complexity of the compiler backend could be removed by letting the assembler do the peephole optimizations. This was a good idea and he found Frank Wille's optimizing assembler vasm to use with vbcc but it doesn't work as well on the 68k where CC flag changes of most instructions occur. Only 100% safe peephole optimizations are done by default (the only useful option for a compiler). A good example is MOVEM.L which will be generated when loading/storing registers even if only 1 register is in the list. VASM is expected to peephole optimize:

MOVEM.L Dn,-(sp) -> MOVE.L Dn,-(sp)
MOVEM.L (sp)+,Dn -> MOVE.L (sp)+,Dn

But it can't because the CC is unnaffected in the MOVEM.L cases and set according to Dn for MOVE.L. Vasm can and does do the peephole optimization in some cases with address registers because the CC is unaffected in either case.

MOVEM.L (sp)+,An -> MOVE.L (sp)+,An

Adding the extra needed complexity to the vbcc 68k backend has not been done for a long time which I assume is because its not a priority. I'm not criticizing because a backend is some of the most complex code I have seen and has to be nearly perfect. Also, Volker has done most of the tedious backend work for most CPU targets himself. The 68k backend just needs that last effort to make it great. It has the potential to be great but what is the incentive and priority for an old retro CPU?

A compiler backend is a very important part of code output quality. Here is my opinion of the different parts of vbcc responsible for 68k code generation quality.

vbcc frontend (not CPU or OS dependent) - good
vbcc 68k backend output - average
vbcc/vclib link libraries written in C - average (compiled by vbcc)
vbcc/vclib link libraries written in 68k assembler - very good
vbcc assembler inlines in include files (default) - very good
vasm peephole optimizing - excellent
vbcc instruction scheduler - doesn't exist (most important for 68040+)

Vbcc will do some sophisticated, innovative and amazing things and other times it will make me cry. It has improved a lot over the years but development moves at Amiga pace (which does have a few advantages).

Originally Posted by ReadOnlyCat View Post
Tools, frameworks, compiler backends, convenience-non-accelerating hardware (CF HD, Network, etc.) are coming, the retro movement brings new users, it is not going to be explosively fast but if everyone does their part of the job there will be an Amiga market eventually as long as the historically significant machines are targeted. (Retro fans do not care about new hardware by definition unless it is spec-identical to the original one.)
The new FPGA hardware is exciting but taking a long time to improve. It would be better if there was more cooperation and sharing. I agree that many existing Amiga users will wait until FPGA hardware is as good or better spec than what they have but there is some potential to bring back old Amiga users who can now easily buy almost reasonably priced hardware and possibly a few retro computer geeks. An upgraded classic Amiga is more usable than most retro computers.
matthey is offline  
Page generated in 0.08441 seconds with 9 queries