brinkema@fjcnet.GOV (John R. Brinkema) (09/08/89)
I am about to purchase a C development enviroment (C compiler, plus
friends) to do some software development on my IIGS. I am interested
in what the experienced developers recommend.
I am a very experienced C programmer (a lot under UNIX, some on a
Mac using THINK's Lightspeed C .. which I like a lot!). Of course I
have a IIGS, a hard disk, 1.25 M memory, but little else other than
a great deal of interest.
tnx. jbblochowi@rt18.cs.wisc.edu (Jason Blochowiak) (09/08/89)
In article <197@fjcp60.GOV> brinkema@fjcnet.GOV (John R. Brinkema) writes: >I am about to purchase a C development enviroment (C compiler, plus >friends) to do some software development on my IIGS. I am interested >in what the experienced developers recommend. > >I am a very experienced C programmer (a lot under UNIX, some on a >Mac using THINK's Lightspeed C .. which I like a lot!). Of course I >have a IIGS, a hard disk, 1.25 M memory, but little else other than >a great deal of interest. > tnx. jb Well, don't get your hopes up too much... Both of the C compilers available for the //gs are mediocre at best. There's APW C, which seems to be a port of Megamax C with a 65816 code generator stuck on the end, and Orca/C which (as far as I know) is a complete from-scratch compiler. Both are buggy. According to a friend (I haven't checked it yet), if you do "a += 1.0" where a is a float, APW C will generate code that crashes. Orca/C is worse - on every program that I've written, I've discovered a new bug - the worst is that they're so basic, I'm frightened about how many subtle bugs will be generated. Two blatant examples: In one program, I do a switch (char variable) with a few cases and a default. The compiler either 1) Didn't generate the code associated with the default clause (what, a parse tree with dutch elm disease? Look, ma, another branch just fell off...), or 2) Just didn't generate the proper branch. I didn't poke that far into the disassembly (just far enough to figure out that it was the compiler, and not my code or my imagination). The second example: typedef struct { int junk } x; x bug[] = {{1},{2},{3}}; main() { int i; for (i = 0;i < 3;i++) printf("%d ",bug[i]); } The program will print out "1 1 1 ". What happened was at some point the compiler decided that (sizeof(x) == 0). If the array is dimensioned, e.g. "x bug[3] = ..." the code works as it should. The Orca/C libraries are much smaller than APW C's - I haven't had much reason to check if they work. printf(), gets(), and atof() appear to work as advertised... By smaller, I mean the code is smaller - they appear to have the complete ANSI C library routines. Neither of them is particularly speedy, but with a TransWarp GS, they're tolerable (without one, though, you'll develop new "waiting for the compiler" habits). I think that Orca/C is faster, but haven't done any testing. Orca/C comes with a (buggy to the point of uselessness) desktop environment, as well as an (fairly bug free) APW compatible text-based shell (the desktop environment also allows access to the shell). APW C requires the APW shell (which also includes a pretty nice macro assembler and some other utilities). The desktop environment includes a (Pascal oriented, although not much) source level debugger, in which there are also bugs (either that, or Orca/C creates bad information for it). There's a text based debugger for APW (when I say APW, I'm referring to the APW shell as well as the text-based Orca shell) that's pretty nice, considering its simplicity (it's not even symbolic). Orca/C allows you to create NDAs and CDAs as well as normal programs (EXE & S16). APW C requires a bunch of weird shit with setjmp to support NDAs, and can't be used to write CDAs. Orca/C also supports more calling conventions, which make doing certain things more convenient. Basically, Orca/C has more "stuff", but is significantly buggier than APW C. APW C is also not ANSI compatible (no function prototyping...). Oh, speaking of function prototyping, Orca/C doesn't allow prototyping toolbox calls, which is really annoying, considering the large number of calls in a standard desktop program. Neither is great, but they work, sort of... If you (or somebody else) has more questions, ask away... Jason
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/08/89)
In article <197@fjcp60.GOV> brinkema@fjcnet.GOV (John R. Brinkema) writes: >I am about to purchase a C development enviroment (C compiler, plus >friends) to do some software development on my IIGS. I am interested >in what the experienced developers recommend. There are only two sensible choices that I know of: APW C (plus APW itself, or the ORCA desktop environment) and ORCA/C (shipped with the desktop environment). The basic APW environment is text-oriented while ORCA provides an APW-compatible environment that also includes graphic- oriented operation (including mouse-driven text editing) and a source level debugger. At present APW C supports pretty much the K&R I language, with Apple extensions such as a "pascal" storage class for functions, while ORCA/C attempts to provide a Standard C (K&R II) environment, again with Apple extensions. Both now come with headers for IIGS ToolBox access. APW and APW C are available only from APDA, while ORCA/C is available from ByteWorks and may be found in some software stores. I have both and find that each has its own set of problems. Generally ORCA/C seems to be more useful, especially given its debugging environment.
blochowi@rt5.cs.wisc.edu (Jason Blochowiak) (09/08/89)
In article <2940@puff.cs.wisc.edu> I wrote:
<typedef struct { int junk } x;
<
< x bug[] = {{1},{2},{3}};
<
<main()
<{
< int i;
<
< for (i = 0;i < 3;i++)
< printf("%d ",bug[i]);
Whoops, this should be:
printf("%d ",bug[i].junk);
Guess I shouldn't complain about bugs too much, eh? ;)
<}
<
< The program will print out "1 1 1 ". What happened was at some
<point the compiler decided that (sizeof(x) == 0). If the array is dimensioned,
<e.g. "x bug[3] = ..." the code works as it should.
<
< Jasonwombat@claris.com (Scott Lindsey) (09/09/89)
In article <197@fjcp60.GOV> brinkema@fjcnet.GOV (John R. Brinkema) writes: >I am about to purchase a C development enviroment (C compiler, plus >friends) to do some software development on my IIGS. I am interested >in what the experienced developers recommend. If you have the choice, I really recommend MPW's CIIgs compiler. From what I've seen, it fixes a lot of the problems in APW C. Cross-development is the way to go if you can afford it. All of AWGS' source has been ported to MPW and it makes for a much better development environment. Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or Dead.
gwyn@smoke.BRL.MIL (Doug Gwyn) (09/09/89)
In article <WOMBAT.89Sep8171013@claris.com> wombat@claris.com (Scott Lindsey) writes: >All of AWGS' source has been ported to >MPW and it makes for a much better development environment. One lesson that UNIX taught us is that the development environment will quickly improve if the developers themselves use it. I hope the DTS staff themselves work in a IIGS environment instead of running to the Macintosh. Many programmers cannot justify buying a Macintosh system to support their Apple IIGS!
martyp@pnet02.gryphon.com (Martin Peckham) (09/09/89)
It's my opinion that APW C generates VERY POOR code and it has almost no
possibilities of an optimizer. It's reasonably compatable with the PCC
compiler and is definitely NOT ANSI compatable.
As for Byteworks ORCA/C, it has PARTIAL ANSI compatability and as I've
mentioned before that it is too buggy to use right now.
Those are the only two C compilers specifically for the gs. Manx has a C
compiler that will generate 6502 code for ProDOS or DOS 3.3.
Marty
UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!martyp
INET: martyp@pnet02.gryphon.comwombat@claris.com (Scott Lindsey) (09/10/89)
In article <11003@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: In article <WOMBAT.89Sep8171013@claris.com> wombat@claris.com (Scott Lindsey) writes: >All of AWGS' source has been ported to >MPW and it makes for a much better development environment. One lesson that UNIX taught us is that the development environment will quickly improve if the developers themselves use it. I hope the DTS staff themselves work in a IIGS environment instead of running to the Macintosh. Many programmers cannot justify buying a Macintosh system to support their Apple IIGS! Yes and no. We developed AWGS (as StyleWare) completely under APW. Both 1.0 and 1.0v2 were built under APW. We had to work around the problem of the linker not being able to handle anything as large as our program (we built 6 separate modules and 1 driver and wrote a program to combine the 7 executables into one final program). We jumped at the chance to switch to MPW after shipping 1.0v2. Secondly, time & space: AWGS has > 5Mb of source. A total build from source was completely unfeasible under APW. We never attempted it, only assembling files that had change, but I estimate that it would have taken about 4 days. Under MPW, a total build from source takes about 3 hours. I'm not advocating buying a Mac just to support your IIGS. I'm saying that if you want to do serious development (not just programming), it will probably be worth the trade-off. I would have to assume that DTS supports (& tracks bugs, etc) whichever program on whichever machine it was written for (APW - IIgs, MPWIIGS - Mac, etc). Nothing else makes sense. I do know that the IIgs System Software is maintained under MPW. Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or Dead.
mmunz@pro-beagle.cts.com (Mark Munz) (09/10/89)
Network Comment: to #10361 by claris!wombat@apple.com Scott Lindsey writes : > I'm not advocating buying a Mac just to support your IIGS. I'm > saying that if you want to do serious development (not just > programming), it will probably be worth the trade-off. The problem with that is that if serious development work is done on Macs, APW will NEVER be improved... Merlin (the faithful assembler) has been improved because it is used by a good number of developers. --Mark Munz
wombat@claris.com (Scott Lindsey) (09/11/89)
In article <8909101748.AA04697@trout.nosc.mil> mmunz@pro-beagle.cts.com (Mark Munz) writes: Scott Lindsey writes : > I'm not advocating buying a Mac just to support your IIGS. I'm > saying that if you want to do serious development (not just > programming), it will probably be worth the trade-off. The problem with that is that if serious development work is done on Macs, APW will NEVER be improved... Merlin (the faithful assembler) has been improved because it is used by a good number of developers. But APW *has* improved. It's come great strides since CPW (the Cortland Programming Workshop), but it seems to have stagnated over the past year or two. I'm not saying it's the best it could be, but I see few signs of it getting much better. If 3rd parties start hacking on it, yes, I can see it improving. The main reasons I say MPW over APW are 1) The GS will never be as fast as the Mac and 2) MPW has been around longer and already has the more powerful tools which make it a better environment. Scott Lindsey |"Cold and misty morning. I heard a warning borne in the air Claris Corp. | About an age of power when no one had an hour to spare" ames!claris!wombat| DISCLAIMER: These are not the opinions of Claris, Apple, wombat@claris.com | StyleWare, the author, or anyone else living or Dead.
jm7e+@ANDREW.CMU.EDU ("Jeremy G. Mereness") (09/17/89)
Mark Munz <mmunz@pro-beagle.cts.com> writes: > Network Comment: to #10361 by claris!wombat@apple.com > > > Scott Lindsey writes : > > > I'm not advocating buying a Mac just to support your IIGS. I'm > > saying that if you want to do serious development (not just > > programming), it will probably be worth the trade-off. > > > The problem with that is that if serious development work is done on > Macs, APW will NEVER be improved... Merlin (the faithful assembler) > has been improved because it is used by a good number of developers. > > --Mark Munz I remember when Macs were programmed with Lisas. But as that machine improved in hardware and system software, native development systems appeared and Lisas were forgotten. I believe that if anything should be done with the MPW X-compiler, it is the development of a capable, ANSI C development system for the GS, as from whas has been posted both APW and ORCA fall way short of the mark. It is essential that the GS stand on its own, as the Mac did in its infancy. It is not reasonable for the GS to rely on a Mac for serious programmig applications. jeremy mereness ============= "A car in every pot; a chicken in every garage" jm7e+@andrew.cmu.edu (Arpanet) r746jm7e@CMCCVB (vax.... Bitnet)