1 Byte Instruction In 8085

[Gaetane Eary]

TheRST" instruction doesn't have to fetch an address, so that makes it a one-byte instruction (just the instruction fetch). A snippet of the address is contained in the instruction itself, comprising three of the eight bits. The call address becomes (in binary) 00000000 00xxx000, where xxx are the three bits found inside the RST instruction fetched:( 11xxx111 ). The call addresses formed are on the first page of the 64K address space.

Similar to a call, the RST instruction must push a 16-bit return address onto the stack: one instruction fetch cycle, and two more memory-write cycles to store the return address.

Because RST doesn't have to fetch the subroutine address, it runs faster than a CALL. Some 8085's take 18 clock cycles to complete a 3-byte CALL, while a 1-byte RST completes in 12 clock cycles.

My book says that it is a two byte instruction where the first byte is the opcode and the second is the operand. The first byte being 0011 1110 (3E in hexadecimal) and the second byte being 0011 0010 (32 in hexadecimal).

I am confused as to how exactly the opcode part is converted into machine code. I mean... what part of the "0011 1110" stand for "MVI" and what part of it tells that register A is to be loaded? How does "3E" tell the microprocessor both the information? That is it has to load data as well as the target register. Or is it that this entire opcode is predefined and you can't separate the "MVI" and "target register" in the opcode?

The color coding on that chart gives a strong indication of the opcode decoder if the 2 msbits are 00 then if the lower 2 bits are 10 then if bit 2 is a 1 then it is an MVI and bits 3-6 determine which register. basically 0b00rrr110 is an MVI.

Improving upon the answer given here.MVI R,d8 loads the supplied 8-bit data (d8) into the specified register or memory loaction (R). There are eight possible choice for R namely B, C, D, E, H, L, M, and A. These eight possibilities can be encoded with three bits as follows.

In 8085 Instruction set, LDA is a mnemonic that stands for LoaD Accumulator with the contents from memory. In this instructionAccumulatorwill get initialized with 8-bit content from the 16-bit memory address as indicated in the instruction as a16. This instruction uses absolute addressing for specifying the data. It occupies 3-Bytes in the memory. First Byte specifies the opcode, and the successive 2-Bytes provide the 16-bit address, i.e. 1-Byte each for each memory location.

Each instruction requires some data on which it has to operate. There are different techniques to specify data for instructions. These techniques are called addressing modes. Intel 8085 uses the following addressing modes:

In this instruction, 2400H is the memory address where data is to be stored. It is given in the instruction itself. The 2nd and 3rd bytes of the instruction specify the address of the memory location. Here, it is understood that the source of the data is accumulator.

The opcode 78H can be written in binary form as 01111000. The first two bits, i.e. 0 1 are for MOV operation, the next three bits 1 1 1 are the binary code for register A, and the last three bits 000 are the binary code for register B.

In the above program the instruction MOV A, M is an example of register indirect addressing. For this instruction, the operand is in the memory. The address of the memory is not directly given in the instruction. The address of the memory resides in H-L pair and this has already been specified by an earlier instruction in the program, i.e. LXI H, 2500 H.

An instruction of a computer is a command given to the computer to perform a specified operation on given data. In microprocessor, the instruction set is the collection of the instructions that the microprocessor is designed to execute.

I have declared a float variable y. The compiler will allocate 4-byte wide memory space for me. I have kept the beginning address of that 4-byte memory space into the pointer variable ptr. After that, I have stored binary32 formatted data (0x4091999A) into that memory space being pointed by ptr. And then I have called upon the print() method to interpret my stored 32-bit data as per following binray32/IEE-754 template (Fig-1); as a result, I get the correct float number - 4.55.

Figure-1:

And you are simply saying that the codes are not valid? 150 pupils out of 150 pupils have said that the codes are valid; it is not because the codes do produce the correct result; the codes are also logical. Similar arguments are also there in favor of union structure.

GolamMostafa:

