3
\$\begingroup\$

Many microarchitectures can implement a given digital system architecture. For example, and as Weste and Harris explain in their CMOS VLSI Design,

Digital VLSI design is often partitioned into five levels of abstractions: architecture design, microarchitecture design, logic design, circuit design, and physical design. Architecture describes the functions of the system. For example, the x86 microprocessor architecture specifies the instruction set, register set, and memory model. Microarchitecture describes how the architecture is partitioned into registers and functional units. The 80386, 80486, Pentium, Pentium II, Pentium III, Pentium 4, Core, Core 2, Atom, Cyrix MII, AMD Athlon, and Phenom are all microarchitectures offering different performance / transistor count / power trade-offs for the x86 architecture.

My questions are twofold:

(1) Is the corresponding assembly language for a given architecture microarchitecture-agnostic? (I think the answer is yes, as that ought to be the entire point of the higher level architecture abstraction.)

(2) Is the assembler to translate to machine code is microarchitecture-agnostic?

\$\endgroup\$
2
  • \$\begingroup\$ Agnostic in the sense that it still runs on whatever platform (no documented, functional differences), or literally agnostic ("not knowing") in that one cannot tell any difference in semantics, run time, etc. at all? \$\endgroup\$ Commented Dec 13, 2023 at 22:53
  • \$\begingroup\$ I think I mean the first one, though I'm not sure what you mean by "semantics" so perhaps the second? @TimWilliams \$\endgroup\$
    – EE18
    Commented Dec 14, 2023 at 3:16

3 Answers 3

3
\$\begingroup\$

Imagine a simple assembly instruction (with opcode and operands) that has existed ever since the 386 was made.

For example "MOV AX,BX".

No matter how the CPU actually executes the instruction, the opcode and operands are the same and they end up doing seemingly the same thing you would expect.

So,

  1. Yes because same old opcode works to do the same result on all CPUs regardless of how they really execute the opcode with underlying logic and architecture.

  2. Yes the assembler that was used to compile code for a 386 cannot know on which CPU you are really going to execute it, and anyway there will likely be only one instruction opcode for "MOV AX,BX" instead of multiple architecture-specific opcodes that end up doing the same thing. Of course if you use an assembler for more modern architecture and tell the assembler what architecture you are targeting, it may use architecture-specific instructions and their opcodes to do the same thing, and these new opcodes may for some reason be faster to decode or execute for some reason.

Obviously, if your new CPU which can support newer opcodes, the compiler might warn or give an error that you are using new opcodes which the old 386 cannot execute. But since the 386 should anyway raise an unhandled opcode exception, you might be able to simulate execution of newer opcodes in software with the existing opcodes (if possible). The assembler won't know how your CPU managed to execute what you told it to.

\$\endgroup\$
0
2
\$\begingroup\$

(1) Yes, you are correct. The corresponding assembly language for a given architecture is typically microarchitecture-agnostic. Assembly language is designed to provide a human-readable representation of machine code instructions and is tied to the architecture's instruction set rather than the specific microarchitecture details.

(2) The assembler, which translates assembly language code to machine code, is generally microarchitecture-agnostic as well. It primarily deals with converting symbolic representations (assembly language mnemonics) into the binary machine code specific to the architecture. The assembler is concerned with the architecture's instruction set and does not delve into microarchitectural details.

\$\endgroup\$
0
1
\$\begingroup\$

Yes, except that if a microarchitecture is introduced which implements an existing architecture but- as an example- can reorder memory accesses an extra fence or memory barrier assembler-level instruction might be added.

This is distinct from gross architectural changes (e.g. the MMX -> SSE transition on x86) and from enabling/disabling low level facilities (e.g. memory access reordering) using a control register accessed via standard opcodes.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.