Reputation: 25
I have read that Assembly language is processor dependent, and there were special set of instructions for every processor. I use intel i5 x86_64 architecture processor. When I write code I haven't used any different set of instructions. I use NASM assembler. It assembles my code and converts to binary. So Whats the matter with Processor there. Even my friend with different architecture runs the same code (not compiled but source code) and gets the same Output... So where is Assembly language processor dependent ??
And the code is ... Its just an example, every piece of code runs on both architectures x86_64 and 8088 microprocessor
[ORG 0x7c00]
xor ax, ax ;make it zero
mov ds, ax
mov si, msg
call bios_print
hang:
jmp hang
msg db 'Welcome to Macintosh', 13, 10, 0
bios_print:
lodsb
or al, al ;zero=end of str
jz done ;get out
mov ah, 0x0E
int 0x10
jmp bios_print
done:
ret
times 510-($-$$) db 0
db 0x55
db 0xAA
Upvotes: 2
Views: 1238
Reputation: 21
When you use: [ORG 0x7c00]
xor ax, ax ;make it zero mov ds, ax
You are using registers that 8088, 8086, 80386, 80486, Pentium and modern processors recognize, but if you use for example: xor EAX, EAX ;make it zero
This code will not compile for 8088 and 8086, but it will compile for 80386 and later because AX is a 16-bit register, EAX is a 32-bit register.
Upvotes: 1
Reputation: 71506
Go to the car dealer and take a brand new toyota for a test drive. Then go to other used car lots and find older toyotas of the same model, but different year. They are not identical every year, but they are often quite similar to other models for years at a time, placement and look and feel if some items, door locks, window controls, etc. Then go to a ford dealer and repeat with some model of ford. Instantly the ford is dramatically different than the toyota even though they are both cars with four wheels and an engine that do the same job. Among fords they are often similar to their siblings and prior and post year models for specific details, sharing parts for years in a row.
No different here, x86 processors have items in them that you can see a resemblance all the way back to the first 8088/86. but compare that to a power pc or an arm or a mips and you will see that although they are all processors that can run modern operating systems, their individual details and look and feel are much more different across brands than within brands.
Upvotes: 3
Reputation: 11418
Even as the 8088 and the Intel Core i5 are two different beasts, with massive differences between them, there one thing that makes them to be "connected": the Core i5 is binary compatible with the 8088. In fact, all the x86 processors are binary compatible with the old 8088, at least when they are used in so called "real mode". Binary compatibility means that a program written for the 8088 will run in the Core i5 processor, provided that both processors are installed in systems with the same, or compatible I/O devices (unless your program does not need to communicate to the real world).
Also, there are processors from different makers that are source compatible. This means that the assembler source code written for one processor can be assembled using a direct translating into binary code for the other processor. Examples are: source code for the Z80 processor can be assembled to output binary code for the 8088 processor (and thus, for the Core i5 processor!)
And there are processor from completely different families, totally incompatible between them, for example, the PowerPC architecture versus the Intel x86 architecture. For them, to allow a program written for one of these to be able to run in another one, some sort of translator, interpreter or JIT compiler must be present. This is the case with OS X running on Intel processors, that uses a piece of software called Rosseta to read and translate on the fly instructions for the PowerPC architecture to the x86 architecture.
Upvotes: 0
Reputation: 22074
There are diffent layers of processor dependcy. Intel made a lot of effort to make subsequent CPUs compatible to prior CPUs of their family, so it's entirely possible to write code which runs on multiple "different" CPUs.
However, when you try to write some assembly code, which takes advantage of the specific features, this is no longer true. And if you try to write high performance code the rules are also changing on different CPUs even from the same family.
If you look at the instruction set from Intel and comapre them to older ones, you will easily see that newer CPUs have also new instructions that were not available before.
And also the OS takes a role in that, by providing support for older programs. For example you could run 16-Bit applications natively until Windows XP. In Windows 7 64bit the support was dropped. So when running such code, you may not even have noticed that there is a layer of support that makes your prorgam still working.
Upvotes: 0