I have declared a float variable y. The compiler will allocate 4-byte wide memory space for me. I have kept the beginning address of that 4-byte memory space into the pointer variable ptr. After that, I have stored binary32 formatted data (0x4091999A) into that memory space being pointed by ptr. And then I have called upon the print() method to interpret my stored 32-bit data as per following binray32/IEE-754 template (Fig-1); as a result, I get the correct float number - 4.55.

You are programming in C++, not assembly. Memory layout is irrelevant because it's the compiler that generates the instructions.

In most cases, the compiler can assume that two pointers of a different types don't alias the same piece of memory, so it optimizes the code with that assumption, changing the order of instructions, keeping a version of variables in registers instead of writing them to memory, etc. If two pointers point to the same memory, this is completely wrong.

No, I also provided an explanation, and links for further reading. Invalid pointer aliasing causes undefined behavior, and I've seen it happen multiple times.

If you don't believe me, just Google "C++ strict aliasing rule".

GolamMostafa:

150 pupils out of 150 pupils have said that the codes are valid; it is not because the codes do produce the correct result; the codes are also logical. Similar arguments are also there in favor of union structure.

GolamMostafa:

Are you not convinced that your machine (whatever it may be) is broken? It is already delivering IEEE-754 formatted data except that 2 bytes are corrupted which could due to noisy line etc. etc.

PieterP:

In most cases, the compiler can assume that two pointers of a different types don't alias the same piece of memory, so it optimizes the code with that assumption, changing the order of instructions, keeping a version of variables in registers instead of writing them to memory, etc. If two pointers point to the same memory, this is completely wrong.

In the following example codes, there are two pointers of different types -- one (ptr) is pointing to the beginning address of a 4-byte wide memory space containing a piece of float data; the other one (pointer) is pointing to the beginning address of a 2-byte wide memory space which is a sub-space of the said 4-byte wide space. When the values pointed by the pointers are printed, there is not seen any aliasing effect.

It is just by definition that the carry output of the last ALU operation is captured to bit-0 of the flags. This kind of thing is relatively easy for hardware to accomplish in a number of ways. It could have just as easily been any (other) bit of the flags (or even somewhere else!).

From only the definition of the instruction set architecture, we don't really know where the flags carry bit is (physically) located or how it is implemented. In fact, we cannot say for sure whether the whole flags register is an actual 8-bit register just like all the others, or is instead an alias for a bunch of bits that are located around the ALU and/or in other places around the processor and unlike the more regular registers.

And the thing is that it doesn't matter to the programming model: the instruction set tells us how the carry bit is exposed or made accessible to the programmer, not how it is implemented. Further, a different implementation of the 8085 instruction set architecture may choose different internal implementation method.

So, as a programmer, you're dealing with an abstraction (an ISA) whose implementation details are complex and hidden, and as a chip designer, you're free to make variations of the underlying implementation (say, for performance) as long as you don't break the abstraction of the ISA (in this case, by ensuring that a read of the flags register always produces the last ALU carry as the LSB of the value returned by that read).

I find this wording awkward, as it suggests that the A register itself is the source of the carries; whereas I would say that is that it is the addition operation that generates carry. Again, from the instruction set architecture alone, we cannot know (and don't really need or want to as it turns out) whether the addition operation operands for ADD are shipped somewhere else on-chip to be summed and whose results are returned to the A register, or, whether the A register is indeed some true component of the ALU.

This (8085) processor was designed and documented in an era where the abstraction (the instruction set) and implementation were not as clearly separated as they generally are today. Today, for example, a processor may have multiple ALUs and choose to perform an addition operation on whichever is currently free. Today's processors have tended move away from the notion of a (single) primary A register associated directly with a (single) ALU, and this shows in both newer instruction set architectures (e.g. x64) as well as in underlying chip design & implementation.

Not for the most part. As we noted in a previous question, add and subtract, carry-out, and with or without carry-in all work the same for unsigned and signed, so generally an instruction set won't provide separate instructions for signed vs. unsigned arithmetic.

(Unless it is providing instructions that automatically trap (throw exception) on overflow: then the processor will need to know if it should check signed or unsigned overflow, which means two different instructions for each of signed and unsigned).

3a8082e126