sdcc can be used to cross-compile for CP/M from a modern PC, if you provide a crt0.rel and libc. I rolled my own and was able to port a few useful programs and utilities with it.

https://t3x.org/t3x/0/index.html

Pascal like language, compiles at Unix and to DOS and CP/M, it can be run under CP/M too. It can compile both binaries and bytecode.

I ran a faithful Ladder port natively under a GNU Unix 386, it's really good:

https://t3x.org/t3x/0/programs.html

My greatest claim to fame was embedding a Z80 emulator in Unreal Engine, extending it with TCP/IP and VT100 emulation, and being able to connect to BBS's on the internet, and run Rogue, Zork and Wordstar along with most other Z80 CP/M software:

https://i.imgur.com/aSc9VGL.png

https://i.imgur.com/dd0Nzo2.png

https://i.imgur.com/Usjd4Vk.png

https://i.imgur.com/Y5aIjCi.png

https://i.imgur.com/rIY1he8.png

(yes I know color CP437/ANSI graphics was not a thing on 8080/Z80 CP/M. But it was not difficult to make it work and it looks pretty in Unreal).

(Removing the "-v" flag causes it to generate some submit files, with $$$ suffix, but I don't yet support those in my CCP.)

I'll try it on real hardware next week and if it works there I guess that'll be another fun bug to hunt down!

You are going deep!

(And it has to be said one of the reasons I'm interested is because I have a Z80-based single-board computer which runs CP/M natively which helps for testing things.)

Ha ha, yes.

The first edition of The C Programming Language book by Kernighan & Ritchie (the book popularly called just K&R) used those definitions.

The second edition (the ANSI C one) used the latter kind of definition, the ANSI kind, with both function arguments and return values having (mandatory?) types.

I remember I used to religiously use the latter kind from as soon as the C compilers I used, supported them.

I never said a word about CP/M, sorry.

Referring to my original comment that you replied to, I was talking about Turbo Pascal on DOS, which (DOS, not Turbo Pascal) did have EXE files, from early versions that I had used. But the TP version I mentioned could only create .COM files.

In fact, I remember the DEBUG utility was DEBUG.EXE, again from early DOS versions, although it was possibly DEBUG.COM earlier.

you posted that comment in reply to stevekemp talking about the c compilers he was trying on his cp/m emulator; maybe you clicked the wrong reply link

plausibly early versions of tp could only create .com files because they originally came from cp/m before being ported to ms-dog

> it was possibly DEBUG.COM earlier

yes, though the cp/m version was ddt.com, with a rather rebarbative ui reminiscent not of ddt but of teco

No, I clicked the right reply link that I meant to.

But I see the issue now.

Although his context was small sized compilers on CP/M, my (implied) context was not.

Mine was just small sized compilers, period.

My comment about TP 3 was in that context, and was not referring to CP/M. IOW, I was just saying, TP 3 was another small compiler (and I omitted saying that it was on DOS). I did not even know that TP had existed on CP/M, although I had used that OS briefly, before DOS, and had actually used a Pascal compiler on it, in a programming course I was attending. I remember the machine had those big 8-inch floppy disks. (1) But that was not the TP compiler, it was some other one, I don't remember which.

So I can understand why you thought I was talking about CP/M, and hence said that it had no EXE files.

(1) Or it might have been an MP/M machine, because I vaguely remember that we had to log in to it.

https://en.m.wikipedia.org/wiki/MP/M

yeah, tp3 is great. there were a lot of pretty decent compilers for ms-dog; being able to address hundreds of kilobytes of ram (even if awkwardly) and having separate 64k address spaces for code and data really reduces the difficulty of getting a decent compiler running. the compiler scene for cp/m is fairly dismal by comparison

also, the 8080 and even the z80 were a lot less hospitable to c compiler output than the 8088. on many small processors, though not the z80, sdcc by default compiles everything that isn't specifically marke as __reentrant as non-reentrant, so your parameters and local variables are statically allocated; this isn't compliant with the c standard but is surely a better default tradeoff for the 8080 (which sdcc doesn't support) and probably for the z80 as well. see https://sdcc.sourceforge.net/doc/sdccman.pdf#page=49 for details

NP :)

Sure was, in many ways. That's why it had so many hardcore fans, and why people still talk about it.

Speaking to your second paragraph, IIRC, TP 3 even had overlays, although I never used that feature, maybe because of being in the early stages of my career.

fwiw i suspect implementing only ansi c function headers and declarations would result in a slightly smaller c compiler than implementing only the k&r style ones

http://www.cpm.z80.de/develop.htm

Worked first time to create a simple "Hello World" program, but many of the included examples fail to compile for me, with random errors:

     RM.C: 20: String too long (or missing quote)

     CP.C: 56: Curly-braces mismatched somewhere in this definition

I removed the includes from a few files, changed FILEs to ints, and added "#define EOF -1", etc, which let some more simple code compile & link. But it felt like those changes shouldn't have been necessary.

I guess the good news is the compiler ran without me having to add any new CP/M syscalls/bdos functions to my emulator - unlike hisoft which required that I implement "T_GET" (Get date and time) and a couple of other functions I'd been missing such as F_SIZE (For getting a file size).