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

Sun Nov 15 19:13:09 EST 2020

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