gcc 7.1 for the ST series

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

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

User avatar
christos
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2341
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: 72
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: 900
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: 950
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: 419
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
Captain Atari
Captain Atari
Posts: 272
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: 437
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.
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

BlankVector
Captain Atari
Captain Atari
Posts: 437
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).
Subscribe to my new channel Vretrocomputing on YouTube and Facebook.

User avatar
leech
Atari Super Hero
Atari Super Hero
Posts: 950
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)

PeterS
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 149
Joined: Fri Nov 09, 2007 1:53 pm
Location: England, GB

Re: gcc 7.1 for the ST series

Postby PeterS » Sat Dec 16, 2017 11:25 am

I have started playing with a little app I wrote in 2010. I thought I might see if I could work out how to build it with gcc 7 and the Brown tools but I see it is Windos only and I was hoping for a native Atari version.

I know most builds are slow even on the 060 machines but my app is tiny and takes less than 30sec to build and link.

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Thu Feb 08, 2018 2:13 am

Ran into a couple of issues with the script building on a Solaris machine: sudo needs to default to pfexec on Solaris and make needs to default to gmake to use GNU make instead of Sun's make. Other than that it seems to be compiling GCC fine - at least so far!

User avatar
metalages
Obsessive compulsive Atari behavior
Obsessive compulsive Atari behavior
Posts: 101
Joined: Thu Jun 06, 2013 5:14 pm
Location: France
Contact:

Re: gcc 7.1 for the ST series

Postby metalages » Thu Feb 08, 2018 7:32 am

Do you think it would be possible to share a portable virtual box image with all the setup correctly done ?

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

Re: gcc 7.1 for the ST series

Postby leech » Thu Feb 15, 2018 1:03 am

A docker could be useful.
Atari 8Bits: 800xl, 600xl, XEGS, 800, 130xe, 130xe (fully upgraded (soon!))
Atari STs: 1040STf (broken shifter), 1040STe, Mega STe, TT030, Falcon (CT60e, SuperVidel)

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Thu Feb 15, 2018 2:19 am

Anyone have a link to the CVS mintlib? The Git one doesn't cooperate when building from source.

mikro
Atari God
Atari God
Posts: 1490
Joined: Sat Sep 10, 2005 11:11 am
Location: Kosice, Slovakia
Contact:

Re: gcc 7.1 for the ST series

Postby mikro » Thu Feb 15, 2018 5:48 am

LuigiThirty wrote:Anyone have a link to the CVS mintlib? The Git one doesn't cooperate when building from source.

Huh? Can you elaborate? The github mintlib repository is automatically built after each commit so I'm pretty sure it does build.

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Thu Feb 15, 2018 7:16 am

I meant for use with the brown build scripts :) They reformat the source for use with gas or something, so they expect a specific mintlib source archive.

ThorstenOtto
Captain Atari
Captain Atari
Posts: 272
Joined: Sun Aug 03, 2014 5:54 pm

Re: gcc 7.1 for the ST series

Postby ThorstenOtto » Thu Feb 15, 2018 1:04 pm

Why use the brown gcc? You can just use the usual cross-compiler from Vincents site. If you need a newer compiler version, you can try http://tho-otto.de/crossmint.php. The main key feature of the brown toolchain, using link-time optimization, does not work for mintlib.

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Thu Feb 15, 2018 1:58 pm

I wasnt aware of your site. I’ll give your GCC 7.2 a go.

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Thu Feb 15, 2018 7:02 pm

Hey, is there a problem switching --enable-decimal-float to --disable-decimal-float in your GCC build script? I'm building on a SPARC target which doesn't support decimal float. I won't know the results for a while, so I figure I'd ask too.

ThorstenOtto
Captain Atari
Captain Atari
Posts: 272
Joined: Sun Aug 03, 2014 5:54 pm

Re: gcc 7.1 for the ST series

Postby ThorstenOtto » Fri Feb 16, 2018 12:30 am

LuigiThirty wrote:Hey, is there a problem switching --enable-decimal-float to --disable-decimal-float in your GCC build script? I'm building on a SPARC target which doesn't support decimal float. I won't know the results for a while, so I figure I'd ask too.


Unless you try to compile some Atari program with the resulting compiler that needs decimal floats, that shouldn't be a problem. But it shouldn't be necessary, the host does not have to support that to enable that switch.

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Fri Feb 16, 2018 2:17 am

ThorstenOtto wrote:
LuigiThirty wrote:Hey, is there a problem switching --enable-decimal-float to --disable-decimal-float in your GCC build script? I'm building on a SPARC target which doesn't support decimal float. I won't know the results for a while, so I figure I'd ask too.


Unless you try to compile some Atari program with the resulting compiler that needs decimal floats, that shouldn't be a problem. But it shouldn't be necessary, the host does not have to support that to enable that switch.


It refused to build saying my host compiler didn't support decimal floats until I disabled it. :shrug:

ThorstenOtto
Captain Atari
Captain Atari
Posts: 272
Joined: Sun Aug 03, 2014 5:54 pm

Re: gcc 7.1 for the ST series

Postby ThorstenOtto » Fri Feb 16, 2018 12:20 pm

Never looked into that, but it's a bit strange, considering that this is a cross-compiler. Ie.when that feature was first introduced, the previous gcc used to build the new gcc didn't have support for decimal floats, either. But actually, i've not yet seen any software that really needs this feature.

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Sat Feb 17, 2018 7:55 am

I got GCC 7.2 working and built some hello world applications! Awsome!

I'm adapting my Pure-C GEM game source over to Mintlib and GEMlib. Having some trouble with crashes though, and being without the Pure-C debugger is a pain. Is it possible to get symbolic debugging going with a TOS application built in GCC? Or are my chances dire enough that I should keep working on my homemade GDB stub for TOS?

ThorstenOtto
Captain Atari
Captain Atari
Posts: 272
Joined: Sun Aug 03, 2014 5:54 pm

Re: gcc 7.1 for the ST series

Postby ThorstenOtto » Sat Feb 17, 2018 11:33 am

LuigiThirty wrote:Having some trouble with crashes though


Most common problem when switching from Pure-C to gcc in GEM programs is that you need to declare most variables as short instead of int. Turning warnings on with -Wall (and fixing reported problems of course) might help.

LuigiThirty wrote:Is it possible to get symbolic debugging going with a TOS application built in GCC?


If you mean to generate the debug information that PD needs: no that's not possible, unless someone reverse-engineers the format that PD needs, and implements that in GCC. You can generate other debug information in gcc of course, but unfortunately that does not help much because gdb for MiNT is in a poor state, and does not work at all most of the time.

Or are my chances dire enough that I should keep working on my homemade GDB stub for TOS?


Which stub, and what does it do?

LuigiThirty
Atari maniac
Atari maniac
Posts: 75
Joined: Sat Sep 03, 2016 12:20 am

Re: gcc 7.1 for the ST series

Postby LuigiThirty » Sat Feb 17, 2018 7:05 pm

I started writing a GDB stub that's linkable with TOS applications. (It's also in Pure-C and its assembler format so I'll need to adapt it to GCC and GAS...) So far it hooks the bus error, address error, and illegal instruction vectors and dumps the 68K registers to the screen when it crashes. At that point you can connect to the ST over RS-232 with GDB and examine registers and read/write memory. That's about it so far.


Social Media

     

Return to “C / PASCAL etc.”

Who is online

Users browsing this forum: No registered users and 3 guests