What are the trade-offs between using C and Assembly?

In my career the subject of this question actually did occur. I have been writing disk drivers for a LAN OS back in 1989. We quickly moved to using C, the only assembly code that was really needed was for a boot sector (C would get to big for that). Actually, you learn to predict the assembly the C compiler will generate making C like a hyper macro assembler and merging the two approaches.

Using C offers higher-level abstractions, portability across different hardware, and faster development time compared to Assembly, which provides finer control over system resources and potential for more efficient code at the expense of increased complexity and lower portability. While C abstracts away many hardware-specific details, making it easier to read and maintain, Assembly allows for precise optimization that can be crucial in performance-critical or resource-constrained environments.

Abstraction Level: C: C is a high-level language that provides abstractions, making it easier to write and maintain code. It allows you to focus on solving problems without worrying about low-level details. Assembly: Assembly is a low-level language that provides direct control over hardware resources. It requires a deep understanding of the underlying architecture and specific instructions. Portability: C: C code is portable across different platforms. Once written, it can be compiled for various systems without major modifications. Assembly: Assembly code is not portable. It’s specific to a particular architecture, which means you need to rewrite it for each target platform. Efficiency:

Codes in the C language are first translated into assembly before being compiled. Thus, we can already identify that if we were able to write assembly code with mastery and speed, it would be worthwhile to program only at the low level. This would give us the ability to implement more efficient codes. However, implementing in C is much simpler and also portable to different architectures, where the transformation to assembly can already be altered depending on the architecture in which the C code is being compiled. If we were always programming in assembly, this would require changes depending on the architecture used.

I do not really see where is the problem. I used to program lots of micros, 8-16-24-32 bits but, of course, I never "keyed any code in them using switches or a hexadecimal keypad". Not even in 1990. One always uses a cross-compiler, works comfortably, and does not really make much difference between asembler and C. In a couple of cases, I actually developed my own simple intermediate-level language (it was for Z181, I called it TdMATE, the Td standing for transducer). But the code was always developed and debugged on a separate work-station and then written into an EPROM or similar. On micros one often fights with limited recources and that can affect one's decisions much more than the language as such.

I did use keys on the front-panel of a PDP11, to enter a boot program. But agreed, assembly code and c code from mid 1970s to early 1980s. PDP11s and 6802 micro. Then switched to the array language Apl - initially APL\11 on a Vax 750 ... I still have some of that code in my libraries, still runs fine on an i7 .... I tried lots of the other standards on the way, like Lab-View and others - always ended up writing my source in Apl, and hand-translating to these other languages. If you want to compile Apl to C, try aplc (see my references).