How common was programming in C targeting 8-bit processors in 1983?

Question

How often was C used to program firmware for 8-bit processors in the early 80s?

I'm reverse engineering a firmware binary for a device built around a Hitachi 6303 processor, manufactured in 1983. Even though I'm new to this architecture, it's simple enough that the assembly can be easily read and understood. As I'm slowly documenting the various subroutines I'm wondering how likely it was that the firmware was originally programmed in C, as opposed to hand-written assembler. Ordinarily I would assume that the program was written entirely in assembler, however the book I'm working with The HD6301/HD6303 Series Handbook (1989) contains an entire section related to programming for this architecture in C.

Answer 1

How often was C used to program firmware for 8-bit processors in the early 80s?

It would have been a rather unusual choice in 1983. True, C was slowly creeping in, but only on 'big' machines and 16 bit.

If a high level language was used at all, then it was more likely some PL/1 derivation or maybe a BASIC compiler. Especially the later was rather common on more complex 6800 projects.

[...] Handbook (1989) contains [...] C.

Well, that is 1989, 6 years later than the device (*1), when C had gained a noticeable foothold.

Keep in mind, these were the 80s, when every year delivers more changes to computing, especially at the lower end, than nowadays a whole decade brings.

---

A Short Look at the Transition to C in Time

To put this into perspective (*2), the first Microsoft C compiler, which was not even K&R compliant, came 1983 and wasn't their own development, but a relabeled Lattice-C. It wasn't until 1985 that MS finished one of their own (MS-C 3.0).

For common 8 it systems, BDS C for 8080, of 1979, might have been the first, followed by Small-C in 1980. Both kinda limited systems, more like proof of concept. The first major commercial product I can think of would be Aztec-C in 1982. Eventually the 8 bit compiler for desktop systems (*3) - and that was what C was targeted at in the beginning. As alternative to build in BASICs and PASCAL - which was the coming language of the 1980s. Just think Turbo-Pascal.

Which is a good keyword here, as Borland was, at least during the 80s, quite good in delivering what the marked wanted. Still, their Turbo-C only came in 1987.

Another good marker might be Apple and their Mac series. All Lisa and later all classic Mac system software and most applications were written in Pascal. Yes, this includes explicit the OS. It wasn't until 1987 that Apple even included a C interface (and compiler) to MPW. Pascal Support was, way into the PowerPC age the way to go.

The second half of the 80s is when C became a somewhat relevant language in microprocessor programming, one that made sense to support (like in that data book). And it wasn't until the very late 1990/early 2000s that C - or better C++, became the first stop for many areas.

---

Now, for your actual project way more information would be needed to decide - starting with CPU, System and Size but as well why you assume it's HLL in general and C in particular. More likely I'd say the assembler used was macro equipped and a library (*4) of structure and data macros was used. The resulting code may quite like coming from an HLL - after all a compiler doesn't do much different by modifying and stitching code sniplets.

---

*1 - The product also had some development time, so language decision must have been way before 1983.

*2 - This is about C becoming a the one language across platforms, supported by essentially every CPU, OS and development tool, one that had to be supported, in ubiquitous use from embedded 8 bit to supercomputing. It is not about usage at all, as there have always been forerunners, individual users and projects using non mainstream product - which C was clearly before becoming so prevalent that people assume, without further research the language to be used to generate code.

*3 - Which BTW is opened up by now and well archived.

*4 - Guess what we called 'A Library' would be today called a framework and a documentation loaded with more 3 letter words than assembly instructions used.

Answer 2

