|
---|
| | 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 142 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 142 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 142 23 Jun 2019 15:50
| Chris Dennett wrote:
| I have donated some also
|
Thank you Sir!
| |
|