C compiler for a small CP/M system?
Russell Marks
box with a 4.5MHz Z80, a 46k TPA and a single 256k 'disk' (it actually
has two of these, but the other one is pretty much full, and PCMCIA
memory cards aren't exactly cheap...).
I tried Hitech C - it compiles 'main(){printf("Hello world\n");}' but
that's pretty much the biggest program it can compile in 46k. Besides
that, 'zas' is not quick. I'm sure an assembler written in ZX81 BASIC
would run quicker.
The compiler I use at the moment is Small C v1.2, which works well and
is well suited to running on such cramped machines, but is a bit
lacking in the more advanced language features, like for() and
switch(). ;-)
What I would like is a better C compiler which will run on this
limited system. Any ideas?
-Rus.
--
/ : russell marks :: mr...@gre.ac.uk :: speak softly and carry a +6 kitten : \
| GCS -d+ -p+ c++++ l++ u++ e+(*) m+@ s+/++ n--(---) h+(*) f+ !g w+ t+ r- y? |
\ ::: "His world is under anaesthetic - subdivided and synthetic" - Rush ::: /
John M. Mills
Russell Marks <mr...@GREENWICH.AC.UK> wrote:
>I'm looking for suggestions on the best C compiler to use on a CP/M
>What I would like is a better C compiler which will run on this
>limited system. Any ideas?
You can get MIX C which is supposed to be "full K&R" in matching cp/m
and DOS distribution, but I'm not sure how big it is. I always liked
Software Toolworks C80, which is "nearly K&R" and comes on one 8" ss-sd
disk. (Mathpak is a second disk.) Does anyone know anyone at Software
Toolworks, who might promote a free-distribution policy for these packages
similar to what Hi-Tech did?? I can check out the size, tho ...
Regards --jmm--
--
John M. Mills, SRE -- john.m...@gtri.gatech.edu -- (404)528-3258 (voice)
Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080
Roger Ivie
> The compiler I use at the moment is Small C v1.2, which works well and
> is well suited to running on such cramped machines, but is a bit
> lacking in the more advanced language features, like for() and
> switch(). ;-)
I have Small C 2.3, which I think has for() and I'm certain has switch(). I've
done some work with Aztec C, but not on a machine with only 46K TPA.
--
----------------+------------------------------------------------------
Roger Ivie | Don't think of it as a 'new' computer, think of it as
iv...@cc.usu.edu | 'obsolete-ready'
Mathias Niemz
work on little systems to. It also produces code for amd9511
coprocessor.
--
Mathias Niemz
Snailmail: Lisztstrasse 11 - 31141 Hildesheim - Germany
E-Mail: 76206...@Compuserve.com uucp: (comming up soon)
Phone: (priv)+49-5121-876 932 (business): 15921 Fax: 15405
Will Rose
: I'm looking for suggestions on the best C compiler to use on a CP/M
: box with a 4.5MHz Z80, a 46k TPA and a single 256k 'disk' (it actually
: has two of these, but the other one is pretty much full, and PCMCIA
: memory cards aren't exactly cheap...).
BDS C is pretty much the NATO standard - small and fast and solid.
Version 1.5 had idiosyncratic i/o, but the current 1.6, sold very
cheaply ($30) by Jay Sage, is more standard. I used it a lot on a
machine with a 2MHz Z80 and a 120K ramdisk, and it was fine.
John M. Mills
John M. Mills <jmi...@ccrf-news.gtri.gatech.edu> wrote:
>In article <8857.9501301715@atlas>,
>Russell Marks <mr...@GREENWICH.AC.UK> wrote:
>>I'm looking for suggestions on the best C compiler to use on a CP/M
>>box with a 4.5MHz Z80, a 46k TPA and a single 256k 'disk' ...
>>What I would like is a better C compiler which will run on this
>>limited system. Any ideas?
>Software Toolworks C80, which is "nearly K&R" and comes on one 8" ss-sd
>disk.
I checked and all C80 files including its own assembler/loader and some of
the sources/ alternate library files (but without minimal cp/m utilities) fit
in 276 KBy. HELLO.C and HELLO.COM are 4 KBy (one 'extent'), and HELLO.ASM
is 8 KBy. You might drop 40-50KBy of files from that by judicious selection,
but you still need an editor and probably a couple other utilities. (My total
_does_ include floating point math and float I/O, BTW.) The compiler uses
the disk actively while compiling, so it may need surplus space beyond what
we see here. It was the disk activity of C80 which led me to write a RAMDISK
for my system: it _is_ useful, but I didn't put much time on C80 after I got
it working, as most of my work went to other hosts and/or languages then.
Russell Marks
> >box with a 4.5MHz Z80, a 46k TPA and a single 256k 'disk' ...
>
> >What I would like is a better C compiler which will run on this
> >limited system. Any ideas?
>
> and DOS distribution, but I'm not sure how big it is. I always liked
> Toolworks, who might promote a free-distribution policy for these packages
> similar to what Hi-Tech did?? I can check out the size, tho ...
Being a student, I would obviously prefer free software. :-)
> > The compiler I use at the moment is Small C v1.2, which works well and
> > is well suited to running on such cramped machines, but is a bit
> > lacking in the more advanced language features, like for() and
> > switch(). ;-)
>
> I have Small C 2.3, which I think has for() and I'm certain has switch(). I've
> done some work with Aztec C, but not on a machine with only 46K TPA.
Does v2.3 require M80/L80? (I seem to remember trying it and finding
this a problem.) If so, are there any PD assemblers/linkers which are
sufficiently compatible? I'll check v2.3 out anyway.
> BDS C is pretty much the NATO standard - small and fast and solid.
> Version 1.5 had idiosyncratic i/o, but the current 1.6, sold very
> cheaply ($30) by Jay Sage, is more standard. I used it a lot on a
> machine with a 2MHz Z80 and a 120K ramdisk, and it was fine.
NATO standard? Do they have much development to do on Z80s? :-)
Thanks for the various suggestions.
Roger Ivie
>> I have Small C 2.3, which I think has for() and I'm certain has switch(). I've
>> done some work with Aztec C, but not on a machine with only 46K TPA.
>
> Does v2.3 require M80/L80? (I seem to remember trying it and finding
> this a problem.) If so, are there any PD assemblers/linkers which are
> sufficiently compatible? I'll check v2.3 out anyway.
I'm afraid I don't recall. I just looked, and it isn't currently on my
handy CP/M machine's hard disk; I'd have to dig it out of my pile of
floppies. Apparently, the version I've been playing with lately is the
MS-DOS version, and it's version 2.1. My Kaypro 10 (which _does_ have
Small C on its hard disk) is currently under a big pile of stuff in the
laundry room (and it's probably inconveniently located behind my PDP-8/E,
too).
I have been having fun with the MS-DOS version, though. I've modified it
to put out its intermediate code and written a backend that translates the
intermediate code into VAX assembly: viola! Small-C for the VAX.
By the way, there are a lot of non-obvious things in the compiler source
that assume it's running on a 16-bit machine. It took a while to get it
running on my DECstation...
--
----------------+------------------------------------------------------
Roger Ivie | Never underestimate the bandwidth of a
iv...@cc.usu.edu | truckload of tapes
Johnathan Taylor
on (30 Jan 95) mr...@GREENWICH.AC.UK (Russell Marks) wrote to All...
RM> I'm looking for suggestions on the best C compiler to use on a CP/M
RM> box with a 4.5MHz Z80, a 46k TPA and a single 256k 'disk' (it actually
RM> has two of these, but the other one is pretty much full, and PCMCIA
RM> memory cards aren't exactly cheap...).
Is there no way to increase the available TPA size? addon main ram or a more
space efficient cbios if it's a 64kram system already?
RM> I tried Hitech C - it compiles 'main(){printf("Hello world\n");}' but
RM> that's pretty much the biggest program it can compile in 46k. Besides
RM> that, 'zas' is not quick. I'm sure an assembler written in ZX81 BASIC
RM> would run quicker.
A little trick that'll allow a Hi-Tech C to run in small TPA'd systems is to
invoke each stage manually rather than letting C.COM control the entire show.
Doing it this way is a bit more involved and requires a fuller read of the docs
But it releases the TPA taken up by the resident portion of the $EXEC.COM
batch processor:-)
RM> The compiler I use at the moment is Small C v1.2, which works well and
RM> is well suited to running on such cramped machines, but is a bit
RM> lacking in the more advanced language features, like for() and
RM> switch(). ;-)
Have you tried Small C v2? I'm not too sure about what the extra features are
but it's bound to be better than version 1.2:-)
Just read in it's doc that it require 48k TPA.... So assuming it won't function
at all below 48K of TPA then maybe even this will be out of your range!
It can do:- do...while(), for(), switch() and goto constructs and the doc
states that these could be removed "if you have to shoehorn your compiler into
a small memory space." But you'd first need to recompile the compiler to remove
remove the sacrificed features which would need a 56k TPA to acompilsh that!
RM> What I would like is a better C compiler which will run on this
RM> limited system. Any ideas?
Apart from those ones above, I suspect that to develop programs comfortably
you'll need a slightly better equiped machine:-(
Your other alternative is to program in assembler, that doesn't require a big
system and generally speaking hand-written machine code utils/programs use
less TPA than their compiled C counterparts which is important on such a
TPA challenged machine that you describe!
Sorry I couldn't be of more help:-(
Good luck!
Johnathan.
... If it jams, force it. If it breaks, it needed replacing anyway.
--
|Fidonet: Johnathan Taylor 2:2501/307.9
|Internet: j...@centron.com
|
| Standard disclaimer: The views of this user are strictly his own.
Allison J Parent
small modules and linked later.
I would look into BDS C as I've run it in 40k with success with small
modules. It runs fairly well in 48k.
Like someone else suggested do whatever it take to increase the TPA as
most CP/m applications assume a minimum of either 48k or 56k to run well.
Allison
Russell Marks
> RM> box with a 4.5MHz Z80, a 46k TPA and a single 256k 'disk' (it actually
> RM> has two of these, but the other one is pretty much full, and PCMCIA
> RM> memory cards aren't exactly cheap...).
>
> Is there no way to increase the available TPA size? addon main ram or a more
I can't add on any more RAM, it's 64K with no (practical) facilities
to add more.
> space efficient cbios if it's a 64kram system already?
Oh boy. A more space efficient cbios. :-)
I wrote the OS myself; it's that one for the NC100 I've been going on
about. I suppose I could pull some stuff out of it, but I doubt I
could get more than 1 or 2K out without making it useless.
There are various unpleasant reasons why the system takes so much RAM.
This machine was never meant to run CP/M (and I mean *never*, not in a
million years), so it's pretty much everything from scratch. On top of
that, I need to use 6K for data before I even think about code:
e800h-e87fh 128-byte serial input buffer
e880h-e97fh 256-byte scratch area used by 'find free block'
e900h-e97fh 128-byte cmdline buffer used by ccp
e980h-e9ffh 128-byte card read/write buffer (needed 'cos of paging)
ea00h-eabfh internal stack used by bdos functions.
eac0h-ecffh font data ('fontdata' set to ea00h, but nowt written there)
ed00h-edffh 256-byte keyboard buffer
ee00h-efffh used to store old contents of b000h-b1ffh by powrhndl.z
(this is to do with using the ROM to handle 'soft' power on/off)
f000h-ffffh used by (bitmapped) screen
So I end up with 12K code + 6K data = 18K system. Not so great. :-(
> RM> I tried Hitech C - it compiles 'main(){printf("Hello world\n");}' but
> RM> that's pretty much the biggest program it can compile in 46k. Besides
> RM> that, 'zas' is not quick. I'm sure an assembler written in ZX81 BASIC
> RM> would run quicker.
>
> A little trick that'll allow a Hi-Tech C to run in small TPA'd systems is to
> invoke each stage manually rather than letting C.COM control the entire show.
> Doing it this way is a bit more involved and requires a fuller read of the
docs
> But it releases the TPA taken up by the resident portion of the $EXEC.COM
> batch processor:-)
Been there, done that (but thanks for suggesting it). $EXEC didn't
work anyway. Hitech C really isn't keen on running in so little
memory.
> RM> The compiler I use at the moment is Small C v1.2, which works well and
> RM> is well suited to running on such cramped machines, but is a bit
> RM> lacking in the more advanced language features, like for() and
> RM> switch(). ;-)
>
> Have you tried Small C v2? I'm not too sure about what the extra features are
> but it's bound to be better than version 1.2:-)
> Just read in it's doc that it require 48k TPA.... So assuming it won't
function
> at all below 48K of TPA then maybe even this will be out of your range!
> It can do:- do...while(), for(), switch() and goto constructs and the doc
> states that these could be removed "if you have to shoehorn your compiler into
> a small memory space." But you'd first need to recompile the compiler to
remove
> remove the sacrificed features which would need a 56k TPA to acompilsh that!
Which v2 is this? I've seen both 2.03 (dated 1988) and 2.1 (dated
1985) on oak.oakland.edu. I think there's been some time travel going
on somewhere there. :-)
No real documentation with either of them either (sigh).
The v2.03 seems to only output the assembly source to the console
(seriously! I must be missing something, but it's a bizarre and quite
useless default).
The v2.1 needs M80/L80, which I haven't got. I tried SCMAC and SCLNK,
which are apparently M80/L80 replacements written in Small C, but it
complained about a *large* number of unresolved external references,
even though I linked it with clib.rel. I was only trying a 'hello
world' program, so this is a bit of a downer... any ideas?
> RM> What I would like is a better C compiler which will run on this
> RM> limited system. Any ideas?
>
> Apart from those ones above, I suspect that to develop programs comfortably
> you'll need a slightly better equiped machine:-(
Well my Linux box runs gcc, but it's just not the same... :^) Hitech C
runs well too under the 'cpm' emulator, so if I want to try anything
reasonably serious under CP/M I'd probably use that.
Truth be told, I just mess with CP/M as a form of recreational
retrocomputing - I've only been running CP/M since about May
last year. It started off with me wanting to do something a bit less
'gamesy' with my ZX Spectrum +3. But it's fairly cool to have a #120
A4-size portable with a C compiler on it, too. Do *that* with a DOS
machine. :-)
> Your other alternative is to program in assembler, that doesn't require a big
> system and generally speaking hand-written machine code utils/programs use
> less TPA than their compiled C counterparts which is important on such a
> TPA challenged machine that you describe!
True, and I do occasionally write assembly programs on it with no
problems. I could just do with not having to write everything so
low-level. I did quite enough Z80 writing the OS for the damn thing,
y'know, I'm a bit sick of seeing 'ld a,(hl)' and 'ldir'. :-)
I saw an interesting thing on oakland as it happens, a Small C 1.2
interpreter. It works quite well on my 'real' CP/M system, though it's
a little idiosyncratic and obviously slow. But on my NC100 it crashes
rather badly. (sigh)
How about if I put a different spin on this question, then; are there
any good, free interpreters for CP/M? Any language; I'll try anything
once. :-)
Roger Ivie
> How about if I put a different spin on this question, then; are there
> any good, free interpreters for CP/M? Any language; I'll try anything
> once. :-)
There's always Forth. F83 should be on Oakland.
In going through the CP/M CD-ROM, there are about half a dozen BASIC
interpreters (and even a couple of compiler) of various (usually tiny)
flavors.
There are also a couple of PILOT interpreters on the CD-ROM, but the only
substantial work I've done with PILOT was with my own interpreter in which
I could add the features I needed to make the language useful (not for
CP/M, by the way; for VAX/VMS written in FORTRAN) for my purposes.