Welcome, Guest. Please login or register.

Author Topic: Still C compiler selection hints...  (Read 2875 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline Joloo

Re: Still C compiler selection hints...
« on: February 28, 2010, 10:58:11 AM »
Quote from: ChaosLord;545228
The best C compiler is SASC.  Use the best.  Forget the rest.


Define 'best' compiler!?!

Is it that one, which allows to compile source codes in no time, or is it that one, which creates executables as optimised as code written in assembler, or, which creates executables of similar size like code written in assembler, or is the best C-compiler that one, which runs even fine with a stack size of only 4096 bytes while compiling, or is that one, which conforms to strict ANSI C & C++, or that one, which allows all the features, that makes gcc so incompatible, or is it that one, which does not need lots of RAM while compiling, or is it that one which supports different targets (operating systems and CPUs), or is it that one, which is well integrated into the host OS, or is it that one, which has got everything ever needed in its C-runtime library, or is it that one, which can cross-compile?

As you can see, I have a clear opinion of what I would call a 'best' compiler.
And SAS/C is farer away of that than I of the moon, IMHO. :)
Besides, there isn't a best compiler for me but just a compiler that fits better my needs than others.
SAS/C suits your needs, mine it does not.
 

Offline Joloo

Re: Still C compiler selection hints...
« Reply #1 on: February 28, 2010, 11:10:42 AM »
Quote from: ognix;545211
- gcc (hard to setup and not so user friendly)


It is not hard to setup for OS3, but it takes time, especially for searching and downloading all the relevant parts.
One to three hours must be invested, depending on your experience.
vbcc comes with an Amiga installation script, hence it is much easier to install and requires only a few seconds or minutes to be installed, depending on the host machine and backends you want to have installed.


Quote
My main aim is to do some basic stuff (at the beginning) focussing mostly on the classic platform (OS3.X), but with the idea of porting the most valuable project also on the other Amiga flavours.


That can be reached with any compiler as long as you ignore special features of the compiler's C-runtime lib and special compiler features. This doesn't mean that you can use DICE C or SAS/C for porting, but that you can use gcc or vbcc for this task with no or only few changes applied to the source code.


Quote
But now I don't want to start to code eg. with SAS/C if it contains too many non-stardard compiler dependencies (as I read in a forum), since this will lead to difficulties in porting the code on other platforms/flavours.


What makes SAS/C so special is its C-runtime lib. If you forego to use functions, which are SAS/C only, like for example stcd_l and the alike, and use instead the OS provided counterparts, nothing speaks against using SAS/C, even you take into consideration to port this source code one time to another Amiga flavour.


Quote
But I'd like to know if the big manuals are still valuable for programming the Amiga today, or if the info is outdated, and the docs can be found on the Internet are more the sufficient for a proper and clean coding.


I would speculate that your manuals cover the operating system of version 2, not 3. That means they are outdated in some segments, but not entirely.
Always have the current autodocs at hand in order to verify what in the manuals is stated. Non standard C-lib functions of the SAS/C C-runtime library should be avoided by all means, otherwise you put yourself into the trouble to re-design them for other Amiga flavours or compilers, once you want to port your source codes.


Quote
Ahhh... I don't need C++ (at least on my Amiga projects), and is it true that I can make a shared library just with SAS/C and Storm C? This seems strange to me...


As Piru already pointed out, it can be done with any compiler, even with HiSoftC++, which is a weak compiler.
To hide compiler specific attributes and keywords, use SDI_Headers, which is a collection of macros just designed for this purpose.

If you want to write a shared library, have a look at "Weaver" on "amimedic.de", which is a tool that allows you to create the library frame on a source code level. It makes use of SDI_Headers and supports you in creating OS3, AROS, MorphOS and AmigaOS4 shared library source codes. The created results were already successfully tested with gcc and vbcc.
 

Offline Joloo

Re: Still C compiler selection hints...
« Reply #2 on: February 28, 2010, 01:54:19 PM »
Quote from: itix;545492
SAS/C lacks C++ and it is available only for Amiga (so no cross-compiling possible) but pretty much everything else is in SAS/C.


I personally wouldn't vote for any compiler, hence I made no suggestion. Everybody should test different compilers and use the one that suits best.
SAS/C was the de-facto compiler a long time ago for AmigaOS but since the entire community is splitted into several camps (in case they didn't quit) with different processors and APIs, SAS/C is only suitable for m68k code generation. As I pointed out it doesn't matter as long as one is targetting his programs only towards this platform and the standard Amiga API, but it gets complicated when someone thinks that he can port source codes, that rely on SAS/C special features and its C-runtime lib, with no efforts to other platforms.

I used several compilers on the Amiga in the past till I found the one, which came close to my vision of a C compiler.
Today the most important aspect for me is to have installed a compiler that comes with different backends in order to support all camps, if necessary.


Quote
Libnix covers many SAS/C C lib extensions for 68k and MorphOS...


Correct me if I am wrong. I think you're referring to updated Libnix packages and hand-tuned specs-files for gcc and those are hardly to be found. MorphOS has got these in contrast to the standard (classic) AmigaOS installation.
If one who is not really familiar with gcc and the related stuff tries to update it himself, a nervous breakdown isn't very far. :)