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 tooltranscoded 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. Andeffort—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 arewere 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.