bds@mtgzz.UUCP (12/05/86)
I have a .5 MB ST with SS floppy. I wish to buy a C compiler (choices would be megamax, lattice, and mark williams). Any recommendations? In particular are any of the above NOT distributed on SS disks, and do any include a debugger (MW's ads say they do)? I'm pretty sure I will have to purchase a hard disk as well.
Bicer.ES@XEROX.COM (12/16/86)
Yes folks, it is time to consider a C compiler. I know this subject was discussed extensively, but ... I need a C compiler which is: 1- Usable with 1 single sided drive 520 ST. 2- Fast in compilation. The following points are not absolutely necessary but would be nice: 3- Full K&R. 4- Gem Access and be able to write desk accessories. 5- Assebler support. Currently I am looking into these compilers: - Megamax (a little expensive?) - Lattice (is it usable with 1 drive, and how fast are compilations?) - GST C (not full K&R) All replys are welcome. Thank you in advance, Jack Bicer Bicer.ES@Xerox.COM
oyster@uwmacc.UUCP (Vicarious Oyster) (12/17/86)
In article <861216-121152-4199@Xerox> Bicer.ES@Xerox.COM writes: >I need a C compiler which is: >1- Usable with 1 single sided drive 520 ST. >2- Fast in compilation. > >The following points are not absolutely necessary but would be nice: >3- Full K&R. >4- Gem Access and be able to write desk accessories. >5- Assebler support. > >Currently I am looking into these compilers: >- Lattice (is it usable with 1 drive, and how fast are compilations?) Lattice is not extremely fast, but as with all disk-bound programs, speed can be enhanced through the judicious use of a RAMdisk. My typical compile-link time, using a physical disk for the source file, the object file, and the executable file, is ~1.5 minutes. It can be used with a single-drive system with a bit of one-time adjusting (I currently have 2 drives; when I had only one drive, I had 1MB of RAM, so I may not be accurately describing your situation). As far as I can discern, it is a good K&R implementation. The current version has a couple known bugs, one of which seems especially obnoxious, but I've never personally run into it (something about not generating the correct shift instruction for division by a constant multiple of 2). It has a full GEM library, but the documentation is scarce-- in fact, they provide the assembler source code for the routines (which is good), and tell you to look at the source for complete decriptions (which is not so good). I'm not sure about writing desk accessories. With other C's, you have to link with a different startup module, and they only provide one with Lattice (if anybody has some DA C code sitting around, I could try to get it running with Lattice). I'm not sure if you can imbed assembly code in-line, but Metacomco (the Lattice people) sell a decent assembler. Also, the linker does provide for linking "the other" type of object modules. I have written some reasonably short GEM and non-GEM programs, and I have not had trouble with either flavor. ======================================================================== Somebody else mentioned the Sybex Gem book, saying it fully described GEM. Well, it's a very good book, and I too recommend it; however, there are things it simply doesn't describe (I can't remember offhand, but one of them had to do with the ICON data type. Of course, at the time, I wanted to know about those few things...). Otherwise, it describes GEM in a very understandable way, with plenty of examples, including a full-blown major application. I used it and the Pro*GEM documentation exclusively to puzzle out all the fun GEM features, and that included initializing the data structures by hand, since I have no resource construction set. (My first project was to have been a small RCS that I could use to bootstrap a full-scale RCS, but I started going back to school, as well as learning electronics and computer repair, as well as working nearly full time, while keeping my social calendar full, and... well, I've got a functional spec done! I'm currently investigating all the little pieces of GEM, with an eye towards the RCS, but it's going v e r y s l o w ly.) -- - Joel Plutchak uucp: {allegra,ihnp4,seismo}!uwvax!uwmacc!oyster ARPA: oyster@unix.macc.wisc.edu
jhs@MITRE-BEDFORD.ARPA (12/18/86)
Another C compiler to consider would be the MANX Aztec C, which I understand from a phone conversation with them a few months ago they are in the process of porting to the ST. I have heard that Aztec C for other machines has been pretty good. I don't have MANX's number handy but can get it. They usually advertise in BYTE. Then there is Lightspeed C from Think Technologies of Lexington, MA. This currently runs only on the Mac, but if you have Magic Sac or the new emulator from Europe, maybe you can use it on your ST. Lightspeed C is said to be very fast, e.g. they quote about 6200 lines of code per minute of compile time. If everybody who cares about C would call up Think Technologies and plead with them to port Lightspeed C to the ST, they just might do it. Their phone number is (617) 863-5590. Their sales manager's name is Betty Rock. Another person you could talk to is Ellen Neavitt, with whom I have spoken about the ST market. Another thought: If someone out there with developer tendencies would offer to do the conversion for them, especially on a royalty basis (i.e. at no up-front cost to them), Lightspeed might be very interested. -John Sangster jhs@mitre-bedford.arpa ------------------------------------------------------------------------------ I don't have any financial interest in, nor receive any remuneration from, any of the above-mentioned companies, and darn few others. Drat it.
micah@mit-eddie.MIT.EDU (Micah P. Doyle) (12/22/86)
In article <8612181426.AA17601@mitre-bedford.ARPA> jhs@MITRE-BEDFORD.ARPA writes: >Another C compiler to consider would be the MANX Aztec C, which I understand >from a phone conversation with them a few months ago they are in the process >of porting to the ST. I have heard that Aztec C for other machines has been >pretty good. I don't have MANX's number handy but can get it. They usually >advertise in BYTE. Think twice before waiting for a C compiler from MANX. Last summer, I called them up to find out if they were coming out with a C compiler for the ST. I was told they were and that it would be out in the early Fall. Well, early Fall came, and they said it would be out before Christmas. Now they say it will be out first quarter next year. Can you say "vaporware"? I stopped waiting for them, and just ordered Megamax C. ----- Micah Doyle micah@athena.MIT.EDU mit-eddie!mit-athena!micah
ehood@ics.uci.edu (Earl Hood) (03/04/90)
Hello, I want to get a C compiler for my Mega. But I do not know which compilers are good ones. Can anybody recommend any good compilers at reasonable costs. Thanks, -- Earl Hood (UC Irvine) -------------------------------> ehood@paris.ics.uci.edu =============================================================================== When in doubt Reboot! ===============================================================================
boyd@fsucs.cs.fsu.edu (Mickey Boyd) (03/04/90)
In article <25F02612.3980@paris.ics.uci.edu>, ehood@ics.uci.edu (Earl Hood) writes: >Hello, > I want to get a C compiler for my Mega. But I do not know which >compilers are good ones. Can anybody recommend any good compilers at >reasonable costs. > >Thanks, > >-- >Earl Hood (UC Irvine) -------------------------------> ehood@paris.ics.uci.edu >=============================================================================== > When in doubt Reboot! >=============================================================================== I am getting ready to do this myself. All indications point to Prospero C as the best choice in my book (ANSI standard, real support, good docs, complete language family to work with). I suggest both to myself and you, however, to try the two PD C compilers, Sorbon and GNU. I have seen much net buzz on them, but I do not know if they are complete (ie GEM library, ability to use from GEM instead of a command line interpreter, etc). When I say complete, I mean the ability to create stand alone GEM, TOS, and TTP applications easily. -- ----------------------------------------------------------------------- ---------------------------------+------------------------------------- Mickey Boyd | "Nobody can be exactly like me. FSU Computer Science | Even I have trouble doing it." mail: boyd@fsucs.cs.fsu.edu | - Tallulah Bankhead ---------------------------------+------------------------------------- -----------------------------------------------------------------------
D.C.Halliday@newcastle.ac.uk (Dave Halliday) (05/01/91)
There is also the question of ANSI compatibility. So Here is my revamped table. name memory src price ANSI Debuger Notes ---------------------------------------------------------------------------- GNU C 2Meg+ yes nil Y poor for ST UNIX origins Sozobon C 520K yes nil N none?? PD MW C 520K no #110 N Src Level No longer updated Prospero C 520K no #100 Y Src Level Links to other Prospro langs Turbo C ?? no ?? Y Src Level Only in german Lattice V5 R 1Meg+ no #110 Y Low Level Optomiser Laser C R 1Meg+ no #100 N Src Level Very fast compile times ---------------------------------------------------------------------------- Notes: Prospro C links with other Prospro product because it uses the GST format and not a propriety format. Some other compiler may offer GST link format also (I know Lattice C offers both GST and Lattice libraries.) The R in the memory section indicates that 1meg of memory is recomended but the compiler can be run in 520K. Prices are in pounds sterling and are very approximate mail order prices. I think that covers all the C compilers I know of with the exception of Alcoyn C which is very dated and Hisoft C interpreter (not a compiler and only offers a subset of K&R C). Corrections to the above always welcome. As a recomendation I would say the following if you have lots of memory, hard disk and no need for commercial support or documentation go for GNU C. If on a budget and have a less powerfull setup Sozobon should serve you well. If good profesional support is your prime thought I would recomend Prospro C. Turbo C is good if you read german. If executable efficiency is your prime criteria then Lattice C can't be beeten (though Turbo C is close). Finally if compile speed is required then Laser C is the best bet (I'ts one pass compiler compiles at an order of magnatude faster than many of the other compilers.) So each compiler has its strengths. For those wondering what my bias is I own GNU C and Lattice C Vsn5. Dave H. (D.C.Halliday@newcastle.ac.uk)
hyc@hanauma.jpl.nasa.gov (Howard Chu) (05/02/91)
Just fyi, the Mark Williams library source code is available for a price. The compiler innards seem to be kept pretty hush-hush, though. I have the library code, it's been pretty useful to have at times. -- -- Howard Chu @ Jet Propulsion Laboratory, Pasadena, CA Disclaimer: How would I know, I just got here!
jimomura@lsuc.on.ca (Jim Omura) (05/02/91)
In article <1991Apr30.193021.10443@newcastle.ac.uk> D.C.Halliday@newcastle.ac.uk (Dave Halliday) writes: > >There is also the question of ANSI compatibility. So Here is my revamped >table. > >name memory src price ANSI Debuger Notes >---------------------------------------------------------------------------- >GNU C 2Meg+ yes nil Y poor for ST UNIX origins >Sozobon C 520K yes nil N none?? PD I have source files from the '...st.sources' newsgroup that are supposed to be a source debugger for Sozobon C. I haven't even unpacked it yet though so I can't say more than that. Also Sozobon is NOT Public Domain. It's currently "Free". There's no guarantee that any or all future versions will also be free. Personally, I'm hoping they make at least one more free distribution which will be the definitive cleaned-up official version. After that, I don't care if they go "commercial". But I think they sort of owe it to the people who have helped them "beta test" this compiler. >Lattice V5 R 1Meg+ no #110 Y Low Level Optomiser I'm thinking about buying a Lattice. I'm working with a 1040ST, and when you have a bunch of ACC's loaded, I'm wondering if I'll might have a problem. It is really that touchy about RAM? >So each compiler has its strengths. -- Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 lsuc!jimomura Byte Information eXchange: jimomura
saj@chinet.chi.il.us (Stephen Jacobs) (05/02/91)
In article <1991May2.005744.21765@jato.jpl.nasa.gov> hyc@hanauma.jpl.nasa.gov (Howard Chu) writes: >Just fyi, the Mark Williams library source code is available for a price. >The compiler innards seem to be kept pretty hush-hush, though. What the Mark Williams people have let out (that I know of) is that the ST C compiler is a 'clean room' version of the UNIX portable C compiler (specified to behave the same way, but no source code in common). It was done in conjunction with the development of 'Coherent'. The compiler itself #define-s the symbols __GEMDOS__ and __STDC__ (I don't know the value __GEMDOS__ gets, but __STDC__ gets the value 0). If you call them and ask for Atari ST C support, the person helping you will have access to the compiler source code. I should clarify myself a bit: ST C is _related_ to the Coherent C compiler, it isn't necessarily the same. Steve saj@chinet.chi.il.us
johns@maccs.dcss.mcmaster.ca (Conan the Barbarian) (05/02/91)
In article <1991May2.023153.7191@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: >[...] > I'm thinking about buying a Lattice. I'm working with >a 1040ST, and when you have a bunch of ACC's loaded, I'm wondering >if I'll might have a problem. It is really that touchy about >RAM? >[...] My recommendation goes to Lattice 5. A friend of mine stepped up to Lattice from Laser, and I've played with Turbo some. The things that might make me go with Turbo are the excellent help facility and the debugger, but the Lattice library manuals are pretty good so the help that Turbo provides is only a nominal. As for the debugger, who has bugs?? :-) Lattice was not practical from it's editor/environment. It takes up too much memory. (That's on a 1Meg machine, with HD) You can compile single files nicely from the environment, but if you need make like I did, it doesn't work out too nicely. I tried to install make as a tool so I could run it with a single keypress, but I ran out of memory. But I prefer the CLI anyway, and then no problems. -- John Schmitt johns@maccs.dcss.mcmaster.ca ...!unet!utai!utgpu!maccs!johns
klamer@mi.eltn.utwente.nl (Klamer Schutte) (05/02/91)
In <1991Apr30.193021.10443@newcastle.ac.uk> D.C.Halliday@newcastle.ac.uk (Dave Halliday) writes:
Some changes to the C compiler table
->name memory src price ANSI Debuger Notes
->----------------------------------------------------------------------------
->GNU C 2Meg+ yes nil Y poor for ST UNIX origins
->Sozobon C 520K yes nil N none?? PD
Low Level
->MW C 520K no #110 N Src Level No longer updated
->Prospero C 520K no #100 Y Src Level Links to other Prospro langs
->Turbo C ?? no ?? Y Src Level Only in german
R 1Meg+
->Lattice V5 R 1Meg+ no #110 Y Low Level Optomiser
->Laser C R 1Meg+ no #100 N Src Level Very fast compile times
->----------------------------------------------------------------------------
->Notes: Prospro C links with other Prospro product because it uses the GST
->format and not a propriety format. Some other compiler may offer GST link
->format also (I know Lattice C offers both GST and Lattice libraries.)
->The R in the memory section indicates that 1meg of memory is recomended but
->the compiler can be run in 520K.
->As a recomendation I would say the following if you have lots of memory, hard
->disk and no need for commercial support or documentation go for GNU C. If on
->a budget and have a less powerfull setup Sozobon should serve you well. If
->good profesional support is your prime thought I would recomend Prospro C.
->Turbo C is good if you read german. If executable efficiency is your prime
->criteria then Lattice C can't be beeten (though Turbo C is close). Finally if
I think TurboC is a bit faster in execution times than Lattice C. But TurboC
has 16 bits ints where Lattice has 32 bits -- thats the difference.
->compile speed is required then Laser C is the best bet (I'ts one pass
Hmmm. TurboC is also one-pass. And very fast compilation!
Also its integrated edit-compile environment is a very nice way to write
&& debug GEM programs (also due to its build-in online GEM manual).
->compiler compiles at an order of magnatude faster than many of the
->other compilers.)
When one wants to compile U*IX programs conformance to U*IX libaries is
also important. Of the compilers i know the order of compliance is:
GNU - MWC - Sozobon - TurboC.
I don't know about the other ones.
->So each compiler has its strengths.
True.
->For those wondering what my bias is I own GNU C and Lattice C Vsn5.
I own GNU (but not enough memory :-(), Sozobon (slightly buggy &&
slow compilation), MW C (Unix like environmemt), Megamax (Old version of
LaserC), MJ C (An old PD C version -- slow, subset of K&R) and TurboC
(Fast in compile && execute, but ANSI only -- a drawback sometimes).
Klamer
--
Klamer Schutte
Faculty of electrical engineering -- University of Twente, The Netherlands
klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamerneil@cs.hw.ac.uk (Neil Forsyth) (05/03/91)
In article <1991May2.023153.7191@lsuc.on.ca> jimomura@lsuc.on.ca (Jim Omura) writes: > ... Sozobon is NOT Public Domain. It's currently "Free". Now what does that actually mean? Less or more legal rights than PD? >There's no guarantee that any or all future versions will >also be free. Personally, I'm hoping they make at least one >more free distribution which will be the definitive cleaned-up >official version. After that, I don't care if they go "commercial". >But I think they sort of owe it to the people who have helped >them "beta test" this compiler. I don't think Sozobon could go commercial now even if they wanted to. People would always regard it as free since it's been free for so long. Look at NEOchrome. I have had official word from Atari that it is NOT Public Domain yet PD Librarys are distributing version 1.00 and the CHAOS version. Sozobon would have to change it's name at least to avoid this. Anyway I think the Sozobon C compiler is bl**dy great! I use it all the time. Students here with ST's use it home for their projects. I just wish it had been supported more by the original authors and the net's compiler gurus. Atari should bundle it with an ST 'Programming Pack'. >-- >Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880 >lsuc!jimomura >Byte Information eXchange: jimomura +----------------------------------------------------------------------------+ ! DISCLAIMER:Unless otherwise stated, the above comments are entirely my own ! ! ! ! Neil Forsyth JANET: neil@uk.ac.hw.cs ! ! Dept. of Computer Science ARPA: neil@cs.hw.ac.uk ! ! Heriot-Watt University UUCP: ..!ukc!cs.hw.ac.uk!neil ! ! Edinburgh, Scotland, UK Raving Monster Looney Party won a seat! ! +----------------------------------------------------------------------------+