[comp.sys.apple] C on the IIGS..

dougm@pnet51.cts.com (Doug Mcintyre) (03/21/89)

Well, talking about C compiler and what not, Orca/C is due out by Applefest.
It is full ANSI, and includes most of the libraries ANSI specifies (excluding
some multi-tasking stuff that wouldn't do a thing on the IIGS). From what I've
seen it is very nice (I'm a tester for them.). It will allow you to pick a
couple different memory models, a small model for segments totally inside of
one bank, and a large one that is simular to the model presented by APW C.
I can't say too much about the code it generates right now, as it is producing
code to be used by debugging. It does use the desktop debugger or course,
which is very* nice..

        As for APW C, I've found a lot* of unrepeatable bugs, mostly having to
do with its pre-processor. Of course I can't pare it down some to send in, and
I don't really want to send them a 30-40k file for them to scratch their head
at and then complain to megamax or whoever made the compiler for them. The APW
C libraries aren't too bad, but I've found a bug, and a couple things I think
should go the otherway than they have them, but anyway..

        Using the toolbox from C involves putting one* thing into the
compiler. APW C uses the inline() statement which will just push all its
arguements and then jsl to the place you specify. Thats all a compiler has to
provide to do any toolbox. All the rest reside in header files, and not even
in the library (oh and APW C also provides a \p escape to make programming a
little easier for you..) So adding toolbox support puts a lot of appeal into a
compiler with adding essentially nothing..

        Writting a C compiler for a 65802 would be difficult. There isn't a
whole lot of memory there in the first place. C really is a stack based
language, and would just love taking up about 4k or so of stack space. Now
where are you going to stick the code? around this 4k of stack and then hope
that there isn't any wild dereferencing the can trash code around the stack,
or that the stack doesn't grow too big? The 65816 does lend itself quite
nicely with its nice stack control features. C and the 65816 get along
nicely.. For the 65802, the stack features are there, but you have to really
reserve bank 0 for system type stuff and the stack/direct page segments. And
that leaves you with another bank to paly around with in code. Generally
difficult.. Byteworks is not planning on doing a 65802 code version of the
Orca/C compiler..

UUCP: {rosevax, crash}!orbit!pnet51!dougm                Compuserve: 70611,2215
ARPA: crash!orbit!pnet51!dougm@nosc.mil                        ALPE: DougMac
INET: dougm@pnet51.cts.com

gwyn@smoke.BRL.MIL (Doug Gwyn ) (03/22/89)

In article <778@orbit.UUCP> dougm@pnet51.cts.com (Doug Mcintyre) writes:
>It is full ANSI, and includes most of the libraries ANSI specifies (excluding
>some multi-tasking stuff that wouldn't do a thing on the IIGS).

ANSI C doesn't address multitasking at all.
Perhaps you're thinking about multibyte character sets?
Or even IEEE Std 1003.1-1988?

>Using the toolbox from C involves putting one* thing into the
>compiler. APW C uses the inline() statement which will just push all its
>arguements and then jsl to the place you specify. Thats all a compiler has to
>provide to do any toolbox. All the rest reside in header files, and not even
>in the library (oh and APW C also provides a \p escape to make programming a
>little easier for you..) So adding toolbox support puts a lot of appeal into a
>compiler with adding essentially nothing..

APW C just added one thing, too: the "pascal" qualifier to indicate that
function linkage was to follow Pascal conventions rather than native C.
There is a nice advantage in having the entire linkage done via a header:
The disk storage required for the toolbox support library vanishes.

One would hope that the released version of ORCA/C prefixes their added
keyword(s) with underscores, as required by ANSI C to prevent conflicts
with application names.

Re: multiple memory models: I think this is a mistake.  Could we at
least agree to ignore the small model for anything published in the
newsgroups?  (Publishing source code should suffice.  The problems
mainly arise when linking together object modules/libraries compiled
under different models.)