[Coco] OS-9 / NitOS-9 C programmers, lend me your makefiles

Sun Nov 15 20:02:53 EST 2020

Yes, the binaries are in Cmds/ and the source is in
Source/Compiler/{DCC,CPP,CC09,COpt}.
It's possible that the binaries may actually be somewhat more up to
date than the source code, since there are changes I have not pushed
yet, but they do include all the stuff I have been working on.

On Sun, Nov 15, 2020 at 7:34 PM Bill Pierce via Coco
<coco at maltedmedia.com> wrote:
>
> Jeff, are all those in your GitHub repo?
>
> Bill P.
>
>
> -----Original Message-----
> From: Jeff Teunissen <deek at d2dc.net>
> To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> Sent: Sun, Nov 15, 2020 4:46 pm
> Subject: Re: [Coco] OS-9 / NitOS-9 C programmers, lend me your makefiles
>
> My build chain is, currently:
>
> dcc dcpp dcc68 dco68 rma rlink
>
> dcc is the compiler executive, like 'cc' or 'rcr'. It's based on Carl
> Kreider's cc version 2.2, with some updates from later patches people
> have made. It really only has that name because it's useful to have
> both compiler toolchains able to fully coexist with one another.
>
> dcpp is the preprocessor. As I mentioned in one of my previous posts,
> it's compatible with the original Tandy c.prep, but with many features
> from the ANSI/ISO standards and extensions adopted from the GCC
> preprocessor (like the ability to synthesize errors and warnings). It
> can handle much more complex sources than c_prep can, both because
> it's smaller and because it doesn't use hard-sized arrays for all of
> its data.
>
> dcc68 is the 6809 compiler. I used to call it CC09, but I realized
> that would cause problems later when I started working on the HD6309
> version, so I adopted the naming scheme *68 for Motorola chips, *63
> for Hitachi, which also goes along with David Breeding's 6309 patched
> r63 assembler.
>
> dco68 is the 6809 assembly optimizer. It is _slightly_ better at
> optimizing than c.opt (c.opt has a bug that doesn't allow it to
> optimize patterns that start with a label, dco68 doesn't have that
> bug). I plan to integrate the CnoY optimization into dco68 so that you
> don't need a second optimizer, instead you will just have to call it
> with -2 or something like that.
>
> RMA and rlink you already know.
>
> On Sun, Nov 15, 2020 at 3:27 PM Bill Pierce via Coco
> <coco at maltedmedia.com> wrote:
> >
> > Jeff, what's your current Coco Os9 build chain?
> > I mean from beginning to end just as mine (currently) is:
> >
> > RCR C.Prep C.Comp CNoY C.Opt RMA RLink (with "touch" being used by the makefiles)
> >
> > Bill P.
> >
> >
> > -----Original Message-----
> > From: Jeff Teunissen <deek at d2dc.net>
> > To: CoCoList for Color Computer Enthusiasts <coco at maltedmedia.com>
> > Sent: Sun, Nov 15, 2020 2:04 pm
> > Subject: Re: [Coco] OS-9 / NitOS-9 C programmers, lend me your makefiles
> >
> > The "dcc" compiler is not in EOU yet. It should be in Beta 6, with as many
> > of my updates to the libraries and headers as possible.
> >
> > Right now if you want to check out the preprocessor, you want to look at
> > the GitHub repository at <https://github.com/Deek/CoCoC>. The source and
> > OS-9 binaries may be found there.
> >
> > On Sun, Nov 15, 2020, 9:04 AM William Carlin <whcarlinjr at gmail.com> wrote:
> >
> > > Jeff,
> > >
> > > I searched the EOU B5 and can't seem to find the Source/Compiler/CPP
> > > folder.  Is there another location I can find this at?
> > >
> > > WIlliam Carlin, Jr.
> > >
> > > On Sun, Nov 15, 2020 at 2:50 AM Jeff Teunissen <deek at d2dc.net> wrote:
> > >
> > > > I've actually stopped using c_prep entirely here, and have switched to
> > > > a different C preprocessor.
> > > >
> > > > I think the 'cpp' in CoCoC is a descendent of the original c.prep. It
> > > > may be found in the directory Source/Compiler/CPP. It's pretty
> > > > excellent and mostly ANSI-compatible. I've added a few features, like
> > > > #error, #file, #warning, stringification using #, token pasting using
> > > > ##, and optionally restricting macro expansion to only happen outside
> > > > of string/character literals.
> > > >
> > > > Most importantly for me at least, it seems to be faster and consume
> > > > less memory than c_prep, which is important for future enhancements.
> > > > Rather than using a static array for definitions, cpp uses a linked
> > > > list, so it's not wasting as much memory and can thus handle many more
> > > > definitions.
> > > >
> > > > I do have a copy of the (C and assembly) Kreider library. It's also in
> > > > CoCoC, and can be found in the directory Source/Libs/KLibc; once I've
> > > > got the whole toolchain (C compiler, assembler, linker) building,
> > > > maintainable, etc. I do plan to start really fixing up the bugs in the
> > > > C library. I have noticed the Y2K bug in ctime(), but I discovered
> > > > that it's missing the source code to scanf/fscanf/sscanf so I've been
> > > > disassembling it.
> > > >
> > > > On Sun, Nov 15, 2020 at 1:11 AM William Carlin <whcarlinjr at gmail.com>
> > > > wrote:
> > > > >
> > > > > Jeff,
> > > > >
> > > > > Here is the link to the folder on my Google Drive.  The files are under
> > > > the
> > > > > "Microware C Projects" folder.  I have uploaded the two .lzh archives
> > > and
> > > > > the same files are also on a DriveWire disk, "Make91SRC.os9"  The
> > > source
> > > > > code to MROFF is also there if you did not grab that when I previously
> > > > > shared it with you. That is in the "CLib_Kreider_91_doc.lzh" archive.
> > > > >
> > > > >
> > > >
> > > https://drive.google.com/drive/folders/1IZ89kvYU04sfVYufnyqBuvOFZDs59CLv?usp=sharing
> > > > >
> > > > > To compile you are going to need:
> > > > > cc252 (cc v2.5.2)  This should already be on the EOU beta 5 disk.
> > > > > Otherwise you can find it on the Climax C Compiler release on the Color
> > > > > Computer Archive
> > > > > The Kreider clib.l  This should also be on the EOU 5 beta disk.
> > > > > I also use Kreider's fixed version of cstart.r but that should not
> > > > prevent
> > > > > compilation.  This should also be on the EOU beta 5 disk.
> > > > > You will also need my updated version of c_prep v1.9  I am unofficially
> > > > > bumping the version up to 1.10.
> > > > >
> > > > > I have allowed/fixed source line concatenation of more than one line of
> > > > > code.  If more than one line of consecutive code ends with a backslash
> > > > '\'
> > > > > the lines will be concatenated into a single line of code.  Leading
> > > > spaces
> > > > > are removed so you can make your source look "pretty".
> > > > >
> > > > > I have also fixed the __FILE__, __DATE__, and __TIME__ built in macros
> > > to
> > > > > be enclosed in double quotes when expanded.  Previously these macros
> > > were
> > > > > not enclosed in double quotes when expanded and could not be displayed
> > > > with
> > > > > the %s printf format argument.  This also allows for easy inclusion in
> > > > the
> > > > > format text as the preprocessor correctly concatenates consecutive
> > > double
> > > > > quotes.  If there is a way to make the preprocessor enclose an expanded
> > > > > macro with double quotes around it, I have not been able to find it.
> > > In
> > > > > GNU you can prepend a '#' in front of the macro to stringify it.
> > > > However,
> > > > > C-prep 1.9 does not include this feature.
> > > > >
> > > > > #__FILE__ will expand to "filename.c" (GNU)
> > > > > __FILE__ will expand to filename.c (OS-9, both MWC c.prep and c_prep
> > > > v1.9)
> > > > >
> > > > > BTW, the __DATE__ macro is not Y2K compatible.  This has more to do
> > > with
> > > > > the implementation of ctime() in the Kreider clib.l
> > > > >
> > > > > BTW if you have a copy of the assembly source code for the Kreider
> > > CLib,
> > > > > please drop that in the Incoming folder on my Google Drive.  The Y2K
> > > fix
> > > > > should be as simple as adding 1900 to the D register before moving it
> > > off
> > > > > to be included in the returned date string.
> > > > >
> > > > > William Carlin, Jr.
> > > > >
> > > > >
> > > > > On Sat, Nov 14, 2020 at 11:37 PM Jeff Teunissen <deek at d2dc.net> wrote:
> > > > >
> > > > > > I noticed there's a bug in the OS-9 port in that when Neil changed
> > > the
> > > > > > code to work with spaces, he actually changed it to work _only_ with
> > > > > > spaces and not tabs. Unfortunately, this means that the OS9 version
> > > > > > _cannot_ use Makefiles that are compatible with every other Make in
> > > > > > the world, and vice versa. This is an oversight that needs
> > > correcting;
> > > > > > if you get to it before I do, awesome, otherwise I'll do it. :)
> > > > > >
> > > > > > On Sat, Nov 14, 2020 at 11:17 PM William Carlin <
> > > whcarlinjr at gmail.com>
> > > > > > wrote:
> > > > > > >
> > > > > > > Jeff,
> > > > > > >
> > > > > > > I saw all the references to EON in the source but I couldn't find
> > > any
> > > > > > > reference to it on Google.  There is a modern OS called EON but I
> > > do
> > > > not
> > > > > > > think it has any relation to the EON referenced in PD Make.
> > > > > > >
> > > > > > > I'll LHArc my source code, copy it up to my Google Drive, and then
> > > > share
> > > > > > > the link here.  The reason I wanted to know how to add empty
> > > > directories
> > > > > > to
> > > > > > > the LZH archives was to archive this source code when the time to
> > > > share
> > > > > > it
> > > > > > > out was appropriate.
> > > > > > >
> > > > > > > William Carlin, Jr.
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Nov 14, 2020 at 7:25 AM Jeff Teunissen <deek at d2dc.net>
> > > > wrote:
> > > > > > >
> > > > > > > > More information discovered about our favorite Make:
> > > > > > > >
> > > > > > > > It was originally written for an OS I have never heard of, called
> > > > > > > > "eon", by someone named Neil Russell. I surmise Neil had been
> > > > either
> > > > > > > > working or studying at an Australian university when he wrote it,
> > > > from
> > > > > > > > his ACSNet email address.
> > > > > > > >
> > > > > > > > A later version Neil posted in December 1986, though, suggested
> > > he
> > > > was
> > > > > > > > by then working at Fairlight (makers of the Fairlight CMI digital
> > > > > > > > music workstation) and had ported it to OS-9 (whether 6809 or
> > > OSK,
> > > > I
> > > > > > > > do not know). This is still not the same program we know on the
> > > > CoCo,
> > > > > > > > because it doesn't read a /DD/Sys/Make.default data file for its
> > > > > > > > defaults -- they're compiled in.
> > > > > > > >
> > > > > > > > Still, some interesting history there that I will have to
> > > integrate
> > > > > > into
> > > > > > > > CoCoC.
> > > > > > > >
> > > > > > > > --
> > > > > > > > Coco mailing list
> > > > > > > > Coco at maltedmedia.com
> > > > > > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Coco mailing list
> > > > > > > Coco at maltedmedia.com
> > > > > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > > > >
> > > > > > --
> > > > > > Coco mailing list
> > > > > > Coco at maltedmedia.com
> > > > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > > > >
> > > > >
> > > > > --
> > > > > Coco mailing list
> > > > > Coco at maltedmedia.com
> > > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > >
> > > > --
> > > > Coco mailing list
> > > > Coco at maltedmedia.com
> > > > https://pairlist5.pair.net/mailman/listinfo/coco
> > > >
> > >
> > > --
> > > Coco mailing list
> > > Coco at maltedmedia.com
> > > https://pairlist5.pair.net/mailman/listinfo/coco
> > >
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
> >
> > --
> > Coco mailing list
> > Coco at maltedmedia.com
> > https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco