Full break down of high level language to executed code

[brewbuck]

But assembly is already architecture specific.

The two things serve different purposes. Machine language is expected to not change drastically over multiple revisions of a processor family, and it's publicly documented (otherwise nobody could use their CPU...) Microcode is the glue between the publicly known machine language and the actual way the processor works internally. It is thus very specific to the particular model of CPU in a way that a normal programmer is simply not interested in. We want the machine language/assembly language to be stable so we don't have to keep learning it over again. The manufacturer has to actually make the CPU *work*.

[c_weed]

The two things serve different purposes. Machine language is expected to not change drastically over multiple revisions of a processor family, and it's publicly documented (otherwise nobody could use their CPU...) Microcode is the glue between the publicly known machine language and the actual way the processor works internally. It is thus very specific to the particular model of CPU in a way that a normal programmer is simply not interested in. We want the machine language/assembly language to be stable so we don't have to keep learning it over again. The manufacturer has to actually make the CPU *work*.

So in a nut shell the reason is, while assembly is fairly specific compared to higher level languages (e.g. specific to an architecture, like x86) microcode is EVEN MORE SPECIFIC where it is drastically different between even generations of a processor (e.g. an Intel i5 with Sandy Bridge would have different architecture than an Intel i5 with Ivy Bridge)?

[Elysia]

Couldn't this is achieved by high level languages (such as C, C++) in the sense they provide another layer of abstraction so that a programer only needs to know the high level language and let the compiler worry about outputting assembly targeted at the specific platform?

Then the compiler vendors would have to rewrite their compiler every time the instruction set changes. How long did it take all popular compilers right now to produce good assembly?

So in a nut shell the reason is, while assembly is fairly specific compared to higher level languages (e.g. specific to an architecture, like x86) microcode is EVEN MORE SPECIFIC where it is drastically different between even generations of a processor (e.g. an Intel i5 with Sandy Bridge would have different architecture than an Intel i5 with Ivy Bridge)?

Microcodes are most likely broken into very small, specific instructions, that's true.
However, I seriously doubt that they change drastically between every generation. This is the same argument as when the high-level instruction set changes.
The internal architecture is made to work with the micro-ops the processor generates, so if those micro-ops change drastically, then the entire architecture needs to be reworked. Sounds like a lot of work, doesn't it?
Remember: hardware can also be seen as a software architecture--it is also written in a high-level language (VHDL or Verilog are the mist popular), so there is a lot of legacy code, I'll bet.

[brewbuck]

So in a nut shell the reason is, while assembly is fairly specific compared to higher level languages (e.g. specific to an architecture, like x86) microcode is EVEN MORE SPECIFIC where it is drastically different between even generations of a processor (e.g. an Intel i5 with Sandy Bridge would have different architecture than an Intel i5 with Ivy Bridge)?

Drastic is relative. Between one model and the next things might change a lot, or not change at all. The point is there needs to be an abstraction layer there in case it needs to change.

We're talking about an implementation detail here. It is what it is. The only reason people like you and me even know of its existence is because sometimes it can be upgraded in case a bug is found.