Re: C programming langauge on Apple II

[pausch@saaf.se (Paul Schlyter)]

In article <1156129913.949783.39930@p79g2000cwp.googlegroups.com>,
Leor Zolman <leor@bdsoft.com> wrote:

Hi Leor!  Nice to see you here....

(for those who don't know who Leor Zolman is: he was the creator of
the BDS C compiler which ran under CP/M-80.  BDS C was a little like
Turbo Pascal, but for the C language rather than the Pascal language:
BCS C was smaller and cheaper than other C compilers for CP/M.  It
also compiled much faster and produced smaller executable files -
important features when you're using a computer with quite limited
resources.  I did my very first C programming on an Apple II with the
Z-80 Softcard, using BDS C.)

> Paul Schlyter wrote:
>> In article <1156105359.753280.27470@p79g2000cwp.googlegroups.com>,
>>  <mores_p@hotmail.com> wrote:
>>>Hi!,
>>>
>>>Do they (programmers) use C programming language on Apple II? (II+, IIe
>>>or IIc) I have the impression that most Apple II programmers normally
>>>use either Basic (I did on my Apple II days) or Assembly. I am not sure
>>>if it's correct.
>>
>> That's probably correct under Apple DOS at least.
>>
>> >Also, how do you rate C as a programming language on Apple II? Is it
>> >good?
>>
>> It's decent under Apple II CP/M -- on other Apple II OS'es I wouldn't
>> bother trying to use C.  Perhaps if someone rewrote BDS C in 6502
>> assembly language.... :-)
> 
> I never played with an Apple II, but I do recall learning that the 6502
> had an 8-bit stack pointer... which meant that the usual way of
> implementing automatic storage, on the stack, wouldn't be possible...
> and severe limits on recursion, funciton call nesting depth, etc.,
> would be present at runtime. With that, it seemed much more palatable
> for me to work on an 8080-based C compiler rather than a 6502-based
> one...
>  -leor

Yes, the 256-byte hardware stack of the 6502 is a several limitation
if you want to implement a high-level language.  It's tolerable in
e.g. Applesoft, which has only one single global variable space, plus
user defineable functions which can take only one argument.  But if
you add user definable functions taking any number of arguments, and
local (automatic) variables (both of which is really mandatory in any
decent HLL), you'll quickly run out of stack space with a 256-byte
stack.

There are ways around that of course: implement a software stack, using
a pair of bytes in page zero as stack pointer.  But that means bigger
and less efficient (i.e. slower) code.

Using a CPU with a 16-bit stack pointer, as you did when you created
BDS C, is clearly preferable of course.

-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/