difference between assembly directive and pseudo-inst ?

No --- both terms can and often do mean the same thing, but are usually used by different assembler vendors.

Hmm. I'd disagree with that. In my understanding a pseudo-instruction actually generates some kind of code for the target processor, while a directive just tells the assembler something, like changing modes (e.g.

Ed

pseudo-instruction

(e.g.

I was going to answer the OP, but then I realized I don't have a clear definition in my mind. Consider a processor that has no NOP instruction per se. An assembler might synthezize NOP out of a redundant register operation. That is a pseudo-instruction. Or on some processors (ARM, PA-RISC e.g) there is no way to load a 32-bit immediate into a 32-bit register. Assemblers will either declare a hidden constant in ROM and generate an instruction that loads indirect from that ROM address (ARM), or generate two instructions (PA-RISC), one to load the hi side, one the lo side of the register. In either case, ldi reg,#imm32 is a pseudo-instruction.

A directive like ".section FRED", which tells the assembler to flag all subsequent code as being emitted to a specific section, is an assembly directive. It doesn't emit any code. But I don't know if that is a defining criterion of an assembler directive.

Consider dc.b "String",0 - I've seen the declare immediate syntax described as a directive. I certainly wouldn't call it a pseudo-instruction. Yet it does emit code.

Where I've seen the term "pseudo-instruction" used it's been in the PA-RISC sense, where the assembler is giving you a mnemonic for an instruction that doesn't exist. The only processor I've used that does this is the PowerPC, and they restrict themselves to a 1:1 mapping between pseudo instructions and issued instructions -- the ARM and PA-RISC methods are certainly a bit more perverse!

It's easier to tell the difference if you've worked with a variety of assemblers, but:

Mnemonics are most common -- they're what makes the assembler an assembler, after all.

Assembler directives are next most common, they give instructions to the assembler about how to interpret pieces of code and to emit hard-coded data -- so things like .section and db "bob", etc., are assembler directives. You could argue that defining labels in the code is an implicit directive, and some assembler documentation does.

Many cheap assemblers stop here.

Assembler macros are predefined pieces of code, often parameterized, that you can define using (what else) assembler directives. They're basically a way to write an inline function in assembly. I _like_ macro assemblers, they're what makes assembly language productive if you have to do it. For really speed sensitive operations I _particularly_ like macro assemblers that'll let you implement a loop as part of the macro so the assembly that results has the unrolled loop. This has saved my ass on at least one occasion.

Most non-RISC assemblers stop here.

Pseudo instructions are as described above. They are essentially pre-defined macros, and you could even implement them as macros if you felt like it.

Sure. If it helps, I'm sure you have a clear definition of "instruction" in your mind. Then a psuedo-instruction is just something that looks like one of those and acts like one of those, but isn't. Clear as mud, eh?

I'd say it probably is.

I'd say "dc.b" is a directive and "String",0 is data, but I suppose that's cheating. For me, the determining factor is the answer to the question "what is actually processing this notion?" If the answer is "the assembler" I call it a directive and if the answer is the target micro, I call it an instruction. I think you'll find that even though it might not be stated that way very often in print, it's a pretty reliable guide in practice.

Ed

That's your understanding. I was trying to be as general in may answer as the OP was unspecific with his question.

And yes, I do remember having used assemblers that call things like .ORG, EQU or DB a "pseudo instruction" (they even give them the syntactical limitations of a regular opcode: won't work if written in the first colum of the line). For the case of DB that even makes some sense --- it actually generates somthing that will be put into the output file, after all, just like a mnemonic would.

It sounds as though you have some reasonable answers, already. I'll add my own view...

A directive communicates with the assembler or linker (or some other tool in the chain, such as a code-reorganizer, etc.) but usually does not get executed on the target at runtime. It may address pretty printing/formatting, or help to assign segment/section names to code or data, or ask the assembler/linker to use a particular alignment, etc. But whatever the exact purpose, a directive's general purpose is for the programmer to inform some tool in the development chain about some particular intent that may not otherwise be clear from just reading nearby data and code statements.

A pseudo-op or pseudo-instruction is typically something that "looks like" an instruction statement but instead where it maps to a different and possibly less obvious construction of a regular instruction found in the cpu architecture description (which is NOT the same thing as the assembler's.) For example, in the MSP430 microcontroller from TI, there is no NOP (no-operation) instruction in the micro. But there is a NOP recognized by the assembler, which is instead mapped to a genuine instruction found in the architecture, namely "MOV #0, R3". So NOP is a pseudo-op. Actually, there are a number of possible formulations of NOP on the MSP430, with different cycle times. But that is the one chosen by the assembler tool coders. Similarly, the MSP430 assembler accepts "INC ..." as an instruction, but it really translates into "ADD #1, ..." Another pseudo-op.

There are, of course, examples that defy the above. In the x86 MASM/ML assembler for the PC, there is something called ".STARTUP" which informs the assembler/linker about some details you intend (namely, that this is the place where you want to start running code) and automatically helps define a code segment name for you, but also can generate code, as well. So tool programmers can certainly construct hybrids that cannot be exactly placed through the above line-drawing I just mentioned.

Hope that helps.

Jon