From: Alfonso <a.martone@retepnet.it>
To: linux-8086@vger.kernel.org
Subject: using Turbo C compiler to generate ELKS executables
Date: Thu, 6 Feb 2003 19:12:03 +0100 [thread overview]
Message-ID: <200302061328.27317.a.martone@retepnet.it> (raw)
I did it!!
I found on Borland Intl. site (www.borland.com) that they placed
their historic Turbo C 2.01 in freeware, because "Antique Software".
Well, one can use it also to develop programs for the ELKS platform.
I explain here just the basics. Go to my home site ELKS-dedicated
pages for technical stuff and download the full TCC4ELKS.ZIP source:
http://www.alfonsomartone.itb.it
(1) Borland...?
In May 1989 Borland released the version 2.01 of Turbo C, surely
the most used C compiler in the DOS world in the "pioneer's era".
It could be used for creating DOS executables from "tiny" COM files
to "huge" EXE files. A rock-solid compiler with a nice text-based
IDE interface and a *good* debugging tool (you could step-into
functions without altering screen, look for variable values, etc).
After years and years, that software (now released as freeware)
is still good. But, as I demonstrate here, you can use it also to
develop for 8086 (or 80186) environments.
(2) ELKS...?
The only known C compiler suitable for ELKS was the bcc (Bruce
Evans C Compiler) and the Dev86 package. The bcc has (only) a
peep-hole optimizer, which output isn't as fast as the Turbo C
one.
I think that it happens to be easier working on an already
optimized 8088-family compiler than creating a new one, which
would be almost pointless because today 8088-class and 80286-class
machines are "things for museums" (on *these* museum things ELKS
runs!!!).
(3) From DOS EXE format to ELKS.
It's really easy (at least theoretically): ELKS executables have
a fixed header, then the code section, then the data section.
For this release, to make things simple, I consider *only* the
"small" memory model executable (64k code + 64k data/bss/stack).
So, any 8088-class compiler producing a "small" memory model
executable can be used.
Turbo C can generate a DOS executable file (.EXE) and a link map
text information file (.MAP): grabbing information from the EXE
header and MAP file, one can build an ELKS header and append
generated code and data segments. This work is done by the
exe2elks DOS utility program.
(4) Standard C libraries.
Obviously you cannot use DOS-based Turbo C libraries (CS.LIB, etc)
to build ELKS programs, because in *many* points their routines
refer to DOS environment and startup code block (C0*.OBJ): DOS
interrupts (21h, 20h, etc), PSP structure, anarchic heap handling,
interrupt vectors (like division-by-zero), internal variables, etc.
I think that a good part of the standard Turbo C libraries could
be used in almost any environment (e.g.: a "strcpy" function does
not require anything from the underlying operating system), but
one should examine and study the library source (or, harder, the
disassembled code) to select "good" routines one by one...
So I had to develop a minimal library (smallibc.lib) for a number
of ELKS system calls (syscalls) of general use, and a small (very
small) set of general functions (strcpy, minimalistic printf, etc).
(5) It runs!
I compiled some example programs (requiring very little library
functions) to show how it actually runs. The bcc generates for the
"cento.c" program a 5500+ bytes executable file, while the Turbo C
version (with register variables, a decent optimizer, etc) with the
minimalistic library, generates a 1540 bytes file (including about
550 bytes for the only printf/sprintf functions). Start "cento" in
a (true or emulated) 8088-based ELKS environment and enjoy...! :-)
I think that larger programs (the standard library, the ELKS kernel
itself, etc) could be compiled with Turbo C. There are a number of
Turbo C features that should be explored (for example, the
floating-point stuff - emulated or 8087-native; far pointers and
far calls; etc). The ELKS kernel may actually need a decently
optimized compiler, to save some few kilobytes of precious code
space.
The nasty part of all: Turbo C expects only CR/LF terminated lines,
while bcc expects LF only. But the translation from DOS style to
Unix style can be done with a simple filter program. Also, Turbo C
has to be used in a DOS environment (maybe a DEXE file solution
could help).
(6) Get the Turbo C now!
Please do not ask me for a copy of Turbo C: go download it from
Borland site (section Museum) site. Yes, they ask you for your
email address... I gave mine but they didn't ever send me any
advertisement.
I'm not related in any manner with Borland: they just did a good
thing that only a few software companies do -- place in freeware
a great piece of their commercial software ("Antique"? it doesn't
care too much). Go download it from Borland site, and make them
know what a great thing is to release it in freeware! Maybe one
day they will release *also* source code of their old stuff, and
other famous compilers or newer versions of Turbo C and Turbo C++,
letting people using them and porting them to other operating
environments.
(7) Future...
I do not plan to expand smallibc to a decent libc; I know there
are already efforts to port uClibc (www.uclibc.org) to ELKS and
do not want to duplicate work (I hope *already* to not to have
duplicate work from others).
The package TCC4ELKS.ZIP is to be used in a DOS environment,
e.g.: MS/DOS 5.0 under DOSemu 1.0 (other combinations, real or
emulated DOS box, FreeDOS, etc, are untested but expected to
work).
Maybe one could create a modified version of DOSELKS linux-86
package program for use the Turbo C integrated debugger, and
develop and debug in a DOS box...!
The license for using my work (this TCC4ELKS package) is GPL
(GNU General Public License) and won't change in future releases.
alf
next reply other threads:[~2003-02-06 18:12 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-06 18:12 Alfonso [this message]
2003-02-07 2:22 ` using Turbo C compiler to generate ELKS executables jerryc
2003-02-07 14:31 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200302061328.27317.a.martone@retepnet.it \
--to=a.martone@retepnet.it \
--cc=linux-8086@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox