3 Feb
2025
3 Feb
'25
6:50 p.m.
On Mon, Feb 3, 2025, 5:37 PM Sean Conner via cctalk <cctalk(a)classiccmp.org>
wrote:
It was thus said that the Great ben via cctalk once
stated:
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 have Vexix86 emulator that does much the same thing.
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.
I was hoping to use Embeddable Linux Kernel Subset
(ELKS) BCC compiler
Bcc was written by Bruce Evans to have a compiler for 386BSD for the boot
loader (among other reasons). It dates back to the late 80s or so. It's one
of the reasons we in FreeBSD held onto K&R constructs in certain areas of
the tree for so long. Well after gcc / binutils could generate the small
bits of 16bit code the loader eventually required..
Warner
/* bcc.c - driver for Bruce's C compiler (bcc) and for CvW's C
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]:
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.