Overview Features Coding ApolloOS Performance Forum Downloads Products Order Contact

Welcome to the Apollo Forum

This forum is for people interested in the APOLLO CPU.
Please read the forum usage manual.
Please visit our Apollo-Discord Server for support.



All TopicsNewsPerformanceGamesDemosApolloVampireAROSWorkbenchATARIReleases
Information about the Apollo CPU and FPU.

Gcc6 Support?page  1 2 

Gregthe Canuck

Posts 274
12 Jan 2018 02:32


I see bebbo is continuing his work on reviving 68K support in gcc here: EXTERNAL LINK 
 
Is the timing right to start considering updates to his gcc port for the 68080 core? For example there are a number of new registers that could be supported.
 
Perhaps he could be bribed with a Vampire board? I would happily contribute to the cost of that.
 
Thoughts?


Steve Ferrell

Posts 424
12 Jan 2018 03:49


Might be better off giving support $$ here:

EXTERNAL LINK


Gregthe Canuck

Posts 274
12 Jan 2018 05:19


Steve -
 
Good suggestion. I have no problem sponsoring more than one compiler effort. The more the better.

I see vasm has support for Apollo core. :)  (Dec 30th, version 1.8b being the most recent)  EXTERNAL LINK 




Thierry Atheist

Posts 644
12 Jan 2018 06:09


From Steve's link.
Individual Computers wrote:
Jens Schönfeld, owner of iComp GmbH added: "More and more people are returning to the Amiga, as our numbers are showing. We're glad to give something back to the community and encourage everyone to try out your first "Hello World!".

If the text I highlighted isn't just marketing hype... that's a BIG DEAL!!!!

We absolutely need one or more assembler compilers that support ALL 68080 opcodes!


Samuel Devulder

Posts 248
12 Jan 2018 07:00


Right now, GCC6 still produce buggy code on standard 68k. Adding support for 68080 will not reduce the instability of that compiler.
 
On my daily use of C compilers for the amiga, the most stable version is gcc 2.95.3. With gcc3.2.2 and upward (including gcc6) replacing for instance the DotProduct() function by a macro to increase speed results in a executable that goes wrong (some walls become transparent).
 
On the other hand VBCC is much more stable and always produce a working executable with the same source. Speed is however bit less than GCC, but not by a large margin.


Obetto Sannala

Posts 61
12 Jan 2018 07:58


I'll contribute too if possible in any way.

gcc or vbcc with 68080 support would be really great.


Marlon Beijer

Posts 182
12 Jan 2018 21:52


Samuel Devulder wrote:

Right now, GCC6 still produce buggy code on standard 68k. Adding support for 68080 will not reduce the instability of that compiler.
   
  On my daily use of C compilers for the amiga, the most stable version is gcc 2.95.3. With gcc3.2.2 and upward (including gcc6) replacing for instance the DotProduct() function by a macro to increase speed results in a executable that goes wrong (some walls become transparent).
   
  On the other hand VBCC is much more stable and always produce a working executable with the same source. Speed is however bit less than GCC, but not by a large margin.

Reporting these bugs to bebbo is one step towards getting it on par with earlier versions. :)


Samuel Devulder

Posts 248
13 Jan 2018 11:54


I can't yet isolate a simple test-case. The optimizer spread the DotProduct() computation on a large portions of code. This bug is really hard to contain in small location .. and it exists since gcc3 (non beppo-related.) I haven't yet see what is wrong on the assembly-level. All I can identify is that with -O0 there is no trouble, but with -O3 the exe goes wrong (few transparent walls). This doesn't make it easy to spot :-/


Wawa T

Posts 695
13 Jan 2018 12:47


perhaps enabling all warnings and looking through this would help some. we have some problems with gcc6 on aros in comparison with gcc4, however if the problem appears already as early as gcc3 they are not related.


Samuel Devulder

Posts 248
13 Jan 2018 23:10


hmm.. well.. it appeared that the error came from the keyboard-chair interface (Yes that's me :-/ ). It is actually a very subtle coding error that has only impact on very clever C compilers. That's why it didn't showed up with older gcc, neither with sas/c nor with vbcc. These compilers do not perform clever optimizations and are unaffected by the bad code.
     
For information, it was a bad aliasing of variables in the code. An array of float values was accessed as integer using non-standard trick for speedup at some point earlier in the code. The float was modified, but the optimized happily reused the previous unmodified int value because it couldn't "see" the aliases between the two set of values and logically assumed that the modifications of the float values has no impact on the int values.
     
Clearly the C code was breaking the ISO standard that states that it is illegal to access the same memory location using pointers of different types. More info about aliasing trouble with optimizer on: EXTERNAL LINK 
I should'nt have blamed GCC6. The issue was me breaking the standard. My bad :-/



Steve Ferrell

Posts 424
13 Jan 2018 23:50


I'm glad you squashed that bug.  When will you have some videos for us?


Gregthe Canuck

Posts 274
21 Jan 2018 12:52


Stefan "bebbo" Franke continues to work on his 68K gcc6 port. He appears to be getting close to a working compiler. At the moment he is working on debugging his code optimizer.
 
There are a couple of developers filing some good bug reports and helping to iron out the last few issues.
 
I think now is a good time for some donations to keep Stefan motivated. He has mentioned he would like to get a working debugger as well (gdb) which would be very good.
 
Come on folks, pull out some spare change. A good base gcc compiler is important for many reasons. Let's give him some more motivation to keep going. I have done my part for now.
 
His PayPal donation link is part way down this page: EXTERNAL LINK 
 
Let's keep the party going!  :)
 
 


Mr Niding

Posts 459
21 Jan 2018 13:42


Donated 40 euros to him, with the note "Encouragement from Vampire land" ;)


OneSTone O2o

Posts 159
21 Jan 2018 20:01


Hi, on Atari side gcc 6 and 7 works nice to compile 68K code. Maybe you should make connection to Thorsten Otto and other guys working on this topic. Maybe not GCC is the problem, but the Amiga libs for GCC?

EXTERNAL LINK  EXTERNAL LINK  EXTERNAL LINK


Chris Dennett

Posts 67
22 Jan 2018 02:54


I have donated some also


Samuel Devulder

Posts 248
23 Jan 2018 08:21


no no it is amiga's gcc6 branch which has too aggressive optimizations I think. It all depends on the soft you are compiling as well. Compiler correctness is a very tough topic indeed.


E Penguin

Posts 46
25 Jan 2018 20:45


Declare it "volatile" if you're accessing a variable in a way that the compiler can't see.


Stefan "Bebbo" Franke

Posts 139
23 Jun 2019 15:47


Samuel Devulder wrote:

no no it is amiga's gcc6 branch which has too aggressive optimizations I think. It all depends on the soft you are compiling as well. Compiler correctness is a very tough topic indeed.

it's not possible to proof the code correctnes, but my current gcc 6.5.0b passes the execution torture test for 68000/68020 wiht(out) baserel(32) - 5 configurations.

Please file your problem!

There are other people coming up with concrete issues where gcc 6.5.0b created worse code than 2.95.3 which are resolved now.


Stefan "Bebbo" Franke

Posts 139
23 Jun 2019 15:48


Mr Niding wrote:

Donated 40 euros to him, with the note "Encouragement from Vampire land" ;)

Thank you, I own a Vampire since some days, but had no time yet, to test it - /sigh.

And thanks again


Stefan "Bebbo" Franke

Posts 139
23 Jun 2019 15:50


Chris Dennett wrote:

I have donated some also

Thank you Sir!

posts 24page  1 2