It was thus said that the Great ben via cctalk once stated:
> On 2025-02-03 3:32 p.m., Sean Conner via cctalk wrote:
> >
> > So it could be that C99 will work for you, it might not. A C89-only
> >compiler will work---it'll still accept K&R style code, and it will be old
> >enough to avoid the "exploit undefined behavior for better benchmarks"
> >compilers we have today. Or find an old K&R C compiler. They still exist,
> >but generate very bad code.
> >
> > -spc
>
> So where does on find a older version, on a current Linux build.
> we don't support it!!! We only port the latest intel CPU.
>
> You have 32 bit compilers, or bigger. I might want a 16 bit compiler
> under Linux.
Do you mean you want a compiler to generate 16-bit code? Or be compiled
as a 16-bit program to run under Linux? If the later, it's not supported,
or at least, not supported by default [1].
> I was hoping to use Embeddable Linux Kernel Subset (ELKS) BCC compiler
> and the 6809 code generator, but NO they had to rewrite it just for the
> 386.
It took me only a few minutes to find it. There's the GIT repository at
https://github.com/lkundrak/dev86
Yes, it requires git to initially download it, but it's available. And it
*still* has 6809 code generation. The code seems to be originally written
for Unix anyway, or at least it appears so from the initial importation into
git [2]:
/* bcc.c - driver for Bruce's C compiler (bcc) and for CvW's C compiler
*/
/* Copyright (C) 1992 Bruce Evans */
#define _POSIX_SOURCE 1
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/wait.h>
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <string.h>
The latest version was ported to MS-DOS at some point. I was able to
compile the latest version (on a 32-bit Linux system---I no longer have a
MS-DOS C compiler so I couldn't test on that), but the code is C89, so in
theory, you could use any MS-DOS C compiler post 1989 to compile the code if
you so wish.
When I did the compile, there compiler did throw up some warning even
though none were specified because the code is that old, but I did get an
executable:
[spc]matrix:~/repo/dev86/bcc>./bcc
Usage: ./bcc [-ansi] [-options] [-o output] file [files].
> Open source is popular because it was free.
>
> No compiler generates bad code,just some hardware was never meant to
> have stack based addressing, like the 6502 or the 8088/8086.
> Look at the mess that small C has for 8088/8086 code gen.
> Self hosting never seems to be important for C compiler on a small machine.
The 8086/8088 was never meant to have stack based addressing? Um, the
8086/8088 has an entire register dedicated to that (BP by the way). The
limitation with BP is that it's bound to the SS segment by default, and in
some memory models that becomes an issue, but to say it doesn't have stack
based addressing? Methinks you are misrembering here.
And self-hosting a C compiler on a small system isn't easy with 64K of RAM
total. The PDP-11 had at least 64K code space and 64K data space to work
with.
-spc
[1] I have run a 16-bit MS-DOS exectuable under Linux, but it was on a
32b x86-based Linux system with a custom program I wrote to run it.
I even had to emulate several MS-DOS system calls to get it to work
(since I needed input from a Unix program to be piped in, I couldn't
use DOSBox for this).
[2] Dated July 27, 2002, which is before git existed, but this
repository was converted to git at some point.
