gcc 7.1 for the ST series

C and PASCAL (or any other high-level languages) in here please

Moderators: exxos, simonsunnyboy, Mug UK, Zorro 2, Moderator Team

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2291
Joined: Tue Apr 13, 2004 8:24 pm
Location: Greece
Contact:

Re: gcc 7.1 for the ST series

Postby christos » Wed Sep 20, 2017 4:42 pm

I don't really get it. Someone spends his time creating a tool for his own stuff and then releases it for anyone to use and people complain. Not because it's broken or anything, but because it's not done in the way they want it.
I don't think ggn said anywhere that it's a replacement of anything. It's just a tool that you can use to cross compile your programs. If you need mintlib or anything and you need to use it with brownout then you'll obviously need to compile it yourself.
What I think you miss Thorsten is that this was never supposed to be used to compile MiNT stuff as I understand it at least. It's supposed to work for TOS and it's mostly geared towards demo and game development. If it helps people do MiNT stuff then.. great. And I don't see anyone stoping you from using whatever you want.
Last but not least, there is no applestore to tell anyone how they should create their stuff. This is still Atari.
Felix qui potuit rerum cognoscere causas.
My Atari blog

STOT Email address: stot(NoSPAM)atari(DOT)org

chicane
Atari freak
Atari freak
Posts: 67
Joined: Mon Jul 02, 2012 11:25 am
Location: Leeds, UK

Re: gcc 7.1 for the ST series

Postby chicane » Wed Sep 20, 2017 8:34 pm

I also feel compelled to add my support for ggn's work here.

I can't say I understand the details of how/why it works and whether or not this is a good thing. What I do know is that having downloaded and built the toolchain, I'm now able to produce binaries for Pole Position that show marked performance improvements over binaries produced from the same source using the (also excellent) Vincent Rivière toolchain.

This toolchain definitely works as advertised and is a welcome addition to the Atari scene as far as I'm concerned. Thanks ggn!

User avatar
shoggoth
Nature
Nature
Posts: 848
Joined: Tue Aug 01, 2006 9:21 am
Location: Halmstad, Sweden
Contact:

Re: gcc 7.1 for the ST series

Postby shoggoth » Wed Sep 20, 2017 8:47 pm

We code for our own enjoyment, in one way or another. Let's just respect that. No need to turn this into "work".
Ain't no space like PeP-space.

User avatar
leech
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Dec 01, 2015 3:26 pm

Re: gcc 7.1 for the ST series

Postby leech » Thu Sep 21, 2017 5:36 am

Curious, and by no means do I wish to offend ggn... I just find it odd for someone who knows how to make changes to bcc and yet doesn't know how to create a patch file. I can't really say much, since I have only fables a tiny bit in python and can mangle my way through bash, but generally speaking... 'git diff' will print a diff you can use as a patch file.

On that note, what are the chances any of this gets published upstream?
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (fully upgraded (soon!))
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)

m0n0
Captain Atari
Captain Atari
Posts: 417
Joined: Mon Oct 05, 2009 3:13 am

Re: gcc 7.1 for the ST series

Postby m0n0 » Fri Sep 22, 2017 5:07 pm

Hello,

ThorstenOtto wrote:you can't use *any* of the existing libraries. Everything has to be recompiled, including mintlib, gemlib, and every gnu package you can think of. I don't see any of that libraries.


That's problem doesn't kill you. As long as this is the truth, you have to deal with it.
But: does gcc7 for Atari ST compile these libraries without annoying bugs and can you run the executables with enough confidence?

Please tell me, I would like to know. As long as the result of the produced executables is unpredictable, it's not worth to recompile all that stuff.

Greets,
m0n0

ThorstenOtto
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 125
Joined: Sun Aug 03, 2014 5:54 pm

Re: gcc 7.1 for the ST series

Postby ThorstenOtto » Fri Sep 22, 2017 10:00 pm

m0n0 wrote:does gcc7 for Atari ST compile these libraries without annoying bugs


Not out of the box, but that is only because mintlib currently simply does not support it. It's partly because of differences in the elf assembler output, and partly because of newer features of gcc that have to be dealt with. But we are working on it.

m0n0 wrote:and can you run the executables with enough confidence?


The actual compiler is the same, so the final results should be comparable. But of course there have been substantial changes in the overall code generation compared to 4.6.4, and i would bet that not all have been tested for the m68k backend. Another reason why i prefer a solution that can replace the older 4.6.4 version without much changes; only recompiling existing programs will tell wether that version produces something useable.

m0n0 wrote:As long as the result of the produced executables is unpredictable, it's not worth to recompile all that stuff.


"predictable" is not the problem. Wether the compiled program works the way as before (hopefully faster) is the question ;)

BlankVector
Captain Atari
Captain Atari
Posts: 394
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: gcc 7.1 for the ST series

Postby BlankVector » Sun Sep 24, 2017 10:31 am

What a mess here!

I (Vincent Rivière) just want to say that I welcome the GCC brown edition. It is a different approach than the FreeMiNT one. And different visions of the same object lead to better understanding.

- FreeMiNT approach is the native one. Port GCC to a new operating system. Patch the linker to generate native executables, so GCC can naturally output executables for the current system. Then recompile everything with that: libraries, tools, etc. Of course the same can be achieved with a cross-compiler (my preferred method).

- Brown approach is the embedded one. Everything is cross-compiled to generic ELF. Then a post-processor is used to convert the resulting executable to native format. There are no libraries or tools on the target machine, because we don't care, we just want to run the resulting executable on the target machine.

During 15 years, GCC has only be used on Atari by FreeMiNT people. Even if FreeMiNT's GCC (including my own cross-tools) can easily produce TOS-only executables, I have the feeling that it has never been used by TOS people. Surprisingly, it seems that Brown GCC has gained immediate enthusiasm from TOS people. I can only welcome this situation, as this brings more people to GCC. And if this encourages people to write cleaner code, compatible with GCC and ELF features, that can only be a good thing.

Regarding to my m68k-atari-mint cross-tools, yes, they are currently stuck to GCC 4.6. This is just because that version is good enough for my own needs, as well as FreeMiNT people. It has been extremely hard, over the years, to get something stable. Every new version needs more work, more testing, more bug reports, more risks of regression... and finally, not much benefits. And most of all, last years I had less time to care about GCC stuff, so things stayed like that. But the most important is that I have published all my work, including full history, to GitHub: m68k-atari-mint-gcc and m68k-atari-mint-binutils-gdb. So people braver than me can continue the work with newer GCC, what is currently happening with Thorsten and MiKRO.

Regarding to a.out, even if it is *not* dead, it is more and more deprecated. Definitely, the biggest trouble I encountered when porting MiNT patches to newer binutils/GCC were upstream bugs related to a.out. This is like that: GNU people don't care about a.out anymore. So anyone still using a.out features will hit bugs, because that code is no more tested upstream. So definitely, using ELF intermediate files is the way to go. This is why Brown GCC is 1 step forward FreeMiNT GCC regarding to that issue.

On the other hand, I agree to Brown detractors, the Brown solution is not what native GCC users would expect. But it *is* the general embedded solution: executables are generated with any standard ELF tools (old GCC, new GCC, or anything else), then the post-processor converts that into the target format. So any compiler upgrade is uncorrelated from Atari stuff. Hence more simplicity.

Regarding to legal stuff, I didn't look precisely as what is (or is not) provided (I didn't even try Brown GCC myself). So I have no idea if there is a real issue or not. But basically, when you redistribute binaries, you must respect the upstream license, otherwise the upstream copyright holder (namely: the FSF) may complain. When you redistribute binaries of GPL software, the following principles are roughly enough:
- do not distribute binaries built from original sources mixed with any GPL-incompatible sources
- provide your sources if a user of your binaries asks for them
The above rules are pretty easy to respect.
Of course you are free to use any license of your choice for your own tools (i.e. brownout), with your own rules.

So basically, I just say: continue Brown GCC on your way, that's your project, as an alternative to FreeMiNT GCC. If it was a bad thing, it wouldn't be used.

BlankVector
Captain Atari
Captain Atari
Posts: 394
Joined: Wed Oct 24, 2007 7:52 pm
Location: France
Contact:

Re: gcc 7.1 for the ST series

Postby BlankVector » Sun Sep 24, 2017 2:18 pm

(sorry to be out of topic)

leech wrote:Oh, I guess Vincent's Repo isn't updated with GCC7 yet then?

Not yet. I will integrate other people's efforts on m68k-atari-mint GCC 7 when it's mature. Currently I only provide GCC 4.6.4, that one has been stable for years.

leech wrote:Granted last time I tried compiling something (QED) it couldn't find cflib, which I'm sure I have installed.

It worked for me, as I recompiled QED myself without trouble. A potential issue could have been defaults settings in my Cygwin cross-tools installer. In older versions, default installation type was set to Typical (without CFLib) while on more recent versions it is set to Full (with CFLib).

User avatar
leech
Atari Super Hero
Atari Super Hero
Posts: 851
Joined: Tue Dec 01, 2015 3:26 pm

Re: gcc 7.1 for the ST series

Postby leech » Sun Sep 24, 2017 3:27 pm

BlankVector wrote:(sorry to be out of topic)

leech wrote:Oh, I guess Vincent's Repo isn't updated with GCC7 yet then?

Not yet. I will integrate other people's efforts on m68k-atari-mint GCC 7 when it's mature. Currently I only provide GCC 4.6.4, that one has been stable for years.

leech wrote:Granted last time I tried compiling something (QED) it couldn't find cflib, which I'm sure I have installed.

It worked for me, as I recompiled QED myself without trouble. A potential issue could have been defaults settings in my Cygwin cross-tools installer. In older versions, default installation type was set to Typical (without CFLib) while on more recent versions it is set to Full (with CFLib).


I pulled it in from github. https://github.com/freemint/qed
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (fully upgraded (soon!))
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 2 guests