greyelf@wpi.wpi.edu (Michael J Pender) (01/16/90)
I'm looking for a good version of C for the Apple. I have a 3.5 inch drive, a Laser 128ex (3.6MHz), and a 256K ramcard in slot 5. The usual mouse, built in drive, modem, etc... I want to write routines in C, compile them, and use the object code generated as a program under Prodos. I need to be able to use very fast code under prodos for a project I'm working on. I would use pascal if I found a version that worked under Prodos with a minimum of necessary memory taken up. But I need to learn C for a class here at school anyway. I had Hyper C, but didn't know how to get started using the c language, and quickly became irritated trying to write a program on the tiny space alloted on the system disk. I want something that can make use of a 3.5 inch drive. So, are there any good C compilers under Prodos that are cheap (read poor college student). tanks in advance - Mike. --- Michael J Pender Jr Box 1942 c/o W.P.I. ... (Mankind) has already greyelf@wpi.bitnet 100 Institute Rd. used its last chance. greyelf@wpi.wpi.edu Worcester, Ma 01609 - Gen. MacArthur
pnakada@oracle.com (Paul Nakada) (01/16/90)
In article <6761@wpi.wpi.edu> greyelf@wpi.wpi.edu (Michael J Pender) writes:
I'm looking for a good version of C for the Apple. I have a 3.5 inch drive,
a Laser 128ex (3.6MHz), and a 256K ramcard in slot 5. The usual mouse,
built in drive, modem, etc... I want to write routines in C, compile them,
and use the object code generated as a program under Prodos.
I need to be able to use very fast code under prodos for a project I'm
working on. I would use pascal if I found a version that worked under
Prodos with a minimum of necessary memory taken up. But I need to learn
C for a class here at school anyway.
I had Hyper C, but didn't know how to get started using the c language,
and quickly became irritated trying to write a program on the
tiny space alloted on the system disk. I want something that can make
use of a 3.5 inch drive.
So, are there any good C compilers under Prodos that are cheap (read
poor college student).
tanks in advance - Mike.
Mike,
To make a long story short.
NO.
There are no `good' C compilers for the non GS line.. I have seen
and used Aztec, HyperC, and Orca Small C. There are most definitely
other C compilers for the 65c02 //'s out there, but these represent
the 3 most common approaches to structured languages on 8 bit
platforms.
My system. //c with 8mhz zip chip (effective speed 5.6 mhz)
2 5.25" floopies
1 800k floppy
I will summarize:
a note on p-code vs machine code. p-codes are single byte instuctions
which translate to multi byte instructions with the aid of an
interpreter. generated p-code from now on refers to "interpreted" and
should be viewed as a tradeoff between more space for code and less
speed.
Aztec C. A full blown C as per the Kernighan & Ritchie book.
Probably the most complete C compiler available on the market. Can
compile to 6502 assembly or to p-code. Includes standard IO (stdio)
libraries for portability (ha ha) across platforms. Prodos compatible
and very very slow.
Supports records, int, long, char, pointers and unsigned versions.
HyperC. (shareware version) A subset of C yet fairly complete.
Compiles to a native format disk using native OS. I assume it
compiles to P-code. This is perhaps the fastest of the the 3
compilers. Speed can be attributed to the specialized os and limited
subset of full C. This is the sketchiest of the 3, because of lack of
documentation. Any HyperC hackers care to add?
supports ?? datatypes.
Small C. This is my favorite. This compiler is for people already
familiar with both C and 6502 assembly, because it is the perfect too
for learning the basics of compiler design. Small C is an extremely
limited subset of C. I has one two data types, int and pointer. Both
occupy the same number of bytes (in Orca Small C 4 bytes) Source code
for the compiler is provided and is portable to much more powerful
machines. It compiles to p-code, which when assembling using the orca
assembler, compiles to p-code codes or straight 6502. The orca
environment provides a linker to link program segments (which can be
mixed between C, assembly, and any other compiler for the orca
environment)
prodos compatible, very flexible, and most important, educational.
I have ported the compiler to a Sun 4, so modifications to the
compiler are trivial. Compile time on the Sun is under 2 seconds.
assembly time on my 8 mhz //c is considerably longer.
Like I said to make a long story short.
You will find that the most important aspect of learning C is a
quick compile time and a less than hostile development. I would
suggest investing in a 2400 bps modem (which you probably have) and
using a mini-computer account. I would also heartily suggest using
emacs, the emacs "compile" command and the gdb integrated debugger
from within emacs.
Once you've become familiar with the C Programming language,
you will be able to see the limitations of implementing C on an 8 bit
machine. I have found that no matter how much I appreciate and love
my 8-bit apple //c, there's a time to put my apple // pride aside and
use it as the best damn terminal emulator out there. :-)
I really hope this helps..
-Paul Nakada
pnakada@oracle.comgreyelf@wpi.wpi.edu (Michael J Pender) (01/18/90)
In article <PNAKADA.90Jan15232204@pnakada.oracle.com> pnakada@oracle.com (Paul Nakada) writes: >Any HyperC hackers care to add? Not just yet, but I'm working on it. > >Small C. This is my favorite. This compiler is for people already >familiar with both C and 6502 assembly, because it is the perfect too >for learning the basics of compiler design. Small C is an extremely >limited subset of C. I has one two data types, int and pointer. Both >occupy the same number of bytes (in Orca Small C 4 bytes) Source code >for the compiler is provided and is portable to much more powerful >machines. It compiles to p-code, which when assembling using the orca >assembler, compiles to p-code codes or straight 6502. The orca >environment provides a linker to link program segments (which can be >mixed between C, assembly, and any other compiler for the orca >environment) > >prodos compatible, very flexible, and most important, educational. >I have ported the compiler to a Sun 4, so modifications to the >compiler are trivial. Compile time on the Sun is under 2 seconds. >assembly time on my 8 mhz //c is considerably longer. Does Orca work on the IIe? I've got a thought, but it would mean a lot of work, an assembler/c compiler. The original code written in c on a different machine, and cross compiled or some such. I don't know enough about c to do this myself, but I could write an editor for inclusion in the package. Basically I'm asking if it would be reasonable for us, the net community to take on the project of trying to write a freeware c compiler. Any takers? --- Michael J Pender Jr Box 1942 c/o W.P.I. ... (Mankind) has already greyelf@wpi.bitnet 100 Institute Rd. used its last chance. greyelf@wpi.wpi.edu Worcester, Ma 01609 - Gen. MacArthur
mitch@rbdc.UUCP (Mitch Berry) (02/01/90)
In article <12054@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >activation record. The 6502 hardware stack is too small for serious >C applications even if it were used only to hold return addresses. What about the 65c02? or is it just a slightly souped up 6502b...i dont know about many of the differences of the 6502 & 65c02....
matthew@sunpix.East.Sun.COM ( Sun Visualization Products) (02/02/90)
In article <9541.infoapple.net@pro-generic>, ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes: } In-Reply-To: message from pnakada@oracle.com } } I have uploaded HyperC Prodos to the pro-generic (416)-237-0308. It is in the } data library under the programming card file in Shrinkit form. Anyone who } wants it can get it here. If there is interest i'll type up a dox file to go } with it and upload the source code as well. (p.s. the source is VERY portable } it originated on a Mac was ported to the II in a matter of days and I used it } to pass a course on programming on a 68000 based POS) Aztec C is very } expensive (for casual programming) and is unsupported. SmallC is likely the } best trade-off between cost, functionality and support, although severely } limmited in implementation. HyperC is a FULL K&R implementation including all } data types, plus a couple of extra goodies like anchored variables, you can } specify a variablr to occupy a specific memory location. Very useful for } twiddling bits in softswitches. I tried downloading the files from 'pro-generic' tonight, but was gently rebuked by the system. Logging in as "GUEST" did not permit me to download the file, and attempting to login as "REGISTER" reported the system as full (I'm guessing to many people are trying to get accounts). } Two things prevent me from sending the file to apple.binaries, BINSCII is ugly } and I am unemployed and the long-distance charges are killing me. I'm willing to do the processing and posting if I can get the files. And it would be nice to get the whole package posted to the net. (Heck, I'd send someone a SASE just to get a copy of the whole thing) -- Matthew Lee Stier | Sun Microsystems --- RTP, NC 27709-3447 | "Wisconsin Escapee" uucp: sun!mstier or mcnc!rti!sunpix!matthew | phone: (919) 469-8300 fax: (919) 460-8355 |
greyelf@wpi.wpi.edu (Michael J Pender) (02/03/90)
In article <996@rbdc.UUCP> mitch@rbdc.UUCP (Mitch Berry) writes: >In article <12054@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>activation record. The 6502 hardware stack is too small for serious >>C applications even if it were used only to hold return addresses. > >What about the 65c02? or is it just a slightly souped up 6502b...i dont >know about many of the differences of the 6502 & 65c02.... The 65c02 wouldn't really help. The additional instructions of the 65c02 are mostly concerned with a new addressing mode, a short range absolute branch, instructions to push and pop x and y on and off the stack, an instruction to store zeroes in memory, and the test and set bits and test and reset bits instructions. They make some common operations faster. On the other hand, the 65c802 would be well suited to the task. It is pin-compatible with the 6502 and 65c02, and has a stack pointer and fast access pointer. The stack could be made very large by simply testing the stack pointer, and when it reaches a given value, incrementing the stack page pointer. This would allow a real dynamic stack that could grow and shrink. The 6502 and 65c02 are fast for zero page addresses. The fast access pointer allows fast access instructions to be set to access any page. --- Michael J Pender Jr Box 1942 c/o W.P.I. ... (Mankind) has already greyelf@wpi.bitnet 100 Institute Rd. used its last chance. greyelf@wpi.wpi.edu Worcester, Ma 01609 - Gen. MacArthur
rlw@ttardis.UUCP (Ron Wilson) (02/03/90)
In article <1108@greens.East.Sun.COM>, matthew@sunpix.East.Sun.COM ( Sun Visualization Products) writes: > >In article <9541.infoapple.net@pro-generic>, ericmcg@pro-generic.cts.com (Eric Mcgillicuddy) writes: >} In-Reply-To: message from pnakada@oracle.com >} >} I have uploaded HyperC Prodos to the pro-generic (416)-237-0308. It is in the >} data library under the programming card file in Shrinkit form. Anyone who >} wants it can get it here. If there is interest i'll type up a dox file to go >} with it and upload the source code as well. (p.s. the source is VERY portable > > I tried downloading the files from 'pro-generic' tonight, but was gently >rebuked by the system. Logging in as "GUEST" did not permit me to download >the file, and attempting to login as "REGISTER" reported the system as full >(I'm guessing to many people are trying to get accounts). > > >} Two things prevent me from sending the file to apple.binaries, BINSCII is ugly >} and I am unemployed and the long-distance charges are killing me. > > I'm willing to do the processing and posting if I can get the files. >And it would be nice to get the whole package posted to the net. (Heck, >I'd send someone a SASE just to get a copy of the whole thing) > >Matthew Lee Stier | For the benefit of those only interested in the source for this compiler, please post the source in one or more shell archives (compress (ie: LZW) or pack (ie: the Un*x pack utility) are acceptable - few Un*x systems support more than these). Thanks in advance.
stephens@csadfa.cs.adfa.oz.au (Philip Stephens) (02/05/90)
In article <7604@wpi.wpi.edu>, greyelf@wpi.wpi.edu (Michael J Pender) writes: > >In article <12054@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: > >>The 6502 hardware stack is too small for serious > >>C applications even if it were used only to hold return addresses. > > The 65c02 wouldn't really help. The additional instructions of the > 65c02 are mostly concerned with a new addressing mode, a short > range absolute branch, instructions to push and pop x and y > on and off the stack, an instruction to store zeroes in memory, > and the test and set bits and test and reset bits instructions. The fact is, the 6502 (and it's equivilants) are _not_ suited for optimized code generation or speed, in relation to high level languages such as C or Pascal. These languages need a large run time stack, and some decent indexing instructions. Thus, the easiest way to implement C or Pascal is to get the compiler to generate P-code (which is a stack oriented pseudo-machine language). C programs translate extremely easily into P-code, but you either need an interpreter for the P-code (which is not much faster than interpreted BASIC), or an assembler to convert P-code to 6502 code (which produces very inefficient and _long_ object code). Even optimized 6502 code translated from P-code will not run as well as the code for better-suited microprocessors. Sorry if all this has been said before. It's hard to keep track of all the traffic. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ _-_ Philip J. Stephens -_- `My Apple II+ may only have 64K, one _-_ _-_ Department of Computer Science -_- 5 1/4 " drive, a stuffed joystick, _-_ _-_ University College, Canberra -_- and run at 1 MHz; but it's mine!!!' _-_
reeder@reed.UUCP (Doug Reeder) (02/05/90)
In article <17437@athertn.Atherton.COM> paul@Atherton.COM (Paul Sander) writes: >Here's an idea I've been kicking around. How about using two stacks? Use the >6502 hardware stack for just the return addresses, and keep the activation >records in a separate stack just below the OS? Four bytes in zero page are >needed to keep the software stack pointer and frame pointer; addition and >subtraction on zero-page variables are fairly efficient, as are small memory >moves. Larger memory moves would be only slightly tricky if structures are >passed. Some optimization is also possible when copying parameters to the >stack if the things passed are allocated in the same order as they are to >appear on the stack. > >What do the compiler experts think? Is this plausible? Two stacks is entirely possible. GraFORTH was a Forth variant that was blindingly fast. Forth tends to be real fast because the program writer has to do a lot of work that other languages do for you. Forth uses the stack extensively. Graforth implements both a variable stack and a return stack separate from the 6502 stack, as zero page pointers to regions in main memory. One interesting thing to do when a subroutine is called is to have the subroutine always use the same memory space. You save the contents before you call, in dynamically allocated memory, and then restore them after the subroutine returns. All static variables have an absolute location in memory, which substantially reduces access time over indirectly referenced static variables. The chief disadvantage is that the variable space for ALL subroutines is always allocated, whether they are active or not. This is offset by the smaller code size. Making a subroutine call then has a substatial overhead, unless you have the compiler turn off varable saving for a non-recursive program. This is, in fact, the method used in Aardvaark Pascal. -- Doug Reeder USENET: ...!tektronix!reed!reeder from ARPA: tektronix!reed!reeder@berkeley.EDU BITNET: reeder@reed.BITNET the Little Mermaid on materialism: I just don't see how a world that makes such wonderful things ... could be bad!