Amiga.org
Amiga computer related discussion => Amiga Software Issues and Discussion => Topic started by: neofree on August 19, 2010, 01:41:06 AM
-
Note sure if this is the right site/forum, but thought I'd get some opinion...
What is the best C compiler for Amiga?
I'm not sure if any of them make it easier to design GUI interfaces, but that would be a plus. My app would only need simple GUI but still would need it.
Free is preferable, but I'm also not going to settle for free when the pay version is so much better..
Serial I/O is a key thing, so if one has notably better serial functions that would be helpful to know.
Thanks!
Neofree
-
Oh I forgot to mention that the target platform is preferably ALL Amiga's, but if it makes a difference I'd rather it work on classics. (1.3-3.1) If the program will run in a WB compatibility mode on 4.x then that's fine with me. I will probably never have anything other then classic hardware...
-
If you have a PC running Windows, I'd recommend AmiDevCpp.
http://amidevcpp.amiga-world.de/aboutamidevcpp.php?HR_LANG=english
-
If you are planning to debug your software then you want to use the SASC fully Amigatized C compiler. You can debug your code on a single Amiga using the GUI Source Level debugger or you can debug it from another Amiga across the serial port using the GUI source level debugger.
If you do not care about debugging then use VBCC.
Matt can give you more detailed infos
/me casts Summon Matt Hey
Matt Hey suddenly appears in a puff of mystical smoke :)
-
If you have a PC running Windows, I'd recommend AmiDevCpp.
http://amidevcpp.amiga-world.de/aboutamidevcpp.php?HR_LANG=english
I couldn't really get on with AmiDev (too buggy), I'm currently trying to setup Eclipse CDT with gcc (cross-compiler), looking good (so far).
If you want to code on a real Amiga instead then I'd recommend either CubicIDE or StormC V4 (which also has a GUI editor called StormWizard, which is now open source).
Anyway....have fun!
-
Don't care too much about the debugging...
The compiler needs to support Stock/Original Amiga 500 targets (68000/1.x/512k+ RAM)... Since all I have is the above mentioned target right now, it will either need to be a Windows (such as the first one mentioned here) compiler, or something else...
edit: NovaCoder - missed your reply when I wrote this -.. Will CubicIDE or StormC (sounds familiar) run on A500? I'm building a 2meg/IDE upgrade to help there..
Thanks,
Neofree
-
Don't care too much about the debugging...
The compiler needs to support Stock/Original Amiga 500 targets (68000/1.x/512k+ RAM)... Since all I have is the above mentioned target right now, it will either need to be a Windows (such as the first one mentioned here) compiler, or something else...
edit: NovaCoder - missed your reply when I wrote this -.. Will CubicIDE or StormC (sounds familiar) run on A500? I'm building a 2meg/IDE upgrade to help there..
Thanks,
Neofree
Hiya,
Unless you have a RTG Amiga, you're better coding on a PC if you're after a decent IDE.
Basically for win32 native coding you either have AmiDevCPP or some other IDE using gcc (eg Eclipse). If you want to code using WinUAE or have an RTG Amiga then you're looking at CubicIDE or StormV4.
-
What about a simple editor and a command line compiler?
Will anything like that run on an A500?
Thanks
-
What was the standard compiler for A2000 back in the day? Certainly it had a compiler available for purchase?
I don't care about MUI, RTG, etc. I prefer original A500/A2000 (and A3000) computers ... If I want to keep upgrading an Amiga to be modern I might as well use a PC (which I have several).
-
SAS/Lattice was the best compiler if you don't need an IDE. I used an ASCII text editor and the command line to develop my programs and it wasn't bad at all.
I was able to cram the compiler and all my tools onto one floppy disk. Booted Workbench on DF0: and ran the compiler from DF1:
I compiled my programs to RAM: which greatly speeded up the compile and link process.
-
Nobody into Cubic IDE? It is commercial and still available, have powerful cross-compiler but I think it is not 1.3~2.x friendly, nor have an enhanced debug tool. But it is the latest available commercial compiler.
-
Sounds to me like neofree is looking for a retro environment to develop his software and wants to target Amigas running WB 1.2 thru 3.1. He isn't looking for the latest commercial compiler. Just a good, solid compiler that works from a command prompt and produces small, fast programs. SAS/Lattice is it unless he wants to try Aztec C.
-
SAS/Lattice was the best compiler if you don't need an IDE. I used an ASCII text editor and the command line to develop my programs and it wasn't bad at all.
I was able to cram the compiler and all my tools onto one floppy disk. Booted Workbench on DF0: and ran the compiler from DF1:
I compiled my programs to RAM: which greatly speeded up the compile and link process.
I had a two-floppy boot set that would create a RAD: disk with a full workbench install and compiler set. Ran completely from the 4MB RAM on my A2000 ;-)
Back on topic,
I did most of my stuff on Lattice C, later SAS/C which has kept on working great from a stock A2000 (ks1.3) to my recently acquired A4000 (ks3.1/3.9). The latest patches even provide for PowerPC builds for the Cyberstorm cards, I tried it and works great. The last versions (6.5.something) even include a basic editor / shot at an IDE. Never used that though, always worked with MicroEmacs or CygnusEd for programming, and doing compiles / makes from AmigaDOS.
I also have several other native-Amiga compilers... think Aztec C and Maxon C++. If you need documentation for any of them, I have the official retail versions and can have a look if I can digitize them somehow...
-
@mousehouse
If the Maxon C++ documentation contains more information than the help file does then I would be interested in a copy of it please.
Dave G :cool:
-
I couldn't really get on with AmiDev (too buggy),
I often see people posting that AmiDevCpp is buggy, but I dont get much bug reports from the people that are actually using it (DaveAE / AudioEvolution, Jahc / WookieChat etc.)
So would you please post proper bug reports or stop calling it buggy ?
-
What about a simple editor and a command line compiler?
Will anything like that run on an A500?
Thanks
SASC FTW!
I had a hard drive on my A500, A2000, A3000, A4000 and A1200 computers. I assume you do too?
-
What was the standard compiler for A2000 back in the day? Certainly it had a compiler available for purchase?
It was called Lattice C, which was later renamed to SAS/C.
SAS/C is just an improved version of Lattice C with MegaDebugger + other utils.
I don't care about MUI, RTG, etc. I prefer original A500/A2000 (and A3000) computers ... If I want to keep upgrading an Amiga to be modern I might as well use a PC (which I have several).
You sound exactly like me. This means our brainwaves are oscillating at the same frequency. :) I Love my SASC so logically you will too :)
I have compiled many exes with it for OS 1.2, 1.3, 2.04, 3.0. Works a treat.
It comes with a text editor which works together with the compiler. Isn't that what they call an IDE?
But I am oldskool, I use CED + AmigaDos because I am too lazy to install the Arexx scripts to autolink CED and the compiler together.
-
@mousehouse
If the Maxon C++ documentation contains more information than the help file does then I would be interested in a copy of it please.
Dave G :cool:
I need to dig into a few boxes, if I don't get back to you next week please remind me ;-)
-
@mousehouse
No hurry and thanks.
Dave G :cool:
-
I have an extra copy of SASC, the last version, that I would be willing to sell with the printed manual binders, but I would have to check to see if the floppy disks are still readable after all this time.
-
What is the best C compiler for Amiga?
I had SAS/C and used it on my a500, I had a 250mb hard drive, 6mb of ram and a 28mhz 68000 though.
Later when I moved to an A1200 (2gb hard drive, 48mb of ram and a 50mhz 68030) I found that the geekgadgets fork of gcc produced better code. I suspect that using a cross compiler on the PC is probably equivalent, you'll be able to most of your testing under WinUAE. Which will save you alot of time.
Your first choice will have to be based on target hardware. If you want to be able to run on Kickstart 1.3 then boopsi/MUI is out of the window. IIRC There was a gadtools for 1.3, but I never did any coding with it (or the 2.x+ version). I just remember a hard drive partitioning utility that came with it.
Otherwise you're limited to intuition or doing your own thing, intuition isn't actually that good. Which is why so much software opened it's own screen and had it's own look.
Serial port access should be possible on any Amiga compatible compiler. Either direct hardware banging or accessing through a device. A device is better because it will work if you have extra serial ports. Although you probably don't want to use the commodore supplied serial.device, there are much more optimised ones that I used back in the day (aminet should have them).
I would have thought there was a gdb based debugger you can use. However depending on what you're talking to on the serial port, you might find that debugging changes timing that will affect how your software works anyway. With anything realtime you're better off logging out data and then analysing it.
-
How does DICE compare?
I've still got the stripped down version given away by Amiga Shopper many moons ago - the disks are still in their cellotaped plastic bags :shocked:
-
I often see people posting that AmiDevCpp is buggy, but I dont get much bug reports from the people that are actually using it (DaveAE / AudioEvolution, Jahc / WookieChat etc.)
So would you please post proper bug reports or stop calling it buggy ?
-
Nobody into Cubic IDE? It is commercial and still available, have powerful cross-compiler but I think it is not 1.3~2.x friendly, nor have an enhanced debug tool. But it is the latest available commercial compiler.
Cubic IDE isn't a compiler.
-
Hiya,
Unless you have a RTG Amiga, you're better coding on a PC if you're after a decent IDE.
Basically for win32 native coding you either have AmiDevCPP or some other IDE using gcc (eg Eclipse).
How well do these run under a real operating system using WINE?
-
@Hardlink
The trouble with gcc is that each new version creates noticeably worse code. So for many years now it has been rather ridiculous.
So if you want decent code compiled then you need to either use some old gcc from 1990s such as gcc v2.95 or SASC 6.5 or VBCC.
Good luck :)
-
If you do not care about debugging then use VBCC.
Matt can give you more detailed infos
/me casts Summon Matt Hey
Matt Hey suddenly appears in a puff of mystical smoke :)
That mystical smoke really lingers ;). I think this is more your territory anyway. SAS/C is the fastest and one of the best development environment for a low end Amiga. He should not use any of the funky SAS/C functions to maintain portability and should test with VBCC from time to time to make sure his program compiles with both. VBCC is portable, easy to install, currently supported and free so it's the logical choice for portability. It is bigger, slower and does not have a debugger made for it as compared to SAS/C. Here's the link to VBCC...
http://sun.hasenbraten.de/vbcc/
-
My magic is getting a bit rusty and slow :D
-
I was using Lattice on a A2000/3mb.. then later SAS/C 6.5 (I think) on my 2000/2630/5mb. As far as I remember always with CygnusED in which I had some macros to call the compiler.
As far as I know the original Amiga OS (certainly up to 3.1) was actually compiled under Lattice.
Tried Maxon... didnt like it. Never used anything newer then SAS though
ta
Tom UK
-
Thanks for all your comments!
I want to try a lower end compiler first.. Coding on the A500 might be counterproductive but I want to try it first. If I feel the need to use WinUAE or Windows I'll look at some better options.
Does anyone know where I can get Lattice or SAS/C cheap? Or is it freeware now?
Thanks,
Neofree
-
SAS/C is freeware....you can get it over from the EAB file server (I think).
- note I just got Eclipse CDT working with gcc and Cygwin (only took me 3 days), now where's that cross compiler ;)
-
You can get SAS version 6 here: http://www.pictureinthesky.net/appinfo.php?id=65
You can get all the updates and patches here: http://aminet.net/search?f=2&path=biz/patch&start=200
-
I use SAS/C 6.5x under CubicIDE on AmigaOS 4.1 for compiling classic stuff and find SAS/C the best of what's available. I also set up a 3.1 debug environment on eUAE for the debugging part if various printf()'s aren't enough. I have the complete SAS package plus books, so that helps. The IDE with SAS is OK but really dated now in my opinion. It is fine if you actually develop on the classic too, though.
If you are using the classic hardware to compile, you are much better off with a hard drive at least. It is a nightmare otherwise and SLOWWWWW.
-
If you are using the classic hardware to compile, you are much better off with a hard drive at least. It is a nightmare otherwise and SLOWWWWW.
I agree. A bare minimum of 4 MB Fast ram + a Hard drive is needed else the compile process goes 10x to 100x slower than it could.
-
I created a Harddrive installation of SASC v6.58 many moons ago because so many people at the time seemed to have a lot of trouble installing the patches.
I attached the necessary assignments to the end of one of the readme files in the root directory
So cut and paste that into your user-startup OR attach it to a Project Icon via IconX or what have you OR create a file could IWANTC place it in the C: directory protect it with the s flag and open a shell and type IWANTC prior to using SASC
Just remember, whatever you do, the assigns will need to be altered to paths logical with your set up...
Where to get it? I think there is a copy of it on one of the EAB servers or similair... I uploaded it as a lzx but it was converted to a zip file... HOW TYPICAL LOL
-
I tried Eclipse and realised that I am not compatible to the way it works, So no I really dont wont to use that. I thought about Code:Blocks.
-
SAS/C is freeware.
Since when?
-
I often see people posting that AmiDevCpp is buggy, but I dont get much bug reports from the people that are actually using it (DaveAE / AudioEvolution, Jahc / WookieChat etc.)
So would you please post proper bug reports or stop calling it buggy ?
It's fair enough to discuss any issues that you have with a program, but no need for rudeness.
When choosing an IDE, I would probably go for HiSoft C, because I have such a fondness for DevPac's IDE. I imagine that they're similar
I recently purchased the Amiga OS3.5 Developer CD V2.1 which contains Haage&Partner's Storm C.
I'm looking forward to trying that out.
-
.. and just to complete this thread, I do all my Amiga 3.x development using the AROS cross-compilation SDK under Linux, using a GDB stub + serial port combination to debug my apps/drivers on both real hardware and E-UAE.
(I'm heavily mentally invested in the bash+vi+make+gdb development model..)
-
Ezerec?
Can you write up how you (or point somewhere that describes how to) use GDB to debug? I'd love to give it a try. I use Eclipse's CDT which uses GCC, so, in theory I should be able to use GDB similarly...
Just a request. :)
-
Ezerec?
Can you write up how you (or point somewhere that describes how to) use GDB to debug? I'd love to give it a try. I use Eclipse's CDT which uses GCC, so, in theory I should be able to use GDB similarly...
Just a request. :)
Well, the two key parts are C:GDBStub (sources in AROS/arch/m68k-amiga/c/gdbstub.c (https://gitorious.org/aros/aros/raw/b6d1cd6412894303d5f883e2f9c191af32a15194:AROS/arch/m68k-amiga/c/gdbstub.c)), which causes a serial port based GDB stub to activate on a trap, and the m68k-aros-gdb from the AROS m68k SDK on Linux.
To debug, I compile a driver/app first as an ELF binary, then use the AROS elf2hunk utility to convert it to AmigaOS 3.1 compatible hunk style.
Also, I modify my driver/app to have a 'asm volatile ("trap #1")' as the first thing to do in my main() (or equivalent).
I copy the HUNK version to AmigaOS 3.1, then RUN C:GDBStub before running my driver/app.
On the Linux side, I use:
$ m68k-aros-nm myapp.elf | grep main
-- this gets me the address of the main routine --
$ m68k-aros-objdump -h myapp.elf
-- this gets me the segment names and their HUNK load order.
$ m68k-aros-gdb
> target /dev/ttyS0 115200
> x /i $pc
-- This gets me the address of the 'trap #1', and allows me to figure out the offset 'text_offset' that the AmigaOS decided to load main() at)
> add-symbol-file myapp.elf 'text_offset'
-- Now I have the text of my program. If I don't need any .data or .bss debugging, I'm done here.
-- For app debugging, I do something like:
> set $segarray=((struct Process *)((*((struct ExecBase **)4))->ThisTask))->pr_SegList)<<2;
-- That's the address of my app's seglist array
> set $seglist=(($segarray+5*4)<<2)
-- And that's the seglist.
-- You can walk the seglist as per usual to discover the additional segment offsets, using the HUNK load order from 'objdump'
> add-symbol-file myapp.elf 'text_offset' -s .data 'data_offset' -s .rodata 'rodata_offset' ...
Of course, you could use SegTracker, or some other thing, to assist in this process.
-
Ezrec, can I ask what C and C++ standard libraries you are using?
I've built GCC 4.8.2 and the binutils for m68k-elf cross target, but from what I gather there was never an m68k-amigaos port of glibc, and I can't seem to find the last version of libstdc++ that still targeted m68k-amigaos, making my 4.8.2 build less useful. Any pointers?
-
Thanks, Ezrec, I'll give it a shot if I can find the time. :)
-
I couldn't really get on with AmiDev (too buggy), I'm currently trying to setup Eclipse CDT with gcc (cross-compiler), looking good (so far).!
You can try CodeBlock on Linux / Windows.
It's really easy to set a toolchain with CodeBlock.
This is my solution on Windows:
1) install AmiDev ( just to have amiga cross compilers installed on Windows)
2) configure CodeBlock in order to use the amiga cross compilers provided by AmiDev
-
The Atari guys have ported GCC 6.2 to 68k. :)
http://d-bug.mooo.com/beyondbrown/post/gcc-6/
-
SAS/C is freeware....you can get it over from the EAB file server (I think).
- note I just got Eclipse CDT working with gcc and Cygwin (only took me 3 days), now where's that cross compiler ;)
Is this actually freeware now?
-
The Atari guys have ported GCC 6.2 to 68k. :)
Just a bunch of hackers ;)
-
Is this actually freeware now?
No, SAS/C isn't free nor is it open source... sadly...
-
Well guess I try to get a copy through one of the sale sites then. I used to own it too... long ago back in the early 90's but sold it with everything :/
Stooooopid me!
-
The Atari guys have ported GCC 6.2 to 68k. :)
http://d-bug.mooo.com/beyondbrown/post/gcc-6/
we have 6.1.0 on aros, still there are some issues with it sometimes especially on 68k, im trying to locate;). usually it is amiga specific stuff, like third party mui code, with all its specifics that gets accidenatlly optimized away.
-
You can try CodeBlock on Linux / Windows.
btw thanks for resurrecting this thread, probably a valuable info on using gdb with an aros/amiga/68k, from jason/ ezrec further above. probably something i was looking for all the time.
-
Just a bunch of hackers ;)
Yes, they'll never amount to anything and their code will be rubbish because they didn't get paid for doing it. ;)
-
we have 6.1.0 on aros, still there are some issues with it sometimes especially on 68k, im trying to locate;). usually it is amiga specific stuff, like third party mui code, with all its specifics that gets accidenatlly optimized away.
Might be worth getting in touch with the Atari guys and collaborating where possible?
PS: Have you tried setting up a Godbolt server on Linux to use the aros-68k-cross-compiler to help find the optimization bugs?
http://godbolt.org
-
Yes, they'll never amount to anything and their code will be rubbish because they didn't get paid for doing it. ;)
Actually, the 68K code generator of recent gcc versions *is* rubbish.
It's a clear demonstration of the open source problem: Instead of keeping the brilliantly working and well tested code generator of the 2.95 release active and try to get it working with a compatibility layer, the whole compiler was turned upside down. Certainly on good purpose, as to support more recent architectures, but that broke the entire lower layer which was, actually, no longer properly tested and checked.
Yes, the new code might be all polished, nicer, easier to maintain, supports C++ in its latest version, and C99 ... but just doesn't work brilliantly on old platforms, sorry.
-
It's a clear demonstration of the open source problem: Instead of keeping the brilliantly working and well tested code generator of the 2.95 release active and try to get it working with a compatibility layer, the whole compiler was turned upside down.
That is NOT the problem, people are the problem. People are ALWAYS the problem. This is like blaming the goto statement for making a mess of things, while the programmer made a mess of things (it's ALWAYS the programmer's fault).
They didn't have to turn everything upside down, they choose to.
Yes, the new code might be all polished, nicer, easier to maintain, supports C++ in its latest version, and C99 ... but just doesn't work brilliantly on old platforms, sorry.
I'm surprised it still supports 68k at all.
-
Yes, the new code might be all polished, nicer, easier to maintain, supports C++ in its latest version, and C99 ... but just doesn't work brilliantly on old platforms, sorry.
You have data to back this up? Debian/m68k is using gcc6 and they have built around 10k of packages now, as well as the kernel, glibc etc. using newer gcc (currently gcc-6.2 I think).
-
I'm surprised it still supports 68k at all.
m68k as embedded platform is still a commercial thing. But most of all this has to do with the ColdFire CPUs, and how gcc etc treats ColdFire and m68k as the same "family" of architectures. Improvements done for CF are most often also done for m68k.
-
Actually, the 68K code generator of recent gcc versions *is* rubbish.
It's a clear demonstration of the open source problem: Instead of keeping the brilliantly working and well tested code generator of the 2.95 release active and try to get it working with a compatibility layer, the whole compiler was turned upside down. Certainly on good purpose, as to support more recent architectures, but that broke the entire lower layer which was, actually, no longer properly tested and checked.
Yes, the new code might be all polished, nicer, easier to maintain, supports C++ in its latest version, and C99 ... but just doesn't work brilliantly on old platforms, sorry.
So you've heavily used GCC 6.2 on 68k to write C++14 code?
And even if what you say is true, why is this an "open source problem"? Does the latest MSVC++ compiler spit out 8086 real mode code that is as good as a 20yr older version? If not, why? " Closed source problem "? Nope, just technology moving on and getting left behind.