Suppose it's late 1980 to early 1981, you've got some software you want to write for the IBM PC which will be released later in 1981, want to get started ASAP, and believe C is the right language for the job. However, a C compiler on the PC does not become available until 1982.
What's the cheapest way to get your hands on some kind of usable C programming environment immediately?
One option might have been using “Small C,” which was published in 1980 in Dr. Dobb's Journal magazine.
Initially it generated code for the 8080, but was adapted for a few other CPU's. It was adapted to generate code for DOS/8088 but I do not know the date.
Small C was written in itself so you would need a CP/M-80 system to do the port.
But if I recall correctly, at the time, most things were done in Basic or assembler. There may have been a Forth implementation but that was always a niche language.
So you want to write a C program for the IBM PC before the first C compiler for the PC is released. How do you go about it?
There are three options I can see:
No four options. Amongst our many options are fear, surprise and a fanatical devotion to the Pope.
I'd be pretty confident that all of the software houses that were in that position would have gone with option 4. The reason for this is that the premise of your question is faulty: professional software developers don't have dogmatic views about which language to use, they look at the target platform and then pick (what they think is) the best language that is available. In my 30 years as a professional software developer, I have never had the luxury of a free choice of what language to use on any project. On a professional level, my favourite language is whichever one gets the job done on the target platform. For my personal projects, it's Swift all the way.
Another point to remember is that, in 1981, C did not have the ubiquity in the world of personal computers that it later gained. Everybody wrote in BASIC or assembler. The deficiencies of BASIC were recognised but the answer was not obviously "replace it with C". Several languages were mooted as a replacement including IIRC Pascal, COMAL and even Fortran but the first time I even heard of C was when I went to University in 1984 and was exposed for the first time to Unix. There was a significant group of people who thought "why would you use anything but assembler?"
The software house developing an application for the IBM PC in 1981 would have had no hesitation in breaking out the 8086 assembler and just getting on with it.
The BDS C compiler was released in 1979, ran on CP/M, and was capable of generating code for the Intel 8080 microprocessor. (It also ran on and generated code for the Zilog Z80, but that's not relevant here). This was a very popular, well-known CP/M compiler, and as Wikipedia says:
It ran much faster and was more convenient to use than other Z80-hosted compilers of the time. It was possible to run BDS C on single-floppy machines with as little as 30K of RAM - something of a minor miracle by comparison to most other commercial compilers which required many passes and the writing of intermediate files to disk.
[ … ]
BDS C was very memory efficient, with fast compilation speeds.
Since the 8088/8086 processors used in the IBM PC are largely compatible with the 8080, I believe that using BDS C on a CP/M machine would have been a viable path.
The two processors aren't completely binary-compatible—as in, an 8088 won't run 8080 code as would have been generated by the BDS C compiler. But, the two processors are compatible on the assembly language level, which means that the binary code could have been easily transcoded using an automatic tool, or even by a human assembly-language programmer looking at the 8080 source disassembly. All you needed to do was to translate the opcodes over.
Alternatively, you could have used Ron Cain's Small-C compiler, the source code for which was published in the May 1980 issue of Dr. Dobb's Journal. This compiler also targeted the 8080, but since its source was available (at some point, it was released into the public domain, but I can't find a precise date), you could have modified it to target the 8088 with minimal effort—and I really do mean minimal. Small-C generated assembly code as its final output, which then had to be translated into machine code by an assembler, so all you really needed to do was plug in an x86 assembler.*
Either way, this would allow you to write and debug all of your C code on the CP/M machine, meaning that you wouldn't need access to any IBM pre-release hardware (which wasn't exactly forthcoming; the PC was basically a skunkworks project, kept secret from most of the rest of the industry). CP/M machines were very affordable at this time, and there were plenty of them to choose from. If you wrote reasonably portable C, the porting would have been absolutely trivial. And then, once a C compiler was eventually released for the platform (and you knew it was going to be), you could drop the post-compilation opcode-translation step, switching your build process over to, for example, the newly-released Lattice C compiler in 1982, which ran natively on the IBM PC under PC-DOS.
More realistically, though, the only reason you'd even need to do this would be to make sure that you had software ready to run on the IBM PC on the day of launch. But most vendors weren't doing that—no one expected the IBM PC to be the runaway success that it was.* So, what is more likely is that you were a shop developing software for CP/M machines and already using the BDS C compiler. You'd continue doing so until it was obvious that the IBM PC was going to catch on, and then it would be a simple matter of porting your existing C code base to Lattice C or any other newly-released C compiler targeting the IBM PC.
__
* The few vendors who were writing serious software for the IBM PC in 1980–81 were doing it in assembly. Microsoft had an assembler up and running (they had to—they were using it to steal develop DOS), and Intel certainly had one.
There was also some commercial software development done in Pascal. IBM released a Pascal compiler (developed by Microsoft) for the PC in 1981, alongside its August launch, and I imagine that prototypes were available to prospective vendors (though I don't know this for certain). There were also other vendors who had Pascal development environments, and the USCD Pascal system was one of the available operating systems for the IBM PC, in addition to CP/M and Microsoft's DOS.
CALL 5 system call mechanism of CP/M, even though it was deprecated. From what I recall, that was specifically done for compatibility with machine-translated CP/M software, though this turned out to not be used much in practice.
A possible answer is cross-development. If C is the right language for the job, then a prototype can be written in C on any platform that already has it (say, PDP-11, also a little endian 16-bit architecture, with a well-established C environment).
A command-line program would be portable enough, maybe with a few include file modifications and taking care of the infamous "text mode" vs "binary mode".
If some kind of text mode direct screen access is needed for interactivity, in a prototype implementation it could be modeled by the CURSES library, to be rewritten later with assigning directly to the video memory.
You could do the following:
Partial credit goes to @mcleod_ideafix for his answer to a similar question.
C was available on the BBC Micro in the very early '80s.
You did need the third party 68000 Second Processor which was made by Torch Computers. The OS was Torch Unix. This configuration wasn't supported by Acorn but it worked pretty well. This is how I first learnt C.
From memory there was also an add-on card for the Apple ][ which would give access to a C environment.
You can either use a CP/M machine with an 8080 C compiler and port it when the IBM PC launches (August 1981) and BDS or Whitesmiths produce a compiler.
Or, and this was a common way of working then, you beg/borrow/steal access to a minicomputer with C (maybe Unix, maybe something proprietary) and develop on that.
Can't comment yet, so I'll add another answer.
Small C has been mentioned.
Translators that would mechanically translate 8080 assembly to 8086 assembly were available, if you preferred not to do the job by hand.
I know people who did essentially this in 1983 or '84 -- hand translated the assembly language source for the compiler and the output object.
Small C could theoretically be used to bootstrap a full C compiler, and that was also done. But it wasn't done as much because it did take real work, in terms of working out all the grammar rules and testing them.
On a little higher-tech level, C compilers (and other language compilers and interpreters) in those days were usually constructed using yacc and lex. So, if you had a budget and someone who understand yacc and lex, you might have constructed a cross-compiler on a cheap (so-to-speak) Unix minicomputer which would then be shared by your dev-department to write the software on.
(afterthought)
Using lex and yacc might make it possible, after cross-compiling the libraries and some other tools and lex and yacc themselves, to use the source code for the cross-compiler to bootstrap a native compiler.
That was the holy grail, of course, but it didn't always work that well.
The reason you might not want to use the source code for the Unix compiler, if you had that, is that you wouldn't want the full set of bells and whistles on a machine as limited as the IBM PC.
On the converse, some managers preferred not to have native compilers because that would be one more asset of unknown value to keep track of.
(end afterthought)
And, finally, if you had early access to the hardware or a mockup of some sort, you might have had early access to the compilers that had not yet been officially released.
An option that the Forth community often mentioned back then, but never actually seemed to be used, might have been to write the compiler in Forth.
Speaking of Forth, it is my understanding that the early versions of WordPerfect were written in a Forth that the predecessor to WordPerfect Inc. wrote themselves. If you understood Forth, Forth would have been just as much an option for development as C at the time.
To be realistic... in early 1981, you wouldn't be writing software for the announced but not released IBM PC, because it was expected to be a proprietary box with a proprietary OS, excluding the (relative) wealth of CP/M software already available. IBM owned the big computing industry in 1981, and it's PC was expected to be like its big iron: closed, proprietary, and not conducive to the rough and tumble world of the personal computer of the late 70's. It wasn't expected to sell very well.
You'd be targeting either Apple II or CP/M, to get the broadest possible market for 1981.
And you wouldn't be writing in C in 1981. You'd be writing in assembler, BASIC, maybe FORTRAN, whatever you could get a compiler for. C for personal computers didn't become popular until the mid to late 1980's.
Actually, writing one's own C compiler was not outside the realm of possibility in those days. Since the language is easy to parse, and is fairly close to assembler, writing a native code compiler wouldn't be that difficult, especially if the alternative was writing in assembler.
You could write a x86 backend for pcc (and a cross-assembler), or politely ask Whitesmiths Ltd. to deliver their x86 compiler earlier (InfoWorld reported on 29 September 1980 that it was at least 6 months away from release).
Or just write in assembler (Intel ASM86 running on a Intel MDS) -- that's how IBM has written PC BIOS, apparently -- http://www.os2museum.com/wp/the-ibm-pc-bios-and-intel-isis-ii/
