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 martyb on Saturday October 31 2015, @02:38PM
Most certainly agree. How is data stored in memory? Knowing something about the underlying hardware, I can, for example, understand how a C struct is laid out in memory and how pointers are implemented.
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.
I, too, have witnessed this. Sometimes, for whatever reason, the compiler just gets it wrong. A compiler is a program, and is subject to mistakes, as well. I have found and reported bugs in a couple of them. Still, for the vast majority of the time, compilers do a good enough job and much more quickly than hand-crafted assembler would often be. So, I'm entirely with you on this point.
I appreciate the anecdote. And, yes, compilers occasionally make what seem to be poor choices in particular cases.
That said, it bears mentioning for those who might not be aware that there are space and time tradeoffs, e.g.: loop unrolling. To illustrate, here is some pseudo code where we assume that x is defined as an array of unsigned bytes:
could be unrolled as:
By removing increment and conditional branch instructions, one ultimately has fewer instructions to perform — it would run more quickly. So, the assembly listing would be longer, but the code would generally run more quickly.
On the other hand, one could define, say, an array of long ints (32 bits) defined to be located at the same address as x[] and one would need only two instructions to zero out those locations:
Note, however, that if taken to extremes, one gets to the point that the additional size of the code exceeds what can fit in cache and costs a cache miss which could eliminate the time savings. As with most things, there are tradeoffs.
Wit is intellect, dancing.
(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.