Getting back into C programming for CP/M

Original Article ↗ Hacker News Discussion ↗

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.