Question And Answer Of Microprocessor 8086 Pdf
Jaunita Rousu
Here are some list of Interview Question Answers on 8086 Microprocessor. I believe this set of questions with solution will helpful for entry level position/academic interview. 8086 is one of famous microprocessor architecture. 8086 is 16-bit microprocessor designed by Intel which gave rise to X86 architecture. The work on 8086 design started in 1976 and chip was introduced to market in the summer of 1978.
Released by Intel in 1978 produced from 1978-1990. A 16-bit Microprocessor chip max. CPU clock rate 5MHz to 10MHz. Instruction Set: X86-16 package: 40-Pin DIP, 16-bit Arithmetic Logic Unit, 16-bit data bus (8088 has 8-bit data bus) 20-bit address bus. In 8086, bytes at even addresses come in on the low half of the data bus (bit 0-7) and bytes at odd address come in on upper half of the data bus (bits 8-15). The 8086 can read a 16-bit word at an even address in one operation and at an odd address in either case. The least significant byte of a word on an 8086 family microprocessor is at the lower address.
A memory address on the 8086 consist of two numbers usually written in hexadecimal and separated by colon representing segment and the offset. The combination of segment and offset is referred to as a logical address. In short Logical Address = Segment : Offset.
In general, memory accesses take the form of the following example: MOV ax,[Base Reg. + Index Reg. + Constant]. This example copies a word size value into the register Ax. Combined the three parameters in brackets determine what is called the effective address, which is simply the offset referenced by the instruction.
The signal M/IO is used to differentiate memory address and IO Address. When the processor is accessing memory locations M/IO is asserted high and when it is accessing I/O mapped devices, then it asserts low.
The 8086 does not have on-chip clock generation circuit. Hence the clock generator chip, 8284 is connected to the CLK pin of 8086. The clock signal supplied by 8284 is divided by three for internal use. The maximum internal clock frequency of 8086 is 5 MHz.
BINARYUPDATES.COM is a participant in Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to amazon.com or amazon.in
There is something vague with the memory timing operation of 8086 microprocessor as I read from many sources. There is a TAVDV which is the time from when a valid address goes on the bus until a valid data appears on the bus (in the read cycle). Have a look at this book (page 58).
To calculate that (the figure on page 59), it assumes 3 clock cycles as a whole and then subtract two redundant terms. One is the TCLAV which means the time from clock to when valid address is on the bus and the other term is TDVCL which means the time when valid data is on the bus until the edge of the clock.
Now, the book says TDVCL is 30ns. How that is calculated? Data lines must hold valid values according to the Tsetup. Therefore, in my opinion, TDVCL is absolutely greater than 66ns (which is the time for the clock to be high).
Without knowledge of the internal design you cannot attempt to calculate a value for these, which is why they are given. The fact the TAVCL is so large probably reflects the complexity of the internal asynchronous logic generating the address. It is likely TDVCL is small because the input goes directly to a flip flop.
The two values (TAVLC and TDVCL) can be used to calculate the asynchronous memory access time requirement as done in the book except for the fact they neglected to account for the round trip PCB trace delay.
For instance, the 8086 and 8088 processors do not support detection of illegal instruction operation codes, but this capability is available on the 286 and above, which trap on an attempt to execute an illegal opcode.
Most of them were just NOPs (either because they weren't wired up to anything or because they did stuff like writing a register to itself) or duplicates of other instructions (because the instruction decoder ignored some bits when it didn't need to pay attention to them), but some of them were more interesting.
On the 80186 and above, a new thing was defined called an "illegal instruction", and this new thing came with a new behavior -- a #UD exception that was generated when one was encountered. Before the 80186/80286, there was no such thing as an illegal instruction, just undocumented ones.
Your question then becomes, "what did the 8086 and 8088 do when encountering undocumented instructions" and the answer is simply that the behavior was undocumented. Some of them appeared to do nothing (i.e. they produced the same apparent result as a NOP instruction), while others did odd things, or simply the same thing as another opcode.
Basically, as the processor would read the bytes of a single assembler language instruction, those bytes would be fed as an input to a network of logic gates called the instruction decoder; this network was designed to produce as output the signals to enable or disable various internal components of the processor according to what the instruction was supposed to do, so that the processor ends up doing the required operation.
As a result, if you viewed the instructions of older, simpler processors as bit patterns, you might notice certain groupings; for example, if the top three bits of the instructions would be set so, you might know that it must be a jump instruction of some type; other patterns might identify other general types of instructions.
The design team for a new processor architecture would develop a reasonable set of instructions, the various networks of logic gates to implement them, and the instruction decoder to manage them all. Back when the 8086 and 8088 processors were designed, it was not yet economically viable to add extra logic to the instruction decoder to exclude any "undocumented instructions", so any bit pattern fed into the instruction decoder would do something, but only the documented instructions would be guaranteed to exist and work the same also in the future members of the same processor family.
Sometimes the undocumented instructions actually ended up doing something useful, but relying on them was risky, as it might mean any program using a particular undocumented instructions might only run successfully that particular processor model. On a newer model, the previously undocumented instructions might actually been used for some new functionality, or they might have become completely useless as a result of a redesign of the instruction decoder.
With 80186 or above, using a number of logic gates to trap the undocumented instructions was economically feasible, and it became a compatibility feature: a program might prefer to use a new instruction available in newer processors only, but could provide a routine to emulate that instruction in software within an "illegal instruction" trap handler.
Based on the other answers, the proper answer is: they do whatever the instructions bits tell them too.Since apparently they aren't validated, they always do something, even if that something is nothing.
EDIT: I had a question in the answer which I removed, which was "Another question you may ask is: if an instruction does not exist, how does the processor knows it length?", which was replied in the comments below.
0xFFFFFFF0 is where an x86-compatible CPU starts executing instructions when it's powered on. That's a hardwired, unchangeable (without extra hardware) aspect of the CPU and different types of CPUs behave differently.
Just about everything in programming works better with contiguous addresses. The CPU designer does not know what a system builder will want to do with the CPU, thus it's a bad idea for the CPU to require addresses smack in the middle of the space be required for various purposes. It's better to keep that "out of the way" at the top or bottom of the address space. Of course, keep in mind this decision was made when the 8086 was new, which did not have an MMU.
In the 8086, interrupt vectors existed at memory location 0 and above. Interrupt vectors need to be at known addresses and were desired to be in RAM for flexibility - yet it was not possible for the CPU designer to know how much RAM was going to be in a system. So starting from 0 and working up made sense for those (because no system in 1978 when the 8086 was invented would have 4 Gbytes of RAM - so expecting RAM to be at 0xFFFFFFF0 was not a good idea), and then ROM would have to be at the upper boundary.
Of course, starting with at least the 80286, interrupt vectors could be moved to a different starting location other than 0, but modern 64-bit x86 CPUs still boot up in 8086 mode, so everything still works the old way for compatibility (as ridiculous as it sounds in 2015 to still need your x86 CPU to be able to run DOS).
Keeping it somewhat simple: 64-bit CPUs have more addresses (which is one of the things that makes them 64-bit - e.g. 0x0000000000000000 through 0xFFFFFFFFFFFFFFFF) for example, so the extra RAM "fits". Assuming the CPU is in long mode. Until then the RAM is there, just not addressable.
I can't immediately find anything on what x86 assigns the stack pointer at power-on, but it would eventually have to be reassigned by an initialization routine anyway once that routine finds out how much RAM is in the system. (@Eric Towers in the comments below reports that it is set to zero on power up.)
It isn't located at the top of RAM; it is located in ROM whose address is at the top of the memory address space, along with any memory on expansion cards, like Ethernet controllers. It is there so that it won't conflict with RAM, at least until you have 4 GB installed. Systems that have 4 GB or more of RAM can do two things to resolve the conflict. Cheap motherboards simply ignore the parts of RAM that conflict with where the ROM is located. Decent ones remap that RAM to appear to have an address above the 4 GB mark.
c80f0f1006