Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!cmcl2!harvard!topaz!ll-xn!mit-amt!mit-eddie!genrad!decvax!wanginst!apollo!nazgul From: nazgul@apollo.uucp (Kee Hinckley) Newsgroups: net.micro.apple Subject: Re: C compiler for apple ][ ??? Message-ID: <2dac102d.7005@apollo.uucp> Date: Tue, 13-May-86 16:43:05 EDT Article-I.D.: apollo.2dac102d.7005 Posted: Tue May 13 16:43:05 1986 Date-Received: Thu, 15-May-86 07:31:36 EDT References: <368@hope.UUCP> <249@ski.UUCP> Reply-To: nazgul@apollo.UUCP () Distribution: net Organization: Apollo Computer Inc., Chelmsford MA Lines: 117 In article <249@ski.UUCP> dr@ski.UUCP (David Robins) writes: > > I'm looking for information about C compilers for the apple ][. Any > > information would be GREATLY appreciated. > > Aztec-C Developer's package > has both a pseudo-code and native code compiler > can link program modules of any mixture of these types > to get a compact program with fast (but larger) parts > for the time-consuming loops, etc. > (but I don't know if a runtime package is needed for > the pseudo-code in this mixture) > CAN PRODUCE stand-alone code- additional 2-4K runtime code > Price ~199.00 You don't really have to worry about the difference between psuedo-code and real-code stuff. Everything links together and the interpreter is linked in automatically. You can use both interpreted and compiled code in standalone compiled modules as well as ones that run under the shell. Generally you do all of the development work under the shell, and then just bind in the standalone library instead when you are ready to test the final product. > > Aztec-C Commercial package (supports PRODOS and DOS 3.3) > in beta-test now (not available) > will support some RAM addition (/RAM like PRODOS ???) > Price ~299.00 > Currently the only ram support in this version is the /ram ramdisk. The shell in this is also much more powerful, it supports both wildcards and environment variables. In particular you can use special environment variables like CCTEMP and INCLUDE to specify where to put temporary files (on the ram disk usually) and where to look for include files (INCLUDE has the same format as PATH, which is also supported). > The Developer's version allows overlay code, so programs can be any > size, and parts can be swapped in from disc. I don't know about support > for hard drives. I've tried using the DOS3.3 stuff on my hard drive (CMC with the PROFIX software support for DOS volumes on the drive) but PROFIX modifies DOS too much for Aztec to deal with it. I don't know if there are any work arounds. The PRODOS stuff works like a charm on a hard drive though. > > These packages require unmodified DOS in the standard location, so > pseudo-RAM drives and DOS-movers cannot be used. Yes and no. As I mentioned above, a very modified DOS won't work, but I've been using a RAM disk I typed in from a NYBBLE article several years ago and it works fine, in fact I'd hate to have to work without it. Generally I put the C compiler and editor (with a few tools) on one drive, the source/binary disk on a second, and the files I am currently working on on the ram drive. Then I set working directory to the ram drive. My compile scripts tell the compiler to always look for the file on the ram drive, but to put the final binaries on the source drive. All of the temporaries (where most of the reading/writing occurs) are on the ram. You can't fit both the linker and the compiler on one disk though, so you still have to do some disk swapping. > The company tech I spoke to recommended the PC systems, rather than the > Apple systems, because of the larger space available in the PC, and the > lack of interference with the graphics pages. The PRODOS version has a linker option to leave holes in the linked text. This should allow you to easily use the graphics areas. If the program is small you can either link it under the graphics page, or over it. If you're to large do that there is one more hack you can do. If you just want to use the graphics screen occasionally you can copy the code out of the way, show your pictures, and then copy it back. This actually works pretty well so long as you make sure that the code to do the copy sits somewhere else. In any case these problems all should go away with the PRODOS version (I haven't actually tested that feature yet). ---------------- There are a couple other C compilers on the market now, all in the $50 price range. I don't know too much about them but I suspect that they have nowhere near the library/shell support that Manx provides. One of them had a product announcement in the latest A+ (they called it a C++ compiler, but that was before they realized there was already a langauage called C++). The other compiler is the Small-C compiler. It's really not a development language, it doesn't support anywhere near the full language, but it's available with source from the people who put out the ORCA/M assembler. You'll need to buy the assembler as well. If you're going to do any development, particularly for more than one machine, I definitely recommend the Aztec compilers. They run on a wide variety of machines. The benchmarks generally show them around the top in compile/run speed, and they support just about every UNIX system call (generally circa SysIII) that you might want. I've found some bugs in using them, but nothing I couldn't work around, and they have a bulletin board you can leave bug reports on and talk to other users. -kee Disclaimer: I don't work for Manx, Apollo doesn't use their compilers, and all these distorted views are my own. -- ...{yale,uw-beaver,decvax!wanginst}!apollo!nazgul This is the Button to Start the Machine To make with the Cybernetics and Stuff To cover Chaotic Confusion and Bluff That hung on the Turn of a Plausible Phrase And thickened the Erudite Verbal Haze Cloaking Constant K That saved the Summary Based on the Mummery Hiding the Flaw That lay in the Theory Jack built. A Space Child's Mother Goose (1 more message to finish this poem!)