Getting back into C programming for CP/M

Original Article ↗ Hacker News Discussion ↗

Retrocomputing enthusiasts reflect on writing C for CP/M-era 8‑bit machines, contrasting it with contemporaries like PL/M, Pascal, BASIC, and Forth, and noting how limited RAM, slow floppy disks, and weak compilers made assembly or alternative languages more practical at the time. Commenters revisit tools such as Aztec C, BDS C, Turbo Pascal, and F83 Forth, touching on licensing quirks, cross‑compilation from modern systems, and the realities of performance optimization without modern toolchains or hardware features. The conversation also prompts comparisons with today’s development culture, where abundant resources, heavy abstractions, and process overhead are seen as both enablers and sources of inefficiency relative to the lean constraints of early microcomputers.

Language Choices on CP/M and 8‑bit Systems

  • Debate over why use C instead of PL/M, Pascal, BASIC, or Fortran on CP/M.
  • Several note C was not a great fit for “odd” 8‑bit ISAs; Pascal, PL/M, BASIC, and Forth often matched hardware better.
  • Others argue C’s portability across diverse word sizes (PDP‑10, Z80, 6809, later 32‑bit) made it very attractive despite inefficiencies.
  • PL/M is described as powerful but niche, proprietary, and non‑hobbyist (“golf course pricing”), making C a more transferable skill.

C Performance and Portability in the 1980s

  • Multiple commenters stress that early C compilers on 8‑ and early 16‑bit systems produced slow code; serious games/demos were in assembly.
  • Examples: Lotus 1‑2‑3 (8088 assembly) vs a slow Pascal competitor; reports that some 68000 Unix workstations ran numeric code slower than cheap 8‑bit machines due to C runtimes.
  • C is characterized as “PDP‑11 shaped,” fitting 68000 reasonably but clashing with Z80/8088.
  • Some highlight that contemporary compilers did little optimization; idioms that modern compilers optimize (e.g., repeated strlen) often were not optimized then.

Development Workflows and Tooling on CP/M

  • Many preferred Z80 assembler or Turbo Pascal because C compilers were large, slow, and overlay-heavy on floppy systems.
  • Cross‑compilation on bigger machines is described as historically common and, today, a practical way to “do retro” work.
  • Disk I/O on floppies (kilobytes/s, sub‑100KB capacities) imposed significant friction on edit–compile–link cycles.
  • Examples of specific tools: Aztec C, BDS C, Whitesmiths C, Mark Williams C, Coherent’s C, Turbo Pascal, and various BASICs.

CP/M OS and File System Details

  • Clarification that CP/M used FCBs/extents, not FAT, and typically had 64 KB RAM limits (several note the article’s “64Mb” is a typo).
  • Discussion about device names (PUN, AUX) and logical vs physical I/O redirection.
  • CP/M file system could store lowercase names, but the command processor uppercased input, making them hard to manage.
  • Stack size was fixed at compile time and shared with interrupts, making stack overflows a real concern.

Retro Tools, Forth, and Modern Alternatives

  • Mentions of emulators and distributions (e.g., CP/M emulators with filesystem integration, RunCPM) that bundle old compilers like Aztec.
  • F83 Forth is highlighted as an extremely featureful CP/M/MS‑DOS system (editor, debugger, VM, multitasking, meta‑compiler, “go to definition”).
  • Some point out that if one wants “small computers” today, modern microcontrollers (AVR, ARM, etc.) offer far better price/performance than vintage CP/M hardware.

Modern Practices vs 1980s Style

  • Several contrast “straightforward” 1980s programming with today’s layers of abstraction, agile rituals, and large teams.
  • Criticism of “Clean Code,” SOLID, and heavy OO design for causing cache‑unfriendly layouts and complexity without strong empirical backing.
  • Observations that large organizations optimize for risk reduction and uniformity, which can marginalize highly competent individual contributors.
  • Persistent difficulty and high cost of replacing legacy COBOL/mainframe systems is cited as evidence that “modern best practices” have not solved core software problems.