The [**BDS C** compiler](https://en.wikipedia.org/wiki/BDS_C) 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.<sup>*</sup>

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. CP/M machines are 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](https://en.wikipedia.org/wiki/Lattice_C) in 1982.

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.<sup>*</sup> 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.

__  
<sub><sup>*</sup> 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 <strike>steal</strike> develop DOS), and Intel certainly had one.<br><br>
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](https://en.wikipedia.org/wiki/UCSD_Pascal) was one of the available operating systems for the IBM PC, in addition to CP/M and Microsoft's DOS.</sub>