1

When writing in a language such as C, the compiler theoretically takes your human readable code and translates it into machine code - relatively hardware-dependent atomic instructions. Each CPU architecture seems to have an Instruction Set which is implemented for the CPU in some sort of hard-wired way, yet it seems that different CPUs can implement the same ISA in different ways, say x86.

Does this mean that an ISA essentially acts as an abstraction layer for the hardware? x86 says: These are the standard instructions that I offer - you don't need to know HOW the hardware does it, just know that it does and you can use them by sending me the following machine code?

Thus, if I were to construct a new CPU and I implemented my CPU in such a way that it followed the x86 standard, I would not need to write a compiler specific to my hardware, but that any compiler which compiled from C to the x86 ISA would be sufficient for my new CPU?

Justin
  • 1,226
  • 4
  • 18
  • 21

2 Answers2

1

the compiler theoretically takes your human readable code and translates it into machine code

I would say this is what the compiler does. It is not Theoretical.

If you meet the spec for the instruction set then you are free to choose your hardware implementation.

The Instruction Set might have some simple instructions like ADD, SUBTRACT, as long as the CPU performs the bit accurate instruction you should not care about the implementation. In fact this is where performance improvement can be made by increasing complexity of the adder implementation to allow faster clock speeds.

Morgan
  • 19,934
  • 8
  • 58
  • 84
  • Your last sentence contradicts your second last sentence. Compilers certainly care. – user207421 Jan 12 '13 at 00:14
  • What is the contradiction? You receive a fixed instruction (bit pattern) for example an ADD. The hardware decodes the ADD and performs an ADD it says nothing about the adder architecture implemented by the hardware. – Morgan Jan 12 '13 at 10:31
1

Yes, the x86 architecture is well documented and forms an abstraction layer. However, an optimizing compiler can do better if it understands load-use delays, the number of load-store units, the number and types of computational units, cache sizes and cache lines; the number of internal registers, some processors do more reordering of the instruction stream, etc.; these things being implementation-specific.

For example, an older processor might have only one integer multiplication unit, a newer one might have two (a really old one might have none, I worked on one such, though was not x86). Their types might also differ. These differences alter the balance between speed-space tradeoffs in optimization/code generation, so a strategy that knows which is which may use different instruction sequences. For example, a multiply by a large constant is probably shortest using the multiply instruction, but could be slower or faster than several shift and add operations, depending on the underlying implementation. So, the compiler has some choices to make, and since it can keep track of a lot of state about the code it is writing, it can use rather complex decision strategies.

Another common optimization strategy is to interleave two or more different computations; this so as to keep the processor more busy. To do this often increases the number of registers needed, and may even require more instructions, and could be quicker yet longer or not depending again on the underlying implementation.

Erik Eidt
  • 23,049
  • 2
  • 29
  • 53