StormC 2.0 vs SAS 6.57
Georges Heinesch
I'd like to purchase a compiler for the Amiga.
To me, it seems that the SAS 6.57 (which is not developed any more),
it the best, but not really very user friendly (regarding the
programming; no GUI, ...). Besides that, it only supports up to 68040.
not even a 68060 afaik.
The StormC 2.0 seems to be more future orientated, but unfortunately
very expensive and demanding a major rewrite of existing SAS code to
allow compilation. Besides that, it's sometimes not very ANSI-standard-
friendly.
I'd greatly apprciate any comments about which one should be bought
nowadays considering the situation of the Amiga.
TIA
--
Cu Georges Heinesch, Luxembourg
geo...@ibm.net - geo...@geocities.com
http://www.geocities.com/yosemite/2480
PGP 2.6.3i public key available on request and on public servers
... if you can't beat them, join them !
Johan Grip
Georges Heinesch wrote:
>I'd like to purchase a compiler for the Amiga.
>To me, it seems that the SAS 6.57 (which is not developed any more),
>it the best, but not really very user friendly (regarding the
>programming; no GUI, ...). Besides that, it only supports up to 68040.
>not even a 68060 afaik.It does not support compiling for the 68060.
>The StormC 2.0 seems to be more future orientated, but unfortunately
>very expensive and demanding a major rewrite of existing SAS code to
>allow compilation. Besides that, it's sometimes not very ANSI-standard-
>friendly.But on the other hand, it will compile programs for the PPC,
and you can alsobuy extensions for Java, PPC-asm and other things.
IMHO, StormC is the best buy for programming the Amiga at the moment,
mostly based on its future compability.
Regards,
Johan Grip
Johan Eriksson
On 21 Jun 1997, Georges Heinesch wrote:
> I'd like to purchase a compiler for the Amiga.
>
> To me, it seems that the SAS 6.57 (which is not developed any more),
> it the best, but not really very user friendly (regarding the
> programming; no GUI, ...). Besides that, it only supports up to 68040.
> not even a 68060 afaik.
>
SAS 6.57 does have 68060 support. Don't know how good the optimization is
though...
/Johan Eriksson, joh...@lysator.liu.se
Gunther Nikl
> To me, it seems that the SAS 6.57 (which is not developed any more),
> it the best, but not really very user friendly (regarding the
> programming; no GUI, ...). Besides that, it only supports up to 68040.
> not even a 68060 afaik.
Wrong, SAS/C with its latest patch to 6.57 does know the 68060 and
6.58 is coming for sure. AFAIK, you really should prefer SAS/C.
What does a 'nice looking gui' is useful for if the compiler itself
isn't worth its money? Why are people always bedazzeld by the outfit
but ignore the crappy engine beneath it?
> I'd greatly apprciate any comments about which one should be bought
> nowadays considering the situation of the Amiga.
Have you ever tried gnuc? But it has no gui, bad for you but good
for me :-)
Gunther
--
irc: munk@#amigager
Carsten Schlote
>I'd like to purchase a compiler for the Amiga.
>To me, it seems that the SAS 6.57 (which is not developed any more),
>it the best, but not really very user friendly (regarding the
>programming; no GUI, ...). Besides that, it only supports up to 68040.
>not even a 68060 afaik.
Wrong. SAS/C 6.57 and higher supports 68060 cpus. Even if there is no official
development of SAS/C anymore, the SAS/C authors still do a _great_ job and add
small fixes to their great compiler.
>The StormC 2.0 seems to be more future orientated, but unfortunately
>very expensive and demanding a major rewrite of existing SAS code to
>allow compilation. Besides that, it's sometimes not very ANSI-standard-
>friendly.
Wrong. You only have to addapt very few thing (e.g. #pragmas or Includes
). Meanwhile StormC creates a good code for all cpus, and outperformes SAS/C
with FPU operations on 060 CPUs :-)
I will release some benchmarks on my homepage, ready made for SAS/C and
StormC. You can compile the supplied C sources with the current compiler
release and see how the code performes. Try and compare :-)
>I'd greatly apprciate any comments about which one should be bought
>nowadays considering the situation of the Amiga.
If you really want to support the Amiga scene, consider purcasing StormC -
maybe they have some student saccounts ??? (Don't know, SAS had !)
StormC is in development, and will allow CrossDevelopment for PPC Cpus, too. I
know that there is some kind of ppc codegen already done for SAS/C, but as
Amiga development was cancled we can't depend on SAS/C supporting the future
(But would be nice :-)
Regards,
Carsten
---
Carsten Schlote
Coenobium Development - Software Dep.
email: sch...@stud.uni-frankfurt.de
BBS/Fax: Reefer Madness ++49-6171-910286
http://www.rz.uni-frankfurt.de/~schlote
Flavio Catalani
On 22 Jun 1997 18:35:39 Gunther Nikl wrote about "Re: StormC 2.0 vs SAS 6.57":
>
> Georges Heinesch (geo...@ibm.net) wrote:
> > I'd like to purchase a compiler for the Amiga.
>
> > To me, it seems that the SAS 6.57 (which is not developed any more),
> > it the best, but not really very user friendly (regarding the
> > programming; no GUI, ...). Besides that, it only supports up to 68040.
> > not even a 68060 afaik.
>
> Wrong, SAS/C with its latest patch to 6.57 does know the 68060 and
> 6.58 is coming for sure. AFAIK, you really should prefer SAS/C.
> What does a 'nice looking gui' is useful for if the compiler itself
> isn't worth its money? Why are people always bedazzeld by the outfit
> but ignore the crappy engine beneath it?
>
> > I'd greatly apprciate any comments about which one should be bought
> > nowadays considering the situation of the Amiga.
>
> Have you ever tried gnuc? But it has no gui, bad for you but good
> for me :-)
>
StormC is the only real C++ compile (besides gnuc) on the Amiga.
SAS/C translate C++ in C and AFAIK does not support templates.
--
Ciao
fl...@itelcad.it
Christian Stieber
Gunther Nikl (gn...@informatik.uni-rostock.de) wrote:
> isn't worth its money? Why are people always bedazzeld by the outfit
> but ignore the crappy engine beneath it?
Isn't that obvious? Good software has to be colorful, aniomated
and, preferably, loud. Just ask a 3 year old kid --- I'm pretty sure
he'll prefer playing Storm-C instead of GNU-C, even if he doesn't
really understand the game.
The same happens here. People don't know much about programming, but
having a compiler with a GUI certainly makes things look easy. It
doesn't help with programming at all (in fact, it usually makes it
more complicated to get the GUI to do the stuff that a decent make
can do), but it makes it _look_ easier.
After all, it's 1997 --- software is judged by the looks. If it
looks good, it beats everything, even if it is crappy.
Christian
--
Christian Stieber sti...@informatik.tu-muenchen.de
Fortune cookie of the day:
Throwing food at a wild dog might tame him.
Maarten D. de Jong
Georges Heinesch (geo...@ibm.net) wrote:
: I'd like to purchase a compiler for the Amiga.
:
: To me, it seems that the SAS 6.57 (which is not developed any more),
: it the best, but not really very user friendly (regarding the
: programming; no GUI, ...). Besides that, it only supports up to 68040.
: not even a 68060 afaik.
Bull. 6.57 supports a 68060. Also, don't hold your breath for any special
support of CPU's with a type number 68030 and higher: the difference in
speed is in most practical cases not noticeable. SAS has a GUI -- it is
called 'se'. Only I'd throw away any GUI right away and use a dedicated
editor like GoldED or AMIS.
: The StormC 2.0 seems to be more future orientated, but unfortunately
: very expensive and demanding a major rewrite of existing SAS code to
: allow compilation. Besides that, it's sometimes not very ANSI-standard-
: friendly.
I cannot be sureof this (I never used Storm), but if this is true, avoid
this sucker straight away. Using a non-ANSI C-compiler is asking for
trouble. I've also heard lots of complaints about code bloat and lousy
code generation. Therefore, buy SAS.
Maarten
Johan Grip
Maarten D. de Jong wrote:
>Georges Heinesch (geo...@ibm.net) wrote:
>: I'd like to purchase a compiler for the Amiga.
>:
>: To me, it seems that the SAS 6.57 (which is not developed any more),
>: it the best, but not really very user friendly (regarding the
>: programming; no GUI, ...). Besides that, it only supports up to
68040.
>: not even a 68060 afaik.
>Bull. 6.57 supports a 68060. Also, don't hold your breath for any
special
>support of CPU's with a type number 68030 and higher: the difference in
>speed is in most practical cases not noticeable. SAS has a GUI -- it is
>called 'se'. Only I'd throw away any GUI right away and use a dedicated
>editor like GoldED or AMIS.
Ok, my fault. I did not know that SAS supported the 68060, but now i
know.
StormC also supports GoldED, and GoldED supports Storm in a very good
way. StormC 2.0 even has a GoldED OEM release on the installation disks.
But then you would miss the visual make system and other useful things.
>: The StormC 2.0 seems to be more future orientated, but unfortunately
>: very expensive and demanding a major rewrite of existing SAS code to
>: allow compilation. Besides that, it's sometimes not very
ANSI-standard-
>: friendly.
>I cannot be sureof this (I never used Storm), but if this is true,
avoid
>this sucker straight away. Using a non-ANSI C-compiler is asking for
>trouble. I've also heard lots of complaints about code bloat and lousy
>code generation. Therefore, buy SAS.
IMO, StormC produces quite good code. I can only speak for the
2.0 version, which is the one I have. Small programs get big, yes,
but that is the startupcodes fault. If you write your programs to not
use the startupcode, you can make programs as small as you can with
SAS. I have examined the output of the compiler, and I must say that
it looks nice.
>Maarten
/Johan Grip
Paul Kolenbrander
On Mon, 23 Jun 97, Maarten D. de Jong typed the following line(s):
> I cannot be sureof this (I never used Storm), but if this is true, avoid
> this sucker straight away. Using a non-ANSI C-compiler is asking for
> trouble. I've also heard lots of complaints about code bloat and lousy
> code generation. Therefore, buy SAS.
Which can be a problem, As stock of that puppy seems to be very low
and it's hard to get at. But I agree, SAS C is a very nice compiler
that was well worth the considerable investment I made in it (from
version 5.x to current 6.57) And I once more would like to applaude
the commitment of that intrepid trio that keeps bringing us little
patches for SAS C. Done, I might add, in their own time and at their
own expense. Thanks guys! You're lifesavers...
Will I migrate? No, I've not yet found a worthy succesor. If I do
migrate (when forced to do so) it will most likely be to GCC as
that one is pretty standard. Not to mention priced at a very, very
attractive price and with good overall support...
take care,
--__
/_/ |/ E-mail: pa...@serena.iaehv.nl
/aul |\olenbrander WWW : http://www.iaehv.nl/users/paul/
-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-o-
- IMPORTANT!: Use mail address in my sig! Do NOT use Reply! -
Note: US$ 100 handling charge applied to unsolicited junkmail
Ash Wyllie
>Gunther Nikl (gn...@informatik.uni-rostock.de) wrote:
>> isn't worth its money? Why are people always bedazzeld by the outfit
>> but ignore the crappy engine beneath it?
>Isn't that obvious? Good software has to be colorful, aniomated
>and, preferably, loud. Just ask a 3 year old kid --- I'm pretty sure
>he'll prefer playing Storm-C instead of GNU-C, even if he doesn't
>really understand the game.
>The same happens here. People don't know much about programming, but
>having a compiler with a GUI certainly makes things look easy. It
>doesn't help with programming at all (in fact, it usually makes it
>more complicated to get the GUI to do the stuff that a decent make
>can do), but it makes it _look_ easier.
>After all, it's 1997 --- software is judged by the looks. If it
>looks good, it beats everything, even if it is crappy.
>Christian
I disagree. Who *really* wants to have to learn and type all the arcane unix
type options for the gcc compiler when a SAS or DIce gui makes life simpler?
-ash
Uffe Holst
In a message of 23 Jun 97 Christian Stieber wrote to :
CS> People don't know much about programming, but having a compiler with=
a GUI
CS> certainly makes things look easy.
And the only reason Borland C has sold more than one copy.
Uffe Holst
Colin Ward
sti...@Informatik.TU-Muenchen.DE (Christian Stieber) wrote:
>Gunther Nikl (gn...@informatik.uni-rostock.de) wrote:
>> isn't worth its money? Why are people always bedazzeld by the outfit
>> but ignore the crappy engine beneath it?
>Isn't that obvious? Good software has to be colorful, aniomated
>and, preferably, loud. Just ask a 3 year old kid --- I'm pretty sure
>he'll prefer playing Storm-C instead of GNU-C, even if he doesn't
>really understand the game.
>The same happens here. People don't know much about programming, but
>having a compiler with a GUI certainly makes things look easy. It
>doesn't help with programming at all (in fact, it usually makes it
>more complicated to get the GUI to do the stuff that a decent make
>can do), but it makes it _look_ easier.
>After all, it's 1997 --- software is judged by the looks. If it
>looks good, it beats everything, even if it is crappy.
Yes, I agree with this wholeheartedly. BUT I will say that I think that
if you have a very solid, efficient and proven compiler then it is ok to
then spend some time making a nice front end to it. But *only* after the
compiler itself is perfect. I remember at college my lecturer for graphics
used to get really upset because whenever he gave us an assignment everyone
would start off on the GUI front end before they had done anything on the
behind the scenes engine. Half of them would run out of time and hand in a
wonderful looking GUI with no engine, or a really bad one! Then I would
come along with my engine that I had worked very hard on, with it's ugly
GUI and get better marks than all of them! So as I said, if and *only* if
the engine is perfect can you spend time making a nice front end!
But the other thing that I don't understand is that when people make
these fancy user interfaces like Visual C++ on the PC (blerrrgh) and StormC
on the Amiga, why do they always end up being soooooo ssssllllloooowwwww???
I mean I am a die hard SAS/C dude, but I download the demo version of
StormC for interest's sake, and you might as well get a cup of tea while
you are waiting for it to load! And the screen updates on my
4000/030/CyberVision 64 3D are as slow as Ed on WB1.3 on my old A500! What
is the problem with making a fancy user interface that is fast? I mean, it
*can* be done...
Bah... I'll stick to sc <FileName> thanks. :-)
/----------------------------------------------------------------------\
[Hitman/Code HQ - 6502/68000/80386 & soon A4000/PowerPC ]
[Assembly Lover since 1987! Proud member of Team AMIGA ]
[OS coding/Hardware hitting/Demos/Games/Modules - c64, Amiga & PC ]
[I'm a pogrammar.. I'm a programor... I'm a progemmar... I write code. ]
\----------------------------------------------------------------------/
Hans-Joerg Frieden
Georges Heinesch <geo...@ibm.net> wrote:
> To me, it seems that the SAS 6.57 (which is not developed any more),
> it the best, but not really very user friendly (regarding the
> programming; no GUI, ...). Besides that, it only supports up to 68040.
> not even a 68060 afaik.
I'd prefer make before any fancy GUI. Apart from that, SAS also has a GUI
to a certain degree - you get a message window with the error messages,
and can configure it for your favorite editor (if it supports AREXX), so
you can load/jump to the offending line. SAS/C is definately my system of
choice, even more because you get incredible worth for your money (how
much is it now? It's far below the $50 I think for a great compiler and
two large manuals)...
Besides SAS has 060 support (although the opt schedule seems to be broken
with
060 code).
> The StormC 2.0 seems to be more future orientated, but unfortunately
> very expensive and demanding a major rewrite of existing SAS code to
> allow compilation. Besides that, it's sometimes not very ANSI-standard-
> friendly.
Haven't seen Storm C, but I'd go for SAS/C anytime. GCC is an alternative,
too, alas it's resource-hungry (no problem if you've got around 32 MB) and
it's quite slow, even on the 060...
Regards, Hans-Joerg.
--
hfri...@uni-trier.de | "Perlious are the devices of an art
Visit our Raytracing page | deeper than we possess ourselves"
www.informatik.uni-trier.de/ | Gandalf the White, The Two Towers
CIP/hfrieden/ |
122010...@tele.dk
In <5olt00$i...@sunsystem5.informatik.tu-muenchen.de>, sti...@Informatik.TU-Muenchen.DE (Christian Stieber) writes:
>Gunther Nikl (gn...@informatik.uni-rostock.de) wrote:
>After all, it's 1997 --- software is judged by the looks. If it
>looks good, it beats everything, even if it is crappy.
So very sad but true!!
Kai Fleischer
Johan Grip wrote:
>
> Maarten D. de Jong wrote:
> >Georges Heinesch (geo...@ibm.net) wrote:
> >: I'd like to purchase a compiler for the Amiga.
> >:
> 2.0 version, which is the one I have. Small programs get big, yes,
> but that is the startupcodes fault. If you write your programs to not
> use the startupcode, you can make programs as small as you can with
> SAS. I have examined the output of the compiler, and I must say that
> it looks nice.
Just have a look at "stormamiga.lib". It replaces the standard
"storm.lib" that is written in C. With "stormamiga.lib" programs become
very small and fast because it is written in highly optimized assembler.
Also it fixes many bugs in the original libs and adds some new
functions. You can find it in aminet at dev/c.
--
Greetings
Kai Fleischer
---------------------------------------------------------------
GMD, Dept. IMK-VMSD tel: +49 (0) 2241 14-2179
email: kai.fl...@gmd.de URL: http://viswiz.gmd.de
---------------------------------------------------------------
Steve Krueger
> Besides SAS has 060 support (although the opt schedule seems to be broken
> with
> 060 code).
Could you give me more details on what it broken? I haven't heard of any
scheduler bug in 6.57.
sk
Johan Grip
Hans-Joerg Frieden wrote:
>
> Georges Heinesch <geo...@ibm.net> wrote:
> > To me, it seems that the SAS 6.57 (which is not developed any more),
> > it the best, but not really very user friendly (regarding the
> > programming; no GUI, ...). Besides that, it only supports up to 68040.
> > not even a 68060 afaik.
> One Word: MAKE
> I'd prefer make before any fancy GUI. Apart from that, SAS also has a GUI
> to a certain degree - you get a message window with the error messages,
> and can configure it for your favorite editor (if it supports AREXX), so
> you can load/jump to the offending line. SAS/C is definately my system of
> choice, even more because you get incredible worth for your money (how
> much is it now? It's far below the $50 I think for a great compiler and
> two large manuals)...
>
> with
> 060 code).
>
StormC 2.0 supports a sort of makescripts. You can write external
makesystems
in ARexx, that will be run everytime you perform a make. Yes, I
personally
like make to, but I don't miss it that much. I can setup an ordinary
project
in StormC vith the visual system much quicker than I can with SAS.
StormC also has 060 support, and will soon support the PPC, which I
doubt
that SAS ever will. You can also extend StormC to support JAVA via the
new Merapi project by Haage-partner.
Added features in StormC is the runtime system that checks if you close
all libraries, free all memory etc. without sourcecode changes. That is
something that no other development system on the Amiga does today.
> > The StormC 2.0 seems to be more future orientated, but unfortunately
> > very expensive and demanding a major rewrite of existing SAS code to
> > allow compilation. Besides that, it's sometimes not very ANSI-standard-
> > friendly.
> Haven't seen Storm C, but I'd go for SAS/C anytime. GCC is an alternative,
> too, alas it's resource-hungry (no problem if you've got around 32 MB) and
> it's quite slow, even on the 060...
>
But, if you program in C++, StormC 2.0 will produce shorter code than
both
SAS and GCC. I would personally not go for GCC, because I'm not porting
UN*X programs, I'm writing for the Amiga.
IMHO, anything lower than 040 is disregarded in software development
anyway.
Yes, I know that you can run SAS on a stock A500, but who make software
on
such a machine nowadays? Most Amigas today have atleast 020, and many
have
even faster CPU:s, I have a 040/40 in my A3000, and for me StormC does
the
job at a reasonable speed. The only thing that I need is a Gfxcard :)
Regards,
Johan Grip.
Mike Redrobe
Hi, Colin Ward , on 24-Jun-97 01:18:30 you scribbled....
CW> Bah... I'll stick to sc <FileName> thanks. :-)
Bah, you mean (s)make surely ;)
Mike
--
---------------------------------------------------------------------------
Mike Redrobe - mailto:mi...@redrobe.demon.co.uk MikeRR on #Amiga
http://www.redrobe.demon.co.uk
---------------------------------------------------------------------------
Walter Doerwald
On 23 Jun 1997 01:57:30 +0100 Flavio Catalani wrote:
>
> On 22 Jun 1997 18:35:39 Gunther Nikl wrote about "Re: StormC 2.0 vs SAS
> 6.57":
>
> [...]
> StormC is the only real C++ compile (besides gnuc) on the Amiga.
What is "real C++"?
Bye...
Walter Doerwald
Colin Ward
Mike Redrobe <Mi...@redrobe.demon.co.uk> wrote:
>Hi, Colin Ward , on 24-Jun-97 01:18:30 you scribbled....
> CW> Bah... I'll stick to sc <FileName> thanks. :-)
>Bah, you mean (s)make surely ;)
:-) Yep... sc, smake, as long as it's not click 'n' wait! :-)
Keith Blakemore-Noble
Johan Grip wrote:
>
> StormC 2.0 supports a sort of makescripts. You can write external
> makesystems
> in ARexx, that will be run everytime you perform a make. Yes, I
> personally
> like make to, but I don't miss it that much.
I just want to make sure I understand this correctly -
Are you saying that StormC does NOT have 'make' and does not directly
support makefiles?
If that is the case, then I am very surprised indeed by the omission of
such animportant aspect of C programming - what ARE H&P thinking of?
If that is NOT the case, then I'm a little confused by what you mean
above - can you clarify please?
FWIW, I personally use SAS/C and GNU C, depending upon what I am
writing, but in both cases, I make heavy use of (s)make - makes life
just soooo much easier :)
TTFN,
Keith
Johan Grip
Keith Blakemore-Noble wrote:
> I just want to make sure I understand this correctly -
>
> Are you saying that StormC does NOT have 'make' and does not directly
> support makefiles?
>
been replaced by a graphical project manager. This is the very
foundation of StormC, as everything you do is based on this
projectmanagement. If you for example doubleclick on a C-sourcefile
in the projectwindow, Storm will open this file in an editorwindow.
When you are finished editing, press the F9 key, and Storm will
invoke its own kind of 'make' on the project.
> If that is the case, then I am very surprised indeed by the omission
> of
> such animportant aspect of C programming - what ARE H&P thinking of?
>
As said above it's not omitted, it's redone.
> If that is NOT the case, then I'm a little confused by what you mean
> above - can you clarify please?
>
Certainly :)
> FWIW, I personally use SAS/C and GNU C, depending upon what I am
> writing, but in both cases, I make heavy use of (s)make - makes life
> just soooo much easier :)
>
Yes, I also use SAS/C for my older sources, but all my current projects
are made with StormC. StormC helps me concentrate on the actual coding,
and less on the management of the project.
Regards,
Johan Grip
Keith Blakemore-Noble
Johan Grip wrote:
>
> Keith Blakemore-Noble wrote:
> > I just want to make sure I understand this correctly -
> >
> > Are you saying that StormC does NOT have 'make' and does not directly
> > support makefiles?
> >
> This is correct, the command 'make' and associated utilities have
> been replaced by a graphical project manager. This is the very
> foundation of StormC, as everything you do is based on this
> projectmanagement. If you for example doubleclick on a C-sourcefile
> in the projectwindow, Storm will open this file in an editorwindow.
> When you are finished editing, press the F9 key, and Storm will
> invoke its own kind of 'make' on the project.
So they do not have any way of using existing makefiles if one is, for
example, porting someone elses software or even takin gover development
of some other software?
That, IMHO is a Very Bad Thing, and for me one reason NOT to even
consider StormC - if it cannot be used for much of my C development
work, then it is of no use, I'm afraid.
(For example, I am working with several other people on a project which
is being written and run on several different platforms. Some of us use
GNU, some use SAS and some use other compilers. However, this is not a
problem because all C compilers that are of any use at all fully support
makefiles, so we can all keep up to date with each other - sounds like
Storm would be a backward leap in this respect. Why?? H&P - any
comments?)
Just my 2p-worth, of course :)
TTFN,
Keith.
Christian Stieber
Keith Blakemore-Noble (kno...@lsil.com) wrote:
> > > support makefiles?
> > >
> > This is correct, the command 'make' and associated utilities have
> > been replaced by a graphical project manager.
> So they do not have any way of using existing makefiles if one is, for
> example, porting someone elses software or even takin gover development
> of some other software?
It also means you'll have to tell you "projectmanager" how to do
thing like "compile a C program which reads a datafile and creates
another C source which is then used to build the component",
and "create the distribution packages" and "create the documentation"
etc. --- basically anything that the original Storm-C developers
didn't implement into their GUI.
This means a lot of work, and creates "makefiles" that are incompatible
to every real make.
> (For example, I am working with several other people on a project which
> is being written and run on several different platforms. Some of us use
> GNU, some use SAS and some use other compilers. However, this is not a
> problem because all C compilers that are of any use at all fully support
> makefiles,
I have never seen a C compiler supporting makefiles. I have seen
C development packages coming with a make utility, though -:)
Christian
--
Christian Stieber sti...@informatik.tu-muenchen.de
Fortune cookie of the day:
I'm watching you. -- The Wizard of Yendor
Hans-Joerg Frieden
Steve Krueger <sekr...@mindspring.com> wrote:
> > Besides SAS has 060 support (although the opt schedule seems to be broken
> > with
> > 060 code).
> Could you give me more details on what it broken? I haven't heard of any
> scheduler bug in 6.57.
When I switch on optimization, everything works. When I additionally
enable scheduling, the resulting executable produces enforcer hits, or it
crashes right away. This happens only when I tell it to produce 68060
code, otherwise it works.
Hans-Joerg Frieden
Johan Grip <og...@moranet.se> wrote:
> StormC 2.0 supports a sort of makescripts. You can write external
> makesystems
> in ARexx, that will be run everytime you perform a make. Yes, I
> personally
> project
> in StormC vith the visual system much quicker than I can with SAS.
> StormC also has 060 support, and will soon support the PPC, which I
> doubt
> that SAS ever will. You can also extend StormC to support JAVA via the
> new Merapi project by Haage-partner.
> Added features in StormC is the runtime system that checks if you close
> all libraries, free all memory etc. without sourcecode changes. That is
> something that no other development system on the Amiga does today.
high price for it. I can enter MKMK to set up a makefile in a second, and
even if I don't use it, writing a makefile is a matter of a minute. The
JAVA capabilities aren't there yet, since Merapi isn't there yet, so that
doesn't really count. I don't have a PPC, so I don't need PPC code
generation right now. Granted, I might need it in the future, but until
then...
The resource tracking feature is nice, but what overhead does it impose?
(no flame, I'm honestly asking).
> But, if you program in C++, StormC 2.0 will produce shorter code than
> both
> SAS and GCC. I would personally not go for GCC, because I'm not porting
> UN*X programs, I'm writing for the Amiga.
> IMHO, anything lower than 040 is disregarded in software development
> anyway.
GCC is an ANSI C compiler, nothing more. It happens to be good for porting
unix programs because the Amiga version comes with lots of stuff exactly
for this purpose, but then, there's libnix which makes it possible to
develop exclusively for the Amiga. GCC is a hell of a good compiler, and
it's very portable, so that porting to PowerPC is quite easy (the
provisions for that are already on the ADE-2 CD).
> Yes, I know that you can run SAS on a stock A500, but who make software
> on
> such a machine nowadays? Most Amigas today have atleast 020, and many
> have
> even faster CPU:s, I have a 040/40 in my A3000, and for me StormC does
> the
> job at a reasonable speed. The only thing that I need is a Gfxcard :)
My opinion exactly. I regard the 030 as a base machine. If my programs
don't run on a 020, I don't care. I have a 060/50, and for me even GCC
does the job in a reasonable speed, not to mention SAS. I guess that I
would also like StormC, but I think it's too expensive. I'm happy with
SAS, and occasionally use GCC for porting UNIX stuff. Of course, your
milage will vary...
C. Potter
Hans-Joerg Frieden wrote:
>
> My opinion exactly. I regard the 030 as a base machine. If my programs
> don't run on a 020, I don't care. I have a 060/50, and for me even GCC
> does the job in a reasonable speed, not to mention SAS. I guess that I
> would also like StormC, but I think it's too expensive. I'm happy with
I agree 100%. I would like to buy Storm to replace my SAS/C, but
I don't have often the time to program, therefore I will not pay
more than 150 euros/dollars for it (and with pOS & PPC extensions).
Same for ArtEffect. I would love to buy it, but need it only
every 2 months or so. Therefore, 100 euros should be a fair price.
I always think that it is better to sell a lot of software at
low price than fewer at high price.
And I would like to have import/export function for standard unix
makefiles.
Regards,
---------------------------------------+----------------------------+
Christopher Potter | CRAY T3D - 256 DEC alpha |
Parallel Applications Engineer | 20000 MFLOPS Sustained |
---------------------------------------+----------------------------+
EPFL/SIC/SE email: pot...@sic.epfl.ch Tel: +41 21 6934552 |
---------------------------------------+----------------------------+
Steve Krueger
Hans-Joerg Frieden <hfri...@fax.uni-trier.de> wrote in article
<5or4l6$p...@news01.uni-trier.de>...
> Steve Krueger <sekr...@mindspring.com> wrote:
>
> > > Besides SAS has 060 support (although the opt schedule seems to be
broken
> > > with
> > > 060 code).
>
> > Could you give me more details on what it broken? I haven't heard of
any
> > scheduler bug in 6.57.
> When I switch on optimization, everything works. When I additionally
> enable scheduling, the resulting executable produces enforcer hits, or it
> crashes right away. This happens only when I tell it to produce 68060
> code, otherwise it works.
Can you send me a test case?
sk
Paul Copsey
In <5ono51$s...@news01.uni-trier.de>,
Hans-Joerg Frieden <hfri...@fax.uni-trier.de> wrote:
> Haven't seen Storm C, but I'd go for SAS/C anytime. GCC is an alternative,
> too, alas it's resource-hungry (no problem if you've got around 32 MB) and
> it's quite slow, even on the 060...
It runs OK here (030/50 16MB) the main problem is the repeated loading
of huge exe's, which I usually get around with a very large disk cache
;-)
Paul
--
I have a screen capable of displaying the first 34 lines of a post at once,
If I can't see any new text in those, I move on.
Hans-Joerg Frieden
C. Potter <pot...@sic.epfl.ch> wrote:
> And I would like to have import/export function for standard unix
> makefiles.
Make. I've already compiled unix programs with that combination, and just
had to add/change the "CC=ucc" line - the rest went automatically...
Problem with some UNIX makefiles is that they can use macros before they
are actually defined, and they can use a bunch of shell commands... With
ADE and GNU Make, this works, even without using gcc.
Keith Blakemore-Noble
Christian Stieber wrote:
>
> Keith Blakemore-Noble (kno...@lsil.com) wrote:
> > GNU, some use SAS and some use other compilers. However, this is not a
> > problem because all C compilers that are of any use at all fully support
> > makefiles,
>
> I have never seen a C compiler supporting makefiles. I have seen
> C development packages coming with a make utility, though -:)
Grrrr.....
:)
You are of course quite correct. I really shoudl be a little more
selective in my terminology :)
Still, it is something that is still sadly missing from teh StormC
devel;opment package...
TTFN,
Keith
Volker Barthelmann
Hans-Joerg Frieden <hfri...@fax.uni-trier.de> wrote:
: Steve Krueger <sekr...@mindspring.com> wrote:
: > > Besides SAS has 060 support (although the opt schedule seems to be broken
: > > with
: > > 060 code).
: > Could you give me more details on what it broken? I haven't heard of any
: > scheduler bug in 6.57.
?? Unless my memory completely fails I posted an example to this newsgroup
some months ago and Steve Krueger himself said it was a bug in the scheduler.
: When I switch on optimization, everything works. When I additionally
: enable scheduling, the resulting executable produces enforcer hits, or it
: crashes right away. This happens only when I tell it to produce 68060
: code, otherwise it works.
In the following example the target cpu doesn't seem to matter:
10.Ram Disk:> cat tt.c
extern int a,b;
f()
{
a=-a;
b=a;
return b;
}
10.Ram Disk:> sc ver opt tt.c disassemble=*
SAS/C Amiga Compiler 6.57
Copyright (c) 1988-1995 SAS Institute Inc.
tt.c 4 Warning 161: no prototype declared at definition for function "f"
SECTION text,CODE
__code:
f:
___f__1:
MOVE.L a(A4),D0 ;202c 0000
NEG.L a(A4) ;44ac 0000
MOVE.L D0,b(A4) ;2940 0000
___f__2:
RTS ;4e75
__const:
__strings:
XREF a
XREF b
XDEF f
END
10.Ram Disk:> sc ver opt tt.c disassemble=* nooptsched
SAS/C Amiga Compiler 6.57
Copyright (c) 1988-1995 SAS Institute Inc.
tt.c 4 Warning 161: no prototype declared at definition for function "f"
SECTION text,CODE
__code:
f:
___f__1:
NEG.L a(A4) ;44ac 0000
MOVE.L a(A4),D0 ;202c 0000
MOVE.L D0,b(A4) ;2940 0000
___f__2:
RTS ;4e75
__const:
__strings:
XREF a
XREF b
XDEF f
END
Volker
Steve Krueger
>
> ?? Unless my memory completely fails I posted an example to this
newsgroup
> some months ago and Steve Krueger himself said it was a bug in the
scheduler.
> extern int a,b;
>
> f()
> {
> a=-a;
> b=a;
> return b;
> }
I forgot all about this one. It is fixed in 6.58 though, which I'll be
releasing soon.
sk
Hans-Joerg Frieden
Paul Copsey <pa...@hectortd.demon.co.uk> wrote:
> It runs OK here (030/50 16MB) the main problem is the repeated loading
> of huge exe's, which I usually get around with a very large disk cache
> ;-)
where once, when I didn't have enough memory... 8-/
Gabriele Greco
Hello Johan,
In a message dated 25 Jun 97 you wrote to All :
JG> This is correct, the command 'make' and associated utilities have been
JG> replaced by a graphical project manager. This is the very
JG> foundation of StormC, as everything you do is based on this
JG> projectmanagement. If you for example doubleclick on a C-sourcefile in
JG> the projectwindow, Storm will open this file in an editorwindow. When
JG> you are finished editing, press the F9 key, and Storm will
JG> invoke its own kind of 'make' on the project.
Dependencies, clean or other typical make actions, like for instance building
versions for different processors or archive are also available through that
enviroment?
JG> Yes, I also use SAS/C for my older sources, but all my current projects
JG> are made with StormC. StormC helps me concentrate on the actual coding,
JG> and less on the management of the project.
Once the (s)makefile is ready I never touch it, I think that clicking on a make
icon (or typing make on the shell) instead of press F9 don't make me take less
care of the code.
Ciao,
Gabry (ggr...@iol.it)
Johan Eriksson
On 26 Jun 1997, Steve Krueger wrote:
> I forgot all about this one. It is fixed in 6.58 though, which I'll be
> releasing soon.
>
Looking forward to that :)
/Johan Eriksson, joh...@lysator.liu.se
Paul Copsey
In <5ourkb$q...@news01.uni-trier.de>,
Hans-Joerg Frieden <hfri...@fax.uni-trier.de> wrote:
> Paul Copsey <pa...@hectortd.demon.co.uk> wrote:
> > It runs OK here (030/50 16MB) the main problem is the repeated loading
> > of huge exe's, which I usually get around with a very large disk cache
> > ;-)
> How 'bout making them resident. Dunno if they're still pure, but they
> where once, when I didn't have enough memory... 8-/
Excellent point that man ;-) I hadn't thought about that, but then
will there be any gain? As it stands the includes and other non-exe
bits get cached too, so they may swing the balance in favour of the
cache.
Georges Heinesch
In a message of 23-Jun-97 16:05:34, Maarten D. de Jong wrote:
> Georges Heinesch (geo...@ibm.net) wrote:
>: I'd like to purchase a compiler for the Amiga.
>:
>: To me, it seems that the SAS 6.57 (which is not developed any
>: more), it the best, but not really very user friendly (regarding
>: the programming; no GUI, ...). Besides that, it only supports up to
>: 68040. not even a 68060 afaik.
> Bull. 6.57 supports a 68060. Also, don't hold your breath for any
> special support of CPU's with a type number 68030 and higher: the
> difference in speed is in most practical cases not noticeable. SAS
> has a GUI -- it is called 'se'. Only I'd throw away any GUI right
> away and use a dedicated editor like GoldED or AMIS.
How far is GoldED a dedicated SAS editor? I didn't see any api or
utility connecting SAS to GoldED (except the standard envCPP.lha)
archive).
TIA
--
XXX Delete 'NOSPAM' in 'geo...@NOSPAM.ibm.net' when replying !!!
Cu Georges Heinesch, Luxembourg
geo...@ibm.net - geo...@geocities.com
http://www.geocities.com/yosemite/2480
PGP 2.6.3i public key available on request and on public servers
... ELLX
Bozena Rogut Siemieniak
Program is compiled with special -68030 or 020 but all the time
i have on this procesors EMP Trap. But with 040/060 everything is
OK. (even 030+FPU don't work) - any ideas where is should look
for errors ? (this program is XAnim)
--
Adrian (Sauron) Siemieniak /~//_ .. Who can destroy The Thing,
sau...@pwr.wroc.pl / //__\ controls The Thing ... (DUNE)
sau...@sco.zsi.pwr.wroc.pl \/___ / Amiga1240T/40Mhz/16MB/1.5GB
Admin on !Agnen! MUD / // Author: MPEGIntuition, MENTAT, Agnen
BTester QT,CyberQT/AVI,AVId \// Animations/Multimedia FAQ,
http://www.wroc.ids.edu.pl/~agnen XAnim port, IntelIndeo.library
Hannu Nevalainen
> + On 05-Jul-97 15:31:46
> + Bozena Rogut Siemieniak <sau...@sun1000.pwr.wroc.pl> wrote
>Program is compiled with special -68030 or 020 but all the time
>i have on this procesors EMP Trap. But with 040/060 everything is
>OK. (even 030+FPU don't work) - any ideas where is should look
>for errors ? (this program is XAnim)
Hmm? Have you tried; 1> Stack 100000
(or maybe even more)
Hannu E K Nevalainen -n.o.s.p.a.m.-> http://www.spam-it.kth.se/~henk/
--
Amiga - The Beauty, Windows - The Beast, Love? Nahhh...
Bruce Abbott
In a message of 23-Jun-97 16:05:34, Maarten D. de Jong wrote:
> Bull. 6.57 supports a 68060. Also, don't hold your breath for any
> special support of CPU's with a type number 68030 and higher: the
> difference in speed is in most practical cases not noticeable.
Will it generate inline 68060 FPU code?
Maxon Cinema 4D renders 2.5 times faster on my Cyberstorm 060 when
Cyberpatcher is running. I wonder How much faster would it be if
compiled with fully '060 optimised code?
---------------------------------------------------------------------------
Bruce Abbott Hastings, New Zealand bhabbott<at>inhb.co.nz
---------------------------------------------------------------------------
Colin Ward
Georges Heinesch <geo...@NOSPAM.ibm.net> wrote:
>How far is GoldED a dedicated SAS editor? I didn't see any api or
>utility connecting SAS to GoldED (except the standard envCPP.lha)
>archive).
On a slightly different note, but still speaking of GoldED. Does anyone
know of *any* way of getting it to keep/insert tab characters? I don't use
tabs in my C source but I do in my assembly source. I'd *love* to use and
register this rather powerful text editor but without tab support it's just
not usable for assembly... The size of your code just bloats out too much.
Keith Blakemore-Noble
Colin Ward wrote:
> On a slightly different note, but still speaking of GoldED. Does anyone
> know of *any* way of getting it to keep/insert tab characters?
I know what you are saying - I have wished for a long tim enow that
GoldEd woudl have proper TAB support.
On 4.7.x, there is a switch that can let you open a fil ein TAB mode -
i.e. it keeps existing tabs and doesn't convert them to spaces.
I can't remember off-hand what teh command is (it isn't on any menu :(()
and I don't know if it lets you enter TABs, but its a start...
Oh, another excellent reason for handling TAB as TAB and not space -
makefile under GNU MUST use TAB and not spaces at teh beginning of some
lines...
TTFN,
keith.
Andreas Malerz
Georges Heinesch <geo...@NOSPAM.ibm.net> wrote:
: How far is GoldED a dedicated SAS editor? I didn't see any api or
: utility connecting SAS to GoldED (except the standard envCPP.lha)
: archive).
Well, it's not, but it is very easy to configure it by yourself.
I did it in an hour or so, you only have to add some items in the
menus and write some ARexx-Scripts, if you want a 'Jump to next error'
feature.
With GoldEd, it's really easy to build up a simple GUI for any
programming language. You just should know a bit ARexx, but this one
is very easy.
Best wishes, Andy.
Charles Patterson
Andreas Malerz was talking about Re: StormC 2.0 vs SAS 6.57 >>
Would you be willing to share your setup instructions with us all?
Midian
--
Charles Patterson EA o http://www.azstarnet.com/~midian/
mailto:mid...@azstarnet.com \ /^\ / Amiga links, programs and art
/ G \ Only on an Amiga!
Wise men still seek him. / \./ \ Team *AMIGA*
===========================================================================
Nothing magnifies one's glory as much as sharing it with another. - Charles
Patterson (Inspired by Evander Holyfield during the 1996 Olympic Torch Run)
===========================================================================
Michael van Elst
bhabbo...@inhb.co.nz (Bruce Abbott) writes:
>In a message of 23-Jun-97 16:05:34, Maarten D. de Jong wrote:
>> Bull. 6.57 supports a 68060. Also, don't hold your breath for any
>> special support of CPU's with a type number 68030 and higher: the
>> difference in speed is in most practical cases not noticeable.
>Will it generate inline 68060 FPU code?
Inline FPU code has been generated for years. The trick is to avoid
inline FPU code that causes exceptions on 68060. You can omit most
such instructions if you make a special m68881.h file. A few
instructions still remain (and 6.57 will replace them when compiling
for 060). 6.57 will also avoid a trick that causes branch prediction
errors on the 68060 and it will use the MUL instruction instead of
a combination of shifts and adds.
>Maxon Cinema 4D renders 2.5 times faster on my Cyberstorm 060 when
>Cyberpatcher is running. I wonder How much faster would it be if
>compiled with fully '060 optimised code?
Maybe a 2-3 percent.
Regards,
--
Michael van Elst
Internet: mle...@serpens.swb.de
"A potential Snark may lurk in every tree."
Colin Ward
Keith Blakemore-Noble <kno...@lsil.com> wrote:
>Colin Ward wrote:
Well, I used to use tabs in my C as well as assembly code, but ages ago I
had so many horrid experiences on the PC with text editors converting tabs
to spaces that I ended up vowing never to use them (tabs) again. Who knows
*what* they used to do but I'd have a nicely formatted C file using, say, a
tab size of 3. Then I'd load it under some PC text editor like Turbo C and
when I quit it would save it using Amiga only knows what algorithm for
converting tabs to spaces. I'd end up with if statements and while loops
where the if or while statements were actually indented *more* than the
contents! Argggh! And the only way to fix it was to manually go and
re-indent everything! So I ended up nearly going nuts one day when it
happened and turned tabs off in all my editors (this is at work, not at
home where I use my beloved Amiga :-) and stopped using tabs.
Anyway, I thought I'd share that little story... :-)
I'll have a look at GoldED when I get home tonight. Could you have a
look at what that command is for me? I was using GoldED for a while and
had some nice ARexx scripts setup for compiling, but I didn't like using
one editor for C and a different one for assembly...
Stephen Keegan
Colin Ward wrote:
>
> Georges Heinesch <geo...@NOSPAM.ibm.net> wrote:
>
> >How far is GoldED a dedicated SAS editor? I didn't see any api or
> >utility connecting SAS to GoldED (except the standard envCPP.lha)
> >archive).
>
> tabs in my C source but I do in my assembly source. I'd *love* to use and
> register this rather powerful text editor but without tab support it's just
> not usable for assembly... The size of your code just bloats out too much.
GoldEd doesn't really handle tabs at all. What it does have is an option that
will convert spaces at the beginning of a line to tabs (note that any spaces
following your first column of assembly code will not be converted to tabs).
The tabs will be converted back to spaces when the GoldEd loads the file back
in though so cursor movements through the file will not skip from tab space
to tab space(as I would like it to).
The save with tabs option is somewhere in the local preferences, but I can't
remember where at this moment.
Stephen Keegan
Leslie Olding
While writing the latest killer app, you had time to say this
I've also had this problem with xanim and tried that amount of stack with
no luck. The xanim home page also warns of this problem I believe.
Regards E-mail: l.ol...@byter.demon.co.uk
Les O O IRC: [Byter]
(
\_/
Jim Cooper
On 07 Jul 97 03:42:23 +1200, bhabbo...@inhb.co.nz (Bruce Abbott)
wrote:
>In a message of 23-Jun-97 16:05:34, Maarten D. de Jong wrote:
>
>> Bull. 6.57 supports a 68060. Also, don't hold your breath for any
>> special support of CPU's with a type number 68030 and higher: the
>> difference in speed is in most practical cases not noticeable.
>
>Will it generate inline 68060 FPU code?
Yes.
>Maxon Cinema 4D renders 2.5 times faster on my Cyberstorm 060 when
>Cyberpatcher is running. I wonder How much faster would it be if
>compiled with fully '060 optimised code?
Don't know. If you could get them to try... :-)
SAS/C's Scheduling optimizer will even optimize the code for the
appropriate caches, etc. of the chosen processor. It's not perfect -
it only got a few bug fixes after the initial version, but it can mean
anywhere from 2% to 10% speedups (or even more, depending on the code)
without doing anything to your code at all... just turn the Scheduler
on when you compile.
Hans-Joerg Frieden
Jim Cooper <ja...@wnt.sas.com> wrote:
> >Maxon Cinema 4D renders 2.5 times faster on my Cyberstorm 060 when
> >Cyberpatcher is running. I wonder How much faster would it be if
> >compiled with fully '060 optimised code?
> Don't know. If you could get them to try... :-)
AFAIK Cinema4D is written in Modula-2, so there's not much chance for
this... Dunno about the quality of M-2 Compilers for the Amiga, but I
think they all stopped development before the 060 came out... At least the
commercial ones...
Michael Johnstone
From the Virtual Office of Future Unlimited
On 08-Jul-97 08:05:19 it was eagerly reported that Charles Patterson said
CP> Andreas Malerz was talking about Re: StormC 2.0 vs SAS 6.57 >>
>> Georges Heinesch <geo...@NOSPAM.ibm.net> wrote:
>>
>> : How far is GoldED a dedicated SAS editor? I didn't see any api or
>> : utility connecting SAS to GoldED (except the standard envCPP.lha)
>> : archive).
>>
>> Well, it's not, but it is very easy to configure it by yourself.
>> I did it in an hour or so, you only have to add some items in the
>> menus and write some ARexx-Scripts, if you want a 'Jump to next error'
>> feature.
>>
>> With GoldEd, it's really easy to build up a simple GUI for any
>> programming language. You just should know a bit ARexx, but this one
>> is very easy.
CP> Would you be willing to share your setup instructions with us all?
Yes, please.
--
Michael Johnstone | A2000 PP&S040 32 meg ram
Otago Amiga Users Group | Guru Rom OS 3.1
Member Team AMIGA | CyberVision64/3D
"Luke, don't give in to hate - that leads to the dark side." - Obi-Wan
Rick Keller
On 11-Jul-97 06:49:41, Michael Johnstone said of Re: StormC 2.0 vs SAS 6.57:
>>> : How far is GoldED a dedicated SAS editor? I didn't see any api or
>>> : utility connecting SAS to GoldED (except the standard envCPP.lha)
>>> : archive).
>>> Well, it's not, but it is very easy to configure it by yourself.
>>> I did it in an hour or so, you only have to add some items in the
>>> menus and write some ARexx-Scripts, if you want a 'Jump to next error'
>>> feature.
>>> With GoldEd, it's really easy to build up a simple GUI for any
>>> programming language. You just should know a bit ARexx, but this one
>>> is very easy.
CP>> Would you be willing to share your setup instructions with us all?
>Yes, please.
I'd be interested in these as well!
<TSB>
Rick Keller |A1200/030/882/40mhz, 2 chip,8 fast, 540 meg Qantum
be...@net.bluemoon.net |internal, 730 NEC, Sanyo 256 CD-ROM via SurfSquirrel
http://bluemoon.net/~bela |33.6 bps NewCom
<TSB>
Drop your carrier ... we have you surrounded!