I was programming full-time on Aztec-C (for Z-80s) starting in mid to late 1982. Our target systems were embedded devices using STD-Bus. We used CP/M as a dev environment. The company also had business systems (mostly written in C) that ran on CP/M (my team would get pulled in when they'd get lost). Those systems used the full 64k, and swapped memory in and out (using overlays) to extend it. Our (embedded) systems were anywhere from 16k EEPROM and 16k RAM to 32/32. We did things like write a 3.5 kB subset of the standard C library so that we had strlen, strcat and a stripped down sprintf that we could use.

Eventually, I wrote a very simplified real-time monitor we could use in our code (it was really just a big event loop). Elements of the core were written in assembly language, and there were I/O stubs written in assembly as well. Almost everything else was written in C. People would blanche when I showed them some C that ran at the interrupt layer (really tiny bits of very well-tuned C).

Debugging was a pain. We ended up paying a small fortune for an in-circuit emulator that gave use the ability to set breakpoints and single step (at the op-code level) through our code. Initially, we'd do this using a map file to resolve symbols. We eventually got a symbolic capability within the emulator. Luckily, Aztec-C was stupid (it had nothing in the way of optimization). I got to the point where I could look at a block of code and say "OK, that's the for loop, this is the assignment and then the function call".

The dev environment was interesting. We'd edit and compile on a terminal running CP/M. Our output was packaged as a normal CP/M COM file (which is just a COre iMage file - addresses in the file mapped 1:1 to addresses in memory). When we wanted to test, we'd run our COM file - it would blow away the "OS" and take over the machine. When we wanted to get back to the dev environment, we hit the reset switch and reboot back.

It sure felt mainstream to me at the time.

Anecdote: This was our standard platform for factory floor embedded devices (Z80s, off the shelf STD-bus hardware, and C code). We were in Canada and associated with a related company in the US. Their standard equivalent was a home-designed 6800 all-in-one motherboard with all the code in assembly language. Our hardware cost more, but we could turn out the software in no time at all. The two companies got bought by a much larger company and there was a desire to standardize things. So I got up in front of management and made my case. At one point, the president of the now combined company (not the parent) interrupted and said "My people tell me that writing in assembly language is much more efficient and error-free compared to writing in C". I had no idea how to tell him he was an idiot, so I babbled about lines of code and programmer output.

Answer 3

In my experience, 1983 would be possible but a little on the early side for people to be doing systems programming in C on 8-bit machines. I had summer jobs in 1982, 1983, and 1984 at Digital Research Inc., which was a fairly big systems house in Pacific Grove, CA, that sold operating systems such as CP/M and MP/M, and also sold compilers. The summer of 1984 was the first time that I started hearing any buzz about C for that type of purpose. Earlier, the perception was that it was a language used on Unix timesharing systems. DRI's own software tended to be written in either assembly language or PL/M. They had a PL/M compiler they had bought or licensed from someone else, and they were very happy with its performance and code generation. (I think it may have actually been a cross compiler that ran on a VAX or something.)

By 1983, DRI was selling a C compiler, which they had actually bought outright from someone else. This was not their usual custom, but nobody at the company had even worked with C, and I guess they wanted to have the compiler in their product line, because some customers wanted it. People complained that this compiler was slow and generated low-quality code.

In 1984, a couple of Japanese programmers had come over and were working at DRI in California, and they were considered notable because they were sages in C -- a skill that other people on the team were just starting to learn. I remember one of the Californians describing C to me as a "glorified assembly language." He said this not entirely disapprovingly, but it was definitely considered minimalist compared to baroque languages like PL/I, which had been more in style, and it also did much less abstraction away of the hardware. This was an era when people would actually use the register keyword, and people would write their own .h file that would #define WORD16 int.

In this same year, DRI started work on a redesign and rewrite of their OS, which I worked on for about a month. Both the core of the OS and the command-line utilities were in C, rather than what they previously would have done, which would have probably been assembler+PL/M. It was known by a code name at the time, but I think it was what later became GEM.

Answer 4

Full C compilers on the 8-bit series was not widely seen, but "mini-C" and "tiny-C" compilers were fairly common. One example is the OSS tiny-C for the Atari machines or Abacus on the C64.

At the time, Pascal was still a major force, and Pascal compilers tended to be more common on the 8-bit machines. Smaller versions of Pascal/Algol were also common, like Action!

All high-level languages like these would be limited by the small stack space available, especially on the popular 6502. This is why Action! didn't use activation records, and thus lacked recursion (which also sped proc calls).

Answer 5

The Hitachi 6303 is unlike typical 8-bit CPUs of the era, and is in fact suitable for high level language programming and C in particular. It has a stack that can hold local variables. Subroutines are entrant, and parameters are passed on the stack. It supports 16-bit pointers that can point anywhere in memory. It has a fairly orthogonal instruction set and primitive compilers can easily generate code for it.

It's not fair to compare it with computers like the Spectrum or the C-64. Rather, look at the Tandy Color Computer with its more Unix-like operating system OS-9.

It's quite possible that a bespoke simple high-level language could have been used in-house, allowing expression statements with general arithmetic, variable assignments, function calls, etc. In short, such a language would be very similar to K&R C (maybe even inspired by it) even if it wasn't 100% compatible with it or carefully getting all the detailed semantics the same.

Answer 6

A personal anecdote: My first computer book in 1981 was called "Programming the Z80". It was focussed on assembly. I had learned Fortran in school but the main language for my home computer was Basic. Assembly was necessary for joystick and keyboard commands for a game I made. As a language, Assembly on the Z80 felt so fast but also terrible to program in given how primitive it was. I never heard about C until years later.

Answer 7

I worked in 1984-86 on CAD software for 6502 machines. We did our coding, assembling and linking on CP/M, and wrote a few utilities in C for the CP/M side during 1984. It was probably Aztec C, and using that for firmware would have have been rather brave, but C compilers were definitely around. Microsoft may not have had one until later, but they weren't necessarily technology leaders at the time.

Answer 8

A quoted comment (by lloyd 2019-02-05 12:54 UTC) from an interesting article about the 6303, MC3 - A DIY 8-bit computer (emphasis is mine):

I used those same '80s processors a lot and still find much to like about them, especially the 6303's instruction set which was a joy for assembly programming. skipp, that repeater manual's a labour of love!

Can't help with a C compiler I'm sorry. In those days Pascal was more popular and it's possible only Hi-Tech was a serious effort for C on the 6303. The current chip I've found with the nearest architecture is the STM8, but the FOSS SDCC compiler for that doesn't target the 6303 or even the 6801 AFAIK. The site below has Hi-Tech for CP/M - can't see a DOS version there but it'll run in an emulator. It's Z80-focused, so maybe it didn't yet support the 6303:

https://github.com/serge-404/HI-TECH-C-V3.09

A direct link to the comment isn't available, unfortunately - you'll have to search the page, it is about 80% down.

Answer 9

I started programming 1984 on a Sinclair (Farewell, Sir Clive!) ZX Spectrum, (which was invented two yeas earlier). Around 1983 was the start of the golden era of 8-bit "home computers" like the ZX spectrum, the C64, Ti99/4A, the BBC computer etc., and the Apple 2e.

Keep in mind that those computers had 64k or less RAM (the ZX81 had 1K, the ViC 20 hat 5K, the Spectrum had 16K or 48K).

Typical CPUs were Z80A (Spectrum) and 6502(?) (C64)

Owning such a thing became affordable at that time (I remember I paid 498 DM for the Speccy, the C64 would cost 700 DM).

Most people just played games, but you could also program quite well. The machines usually had a BASIC interpreter built in (in ROM), and BASIC was easy to learn, so it was common to program in Basic.

With the Speccy came a hand-book which explained the whole thing, including a BASIC programming course with examples, all system settings, and all Assembler Op Codes.

BASIC was terrible slow, so if your wanted a program to run (and not to crawl), you had to use another language.

A natural choice was Assembler then, because an assembler is small enough to fit into RAM. So I used assembler to program little games or graphic routines (e.g. drawing lines and circles much faster than with the built-in commands).

I also looked out for alternatives then and I can't remember to have seen a C compiler. Instead, alternatives (for the Spectrum) that I remember were:

• Beta Basic (it was way cool at that time)
• Forth (White Lightning)
• Pascal (not sure here, it was quite unusable IIRC)

On other machines there were languages like "Action!" (for the Atari 8-bit computers).

There certainly existed C compilers for the spectrum (at least a few years later), but I wasn't aware of them (and nobody I knew).

But even if I had owned a C compiler at that time, I certainly would have used Assembler instead.

Keep in mind that programs for 8-bit computers were much smaller and simpler, and more complicated routines were availabe in ROM anyway, so e.g. on the Spectrum, if you need to load a file from tape, you just had to call the existing routine.