Hacker News Reader

Comment by pjmlp | Hacker News Reader

A very good example how C wasn't as portable and as high performance back in the 1980's, as many nowadays think it was.

Not on 8 bit machines, no. Look at what Perl did with C in that timeframe though, and it's true for a different subset of machines.

Within Perl 1.0, part of the Configure script, you can see the list of machines it could build on here: https://github.com/kaworu/perl1/blob/ba165bbde4eef698ff9cc69...

  attrlist="mc68000 sun gcos unix ibm gimpel interdata tss os mert pyr"
  attrlist="$attrlist vax pdp11 i8086 z8000 u3b2 u3b5 u3b20 u3b200"
  attrlist="$attrlist ns32000 ns16000 iAPX286 mc300 mc500 mc700 sparc"

Not even on 16 bit home machines, which is why any serious game, or winning demoscene entries, were written in Assembly, until we reached the days of 486 and DOS extenders.

As a read through the Amiga and PC literature of the time will show.

The problem here is much more the unix wars and a lack of confidence in BSD under legal fire rather than a lack of ability. The principal concern of unix vendors of the early PC era was to maintain their market share in mini and mainframe product sectors rather than growth into the consumer market. This spurred a rewrite of BSD fragments tied to the legacy unix codebase which fully portablized C and the GCC downstream projects which ended up benefiting the weird hobby OS linux disproportionately, and had it not had to be written from scratch we may have ended up with a wonderful 286-BSD rather than a 486-BSD, which at the time was still not fully clean room foss and unburdened. This was a time when large customers of OS products were trying to squeeze all the performance juice out of the existing systems instead of looking at new paradigms. We have things like the full SAST and warn-free release of sunOS around this time, where Sun was focused on getting a rock stable platform to then optimize around rather than efforts to produce products for the emerging Micro market. We can see that the concept of a portable unix system and c library as early as Xenix on the Apple Lisa in 1984. That's only 3 short years after the IBM collaboration for PC-DOS, showing even a rookie uncoordinated and low technical skill team such as microsoft (Paraphrasing Dave Cutler, chief NT kernel lead - Zachary, G. Pascal (2014). Showstopper!: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft. Open Road Media. ISBN 978-1-4804-9484-8).

Xenix was my introduction to UNIX, I wouldn't claim it would win any performance price, specially when considering graphics programming.

Also my first C book was "A book on C", which had a type in listing for RatC dialect, like many others in those early 1980's, which were nothing more than a plain macro assembler without opcodes, for all practical purposes.

Compiler optimizations in those 8 and 16 bit compilers were what someone nowadays would do in a introduction to compilers, as the bare minimum, like constant propagation and peephole optimizations.

A fair amount of non-game Amiga scene, including the OS, was either BCPL or C.

Sure, when performance didn't matter.

Just like on MS-DOS side, I did plenty of stuff on Turbo BASIC, Turbo Pascal, Turbo C (quickly replaced by Turbo C++), and Clipper, until Windows 3.x and OS/2 came to be.

Small utilities, or business applications, without big resources demands.

Or, where portability did matter. That was still true much later...web servers were often mostly C, then inline ASM for the SSL parts.

By then we were already in Windows 95 and Windows NT territory, with OS/2 still waving on the side, and game developers being shown the door to WinG, DirectX's percusor.

>BCPL

Was used by some parts of AmigaDOS (dos.library) and it is unfortunate.

AFAIK nothing third party uses BCPL.

Dungeon Master (1987) on the Atari ST was mostly written in C.

As I experienced that era, C wasn't really a practical language choice on 8-bit systems. Ok yes you could get a C compiler but it would typically need overlays hence be very slow. Assembler was pretty much where it was at on that generation of systems, or special-purpose languages such as BASIC and PL/M.

C worked ok on a pdp-11/45, but that had 256K of memory and 10s of MB of fixed disk. That level of hardware didn't appear for micro systems until the 68k generation, or I suppose IBM PC, but I don't remember the PC being too important in C coding circles until the 386, much later.

Yeah, that was indeed the case, while I did some C and C++ even on MS-DOS, it was Assembly, Turbo BASIC, Turbo Pascal and Clipper where I spent most of my time.

Even during my early days coding for Windows 3.x, I was doing Turbo Pascal for Windows, before eventually changing into Turbo C++ for Windows, as writing binding units for Win16 APIs, beyond what Borland provided, was getting tiresome, and both had OWL anyway.

I did a lot of C programming on an IBM XT - 8088, 10mb hard disk, WordStar and DeSmet C. All worked very well.

8088 was a 16 bit machine though. This is about machines with 64 kbytes of ram maximum, two floppy drives and no hard drive.

please see the comment i was replying to:

>but I don't remember the PC being too important in C coding circles until the 386, much later.

As other commenters have said, C didn't actually generate fast programs for 8-bit processors, or even 16-bit processors for a long time. C is a poor fit for most of them, so assembly language was the only way to go.

A contemporary source is the opinionated "DTACK-Grounded" newsletter from 1981-1985. http://www.easy68k.com/paulrsm/dg/ Hal Hardenbergh raved about the fast 68000 chip and it's wonderfully easy assembly, but lamented that everyone switched to "portable" Pascal and C to write 16-bit programs so they seemed even slower than 8-bit ones. His favorite example was a direct comparison: Lotus 1-2-3, written in 8088 assembly, vs Context MBA with the same features but written in Pascal for portability. 1-2-3 was MUCH faster than Context on the PC, and no one remembers Context today. Or the $16,000 Unix-based AT&T workstation whose floating-point benchmarks are beaten by a $69 VIC-20. (Obviously due to the C-written runtime, which even followed the C standard of promoting all single precision calculations to double so single was no faster!)

His opinion of C was "slightly-disguised PDP/11 assembly". Not too bad for the 68000, but a terrible fit for the 8088 or Z80.

Reply on news.ycombinator.com