SoylentNews is people
SoylentNews
from the A|Journey|Through|the|CPU|Pipeline dept.
It is good for programmers to understand what goes on inside a processor. The CPU is at the heart of our career.
What goes on inside the CPU? How long does it take for one instruction to run? What does it mean when a new CPU has a 12-stage pipeline, or 18-stage pipeline, or even a "deep" 31-stage pipeline?
Programs generally treat the CPU as a black box. Instructions go into the box in order, instructions come out of the box in order, and some processing magic happens inside.
As a programmer, it is useful to learn what happens inside the box. This is especially true if you will be working on tasks like program optimization. If you don't know what is going on inside the CPU, how can you optimize for it?
A primer for those with a less formal background.
(Score: 2) by frojack on Saturday October 31 2015, @07:36PM
I can only imagine your concept of a big project is different than mine. Unless you consider IBM's VM operating system to be a small project? It was written entirely in assembler, or at least the parts of it that I worked on — system config, scheduler, dispatcher, free storage manager, etc. Wikipedia has some background on IBM's BAL — Basic Assembly Language. [wikipedia.org] Though I do not have first-hand information, I have a strong suspicion that IBM's COBOL and FORTRAN compilers were also written in assembler.
Having some exposure to compiler writing from a long ago contract, I would doubt much of (if any) a compiler was written in assembler. You usually start with some high level language (even something as *cough* "high level" as basic, on some existing platform, to evaluate your compiler source code and produce assembler output. You start small, read something in, say, look at the generated assembler code till it works good enough, "can" that code, and then start working on Writing something out. Building up a collection of library routines.
Before long, you are writing the compiler for your new language IN ITSELF. Very often, compiler developers would get away from any other language, say C, and end up writing their new FORTRAN or Algol compilers in FORTRAN or Algol, or whatever.
Often, these Compiler-Compilers are the best way to get from one platform to another. You just change the assembly instructions to those of the new processor.
No, you are mistaken. I've always had this sig.