Difference between Pseudo-op and Machine-op?

Question

While studying on Assembly language programming I came across the terms "Pseudo-op" and "Machin-op".I am not sure what is their functionalities and how they differ from each other?

Answer 1

Besides assembler directives, it's common for RISC architectures to have pseudo-ops that expand to multiple instructions.

The most common type is a pseudo-op for the sequence of instructions needed to get a 32-bit constant (e.g. an address) into a register. Since a fixed-with 32-bit instruction doesn't have room for an arbitrary 32-bit immediate, the machine can't do it in one instruction. However, there's usually nothing to gain from separating the pair of instructions with 16-bit immediates, it would be annoying to do it manually. (IIRC, some superscalar in-order CPUs recognize such pairs when executed back-to-back, still running them in parallel even though they modify the same register.) ARM assembler pseudo-instructions MOV32 and ADRL do this.

Another interesting example is ARM's ldr r0, =0x12345678. It always assembles to one instruction, but can choose from two strategies: if the constant can be represented as a immediate (using ARM's barrel shifter), the assembler uses a MOV. If not, it puts the constant into a nearby literal pool and uses a PC-relative load. So this pseudo-op can emit an instruction and data (still in the same section, I think).

(The non-pseudo-op form of the LDR instruction is the normal load-register form supporting ARM's various addressing modes, like ldr r0, [r1, r3, lsl #2] to load from r1 + r3 <<2). So the same mnemonic can be a pseudo-op or machine instruction depending on the operands

---

MIPS takes pseudo-instructions to the extreme, with the normal ABI reserving at least one of the 32 architectural registers for use as a temporary by assembler-generated pseudo-ops! (I guess the MIPS designers felt that 32 was really more than needed, because in the standard ABI it's normal for interrupt handlers to asynchronously clobber 2 other registers, making them unsafe for use by user-space code. I guess that simplifies the design vs. having the hardware help more in saving/restoring architectural state on interrupts, but I haven't looked at the details.)