admittedly my initial reply wasn't that helpful in clarifying ;)
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
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.
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