GCC 4.x or Clang for 68k

[matthey]

I have CubicIDE which has GCC 3.3 for the 68k Amiga, but I cannot find those "alpha" versions anywhere on the web anymore. The GCC-lite packages on Aminet are very good and easy to get started with but they're only 2.7.0.

Maybe you couldn't find it because Back2Roots.org has been down. It's supposed to be coming back:

http://eab.abime.net/showthread.php?t=73684

[nicholas]

 This development guide will help build an Amiga GCC 3.3.3 cross compiler on Linux or Windows XP. It is sucessfully tested this doc on RedHat Linux and Windows XP. Other tutorials used GCC 2.95 and usually ended in failed builds.  

http://aminet.net/docs/help/amiga_gcc_build_eng.pdf

This any help?

[Bif]

I do not have much experience with C++ but I do know it is popular and needed for porting other programs to the Amiga. I know it's less efficient as I have looked at the resulting disassembled executables (I see indirect branches and lots of unused code). Regular C is less complex (simpler syntax), offers most of what I need and can generate more efficient executables. Some programmers need C++ and more GCC compatibility though. A newer version of GCC or Clang would be great but it really needs a persistent effort by a knowledgeable team like the original GeekGadgets team.

C++ is not inherently less efficient than C. With equivalent quality compilers you should be able to produce the same quality of executable. Of course if you use some C++ specific features (e.g. exceptions (usually on by default) + STL library, etc.), you can find your EXEs to be larger due to all the embedded error handling, etc. But you can avoid or disable that kind of stuff. Yes there are some C++ features that come with a bit of overhead (virtuals, etc.), but nobody is forcing you to use that stuff - but when you do, it's usually for a good reason, and you would have to introduce the same indirections in non-standard ways in C code to achieve the same thing. On the other hand C++ provides additional features that can help you code things more quickly and safely (e.g. templates, etc., when used intelligently).

I point that out because at some point I want to start some projects that will run on many platforms, including the Amiga. I don't really want to go back to coding the straight C I used for the first 10 years of my life as I've spent the last 15+ years doing C++ in the game industry (where everyone else freaked out about C++ "inefficiency" when we first started using it, now everyone knows better). It does sound like the Amiga is left out in the cold in regards to modern C++ compilers, which is a bummer. GCC 2.95 was somewhat decent at handling C++ syntax but I do recall there were complaints about code quality for the platforms we used it for, and I would imagine things are similar in Amiga-land, the C++ capable compilers available probably don't generate as efficient code as some of the old well optimized C variants.

Anyway, I'm also curious to see if a more modern GCC or Clang gets supported at some point (for cross compiling, I can't imagine compiling on a 68k Amiga nor do I really want to). If not I'd probably take a quick look at it myself to see what kind of job it is, though I suspect it is a pretty big headache or somebody would have done it by now.

[bloodline]

I've managed to some degree but I just noticed that in order to build something like GNUstep (in order to get the appropriate Foundation frameworks which would make Objective-C useful on the Amiga) you need at least 2.9.5.3. Now we do have that version, but I can't help but then wish for more ObjC features that exist in the newer compilers such as blocks, automatic property synthesis, etc...

Start with ObjFW as it's a much lighter weight foundation than GNUStep!

[SamuraiCrow]

Are you sure? I run clang on both my 256meg and my 512meg Raspberry Pis

Well, running it is less demanding than building it.  Building Clang requires 2 Gigs of RAM on my x86 Mac Mini.  I think it might work on 256 megs on 68k but you'd still have to have a lot of Fast RAM to run it in its current state.

My idea for a memory system involves making each optimization pass a separate shared library and make the memory system close passes that are not currently being used so it can flush them out of memory if needed.

[matthey]

C++ is not inherently less efficient than C. With equivalent quality compilers you should be able to produce the same quality of executable. Of course if you use some C++ specific features (e.g. exceptions (usually on by default) + STL library, etc.), you can find your EXEs to be larger due to all the embedded error handling, etc. But you can avoid or disable that kind of stuff. Yes there are some C++ features that come with a bit of overhead (virtuals, etc.), but nobody is forcing you to use that stuff - but when you do, it's usually for a good reason, and you would have to introduce the same indirections in non-standard ways in C code to achieve the same thing. On the other hand C++ provides additional features that can help you code things more quickly and safely (e.g. templates, etc., when used intelligently).

