[TUHS] Comments on "C"

[brantleycoile@me.com (Brantley Coile)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]


> On Aug 28, 2016, at 8:37 PM, Marc Rochkind <rochkind at basepath.com> wrote:
> 
> But, as anyone who's actually programmed seriously in assembly language knows, C is not assembler. It is a system programming language low enough to be used for things that were once done in assembler, the most important of which is an OS.
> 
> So, for most of us, we no longer had to write in assembler. But that doesn't mean C is assembler.
> 

Interestingly, assembler seems to be making a come back if one gives any credence to the Tiobe index. http://www.tiobe.com/tiobe-index/ As one who has written a lot of assembler code and no small number of assemblers, I wouldn’t like to write in assembler again. The problem is the lack of redundancy to catch errors.

As you all know (preaching to the choir here) the semantic model for C is the common von Neumann architecture. With the exceptions of returning structures, the semantics map one to one with most machines. This means that I can write C code and know pretty well what instructions are going to be generated. This in turn means that I can use C for almost all cases where I would have had to use assembler. The great Niklaus Wirth demonstrated this with his Oberon and some other small languages that completely replaced the use of assembler in his systems.

Some modern compliers have broken this, however. I have never been able to figure out what clang is going to do. But I should expect 28,000,000 bytes of instructions to do weird things. There’s no reason a C compiler should ever be more than about 0.25 MB of text.

  Brantley Coile