I imagine some of the C++ inefficiencies can be avoided if a programmer knows what they are doing but that is even more to learn. Compilers have improved for C++ as have some high end processors which now have indirect branch prediction. Processors are now enough faster that a few percent slower code usually means waiting for the next processor to provide a speedup. I'm surprised the game industry doesn't use regular C with a library of functions, macros and assembler optimizations, at least for non-x86_64 games.

I point that out because at some point I want to start some projects that will run on many platforms, including the Amiga. I don't really want to go back to coding the straight C I used for the first 10 years of my life as I've spent the last 15+ years doing C++ in the game industry (where everyone else freaked out about C++ "inefficiency" when we first started using it, now everyone knows better). It does sound like the Amiga is left out in the cold in regards to modern C++ compilers, which is a bummer. GCC 2.95 was somewhat decent at handling C++ syntax but I do recall there were complaints about code quality for the platforms we used it for, and I would imagine things are similar in Amiga-land, the C++ capable compilers available probably don't generate as efficient code as some of the old well optimized C variants.

GCC 2.95.3 generates the most optimized integer C code of any Amiga compiler. I expect some of that would translate to C++. However, the C++ support in GCC was not very mature at that point which probably means lack of support and bugs in certain areas. The 68k code generation quality in GCC 3 deteriorated but it is more modern. C++ is quite usable. I am able to compile DOSBox with whatever changes NovaCoder made. I didn't spot any heavy C++ specific code but this program is huge and it works. The speed is lacking on even a 68060 (without 68k dynrec which is almost working) but it's slow on slower x86 hardware too. It runs fine on UAE. It was compiled using AmiDevCpp which is probably the only sane way of compiling it until we get faster 68k processors (faster 68k fpga processors than the 68060 are being developed):

http://amidevcpp.amiga-world.de/index.php?HR_LANG=english

Anyway, I'm also curious to see if a more modern GCC or Clang gets supported at some point (for cross compiling, I can't imagine compiling on a 68k Amiga nor do I really want to). If not I'd probably take a quick look at it myself to see what kind of job it is, though I suspect it is a pretty big headache or somebody would have done it by now.

GCC would probably be less work (it has better 68k support already) but a group including SamuraiCrow have done some of the work of porting Clang/LLVM to AROS. Maybe you could help them. I can help some with 68k backend stuff but I don't know C++ (even my C knowledge is limited). I have and am working on the vbcc 68k vclib and have submitted bug fixed and optimized code for vbcc including the backend. My time is rather limited right now though. Give AmiDevCpp a try until there is a better option.

[AJCopland]

I'm surprised the game industry doesn't use regular C with a library of functions, macros and assembler optimizations, at least for non-x86_64 games.

Why would we? Look everyone likes to go on about C being the fastest but that comes with the caveat that you can write fast code. C++ comes with the caveat that it's fast if you can write fast code.

If you want a good argument against C it's the Heartbleed bug, a bug that exists almost solely because of someone writing something in C for which there is no good argument to use the language.

Getting a modern C++ compiler available for the Amiga would be very useful. LLVM/CLang or GCC doesn't matter, get the compiler, optimise and bug fix it's output afterwards.

Andy <-- currently developing Unreal Engine 4, which uses quite a bit of C++ and would be  nightmare to imagine in C

[psxphill]

If you want a good argument against C it's the Heartbleed bug, a bug that exists almost solely because of someone writing something in C for which there is no good argument to use the language.

The Heartbleed bug could just as easily have been introduced if it had been written in C++. Someone who shouldn't be left unsupervised near a computer ended up writing security code that was used in everything, because "it's open source it must be good".
 
If you end up writing something in C with
 
extern myobject *alloc_myobject();
extern void func_on_myobject(myobject *x, int y);
 
then you should be using C++. Because if that is all you're using in terms of C++ features then the code generated should be pretty much the same.

[matthey]

Why would we? Look everyone likes to go on about C being the fastest but that comes with the caveat that you can write fast code. C++ comes with the caveat that it's fast if you can write fast code.

Writing fast code requires knowing what is going on under the hood, so to speak. There is more to know with C++ as it's more complex. It's kind of like a luxury car with it's conveniences but then they tend to be less reliable because of the complexity and not as fast because of the extra weight. Some of the luxuries are so nice that regular C has adopted them.

If you want a good argument against C it's the Heartbleed bug, a bug that exists almost solely because of someone writing something in C for which there is no good argument to use the language.

I tend to agree with psxphil that it's not the language but the way the security software is developed and distributed. I read an article on it. There was something like 1 paid academic type programmer with an education in security algorithms and a handful of volunteer programmers that develop the security software for most of the world. The software is used by almost everyone because it's free and popular. What could go wrong?

[AJCopland]

@pspxhill & matthey
You misunderstand, my fault as I wasn't very clear. I made the Heartbleed reference as an argument against using `C` not as a positive for using `C++` - I'd prefer to use another higher level language, maybe C# or Java, but better yet something more suited to the problem domain that is without pointers entirely.

I don't think you should use either (C/C++) for security related code and its horrific to think about all of the libraries like OpenSSL that are implemented using C.

If I had no choice but to use C or C++ then I'd pick C++ since I can at least hope to catch some of the blindingly obvious issues and deliberately avoid using raw pointers which cause most of these kinds of bugs.

The issues that people are spouting about C vs C++ here are weird, it's like stepping back to the 1990s when I started coding in C - they're outdated. You don't need to know all of C++ to use it, you use the bits you need, learn something new now and then. The same as you do with C, if I want to get as low-level as C with C++ then I do, if I don't then I don't. Nothing more too it.

I think the Amiga needs a modern version of GCC / LLVM / CLang just to disspell these myths!

So how do we go about doing that productively? Even if GCC 4.8 spews poor integer code for 68k now, that doesn't mean we have to leave it that way.

[bloodline]

I'd prefer to use another higher level language, maybe C# or Java, but better yet something more suited to the problem domain that is without pointers entirely.

Burn the heretic!!! Pointers are good. Java is a language I really dislike on so many levels, and C# I've never used... And I am unlikely to ever use it now.

C/C++ is a nice compromise between High level and low level programming languages.

If I'm going high level, I'm using Obj-C.

If I had no choice but to use C or C++ then I'd pick C++ since I can at least hope to catch some of the blindingly obvious issues and deliberately avoid using raw pointers which cause most of these kinds of bugs.

C++ is a must for any medium to large project. But I tend to mix C, C++ and Obj-C into a single project depending on the complexity of what I'm doing.

The issues that people are spouting about C vs C++ here are weird, it's like stepping back to the 1990s when I started coding in C - they're outdated. You don't need to know all of C++ to use it, you use the bits you need, learn something new now and then. The same as you do with C, if I want to get as low-level as C with C++ then I do, if I don't then I don't. Nothing more too it.

I agree. Mixing and matching is also possible, not sure how to do something in C++, do it that way you would in C... etc...

[/quote]
I think the Amiga needs a modern version of GCC / LLVM / CLang just to disspell these myths!

So how do we go about doing that productively? Even if GCC 4.8 spews poor integer code for 68k now, that doesn't mean we have to leave it that way.[/QUOTE]

[AJCopland]

I personally hate Java too. C# is I think what Java wanted to be, you know how often you have good idea and try it out but it's not right, in fact it's usually an damned ugly unworkable mess... that's Java. Then some time later you try again based on what you learnt from your first attempt and this time it's really good, not perfect but much better than before... that's C#

People go to C/C++/Obj-C or whatever then decide how to whatever it is that they had in mind. What we should be doing is deciding what our priorities are, security vs speed, and then picking the correct language for the task.

If it's speed then you still need to ask what the right language is. For Games it's probably C/C++, but for numerical analysis Fortran is probably faster. I dislike Fortran too but it might be the correct tool for the job at hand.

C/C++ are hard to write well, and even when you do you get a lot of unintentional bugs even from experienced coders. I see them every single day even from some of the worlds best developers. They're languages that are simply too error prone for a lot of tasks - a lot of that is due to pointers.

Trouble is once someone knows C they think that's it, it's the ultimate hammer, it can do anything. No one ever stops to think if they "should" be using it for everything.

[LiveForIt]

I personally hate Java too. C# is I think what Java wanted to be, you know how often you have good idea and try it out but it's not right, in fact it's usually an damned ugly unworkable mess... that's Java. Then some time later you try again based on what you learnt from your first attempt and this time it's really good, not perfect but much better than before... that's C#

People go to C/C++/Obj-C or whatever then decide how to whatever it is that they had in mind. What we should be doing is deciding what our priorities are, security vs speed, and then picking the correct language for the task.

If it's speed then you still need to ask what the right language is. For Games it's probably C/C++, but for numerical analysis Fortran is probably faster. I dislike Fortran too but it might be the correct tool for the job at hand.

C/C++ are hard to write well, and even when you do you get a lot of unintentional bugs even from experienced coders. I see them every single day even from some of the worlds best developers. They're languages that are simply too error prone for a lot of tasks - a lot of that is due to pointers.

Trouble is once someone knows C they think that's it, it's the ultimate hammer, it can do anything. No one ever stops to think if they "should" be using it for everything.

In some ways C# is useless, its not a cross platform language, it has run time enviroment but no virtual machine, so its in the same category as VB, the only upside is that C# is more like C++ then VB, so you can use C# to proto type stuff.

As you can't do so many things wrong whit C# it is relatively easy to learn language.

Down side to C# is that if you can't type #ifdef and stuff like that.
Another downside C# depends on Microsoft class libraries.

Java has virtual machine, bit like running a emulator, should work every where provided all the Java classes are supported by OS, but they are not on AmigaOS so it more or less useless.

Besides Java is slow because its not native (not the language and not the VM).

[apa]

In some ways C# is useless, its not a cross platform language, it has run time enviroment but no virtual machine, so its in the same category as VB, the only upside is that C# is more like C++ then VB, so you can use C# to proto type stuff.

As you can't do so many things wrong whit C# it is relatively easy to learn language.

Down side to C# is that if you can't type #ifdef and stuff like that.
Another downside C# depends on Microsoft class libraries.

Java has virtual machine, bit like running a emulator, should work every where provided all the Java classes are supported by OS, but they are not on AmigaOS so it more or less useless.

Besides Java is slow because its not native (not the language and not the VM).

But you can run Java on Amiga OS 4 at least. http://jamiga2.blogspot.se/. Now, back to GCC ..

[bloodline]

Trouble is once someone knows C they think that's it, it's the ultimate hammer, it can do anything. No one ever stops to think if they "should" be using it for everything.

I think the problem is that C is actually beautiful... No programming language syntax before it even came close (B and BCPL excluded)... Hence why all modern languages follow the C syntax.

C is beautiful, and those who know it understand that.

[SamuraiCrow]

In some ways C# is useless, its not a cross platform language, it has run time environment[sic] but no virtual machine, so its in the same category as VB, the only upside is that C# is more like C++ then VB, so you can use C# to proto type stuff.

As you can't do so many things wrong whit C# it is relatively easy to learn language.

Down side to C# is that if you can't type #ifdef and stuff like that.
Another downside C# depends on Microsoft class libraries.

Java has virtual machine, bit like running a emulator, should work every where provided all the Java classes are supported by OS, but they are not on AmigaOS so it more or less useless.

Besides Java is slow because its not native (not the language and not the VM).

Perhaps you've never heard of Mono?  Mono runs .NET assemblies on Linux and Mac.  Mono is under Shared Source license from Microsoft so as long as you don't care that .NET is patent encumbered, you can run C# on anything that runs Mono.  Just don't expect all the libraries that use unmanaged code from .NET to work on anything other than Windows.

Also, the latest versions of Android gut the Dalvik JVM and make it compile statically into native code at download.  I think the jAmiga JVM used on AOS 4.x has a similar way to statically compile .class files into native code as well.

Lastly, GCJ is a static Java compiler for GCC.  It depends on GNU Classpath being compiled into a shared object called LibGCJ.