I was looking at instructions and their corresponding opcodes. Instructions such as "je" and "jz" have the same opcode:
je,jz - 0x74 (8 bit)
je,jz - 0x0f84 (16/32 bit).
Why do we have such redundant instructions?
Is it because it makes assembly coding easier? That is, it's easier to understand 'jump if equal' in some cases and 'jump on zero' in other cases. But we don't really code in assembly these days, so does it help?
What's the old quote from that computer architecture book we all had in school? "There's nothing wrong with x86, it's just that a lot of it doesn't make sense."
To answer your question: Likely because "jump on zero" and "jump if equal" are both jumps to a destination address based on the outcome of a previous instruction. That said, the outcome of the previous instruction sets the zero flag (ZF) to 1. JZ may be for "math" and JE may be for "comparison". So from a programmer perspective, it somewhat makes sense to have to two mnemonics. Perhaps the assembler writers of the early days were trying to mimic another popular assembly language.
Looking at the Intel x86 manual for Jcc (set of conditional jump instructions), we can see that both JZ and JE essentially mean "Jump Near if equal (ZF=1)". And then the docs actually mention that this is common for certain sets of jump instructions.
Because a particular state of the status flags can sometimes be interpreted in two ways, two mnemonics are defined for some opcodes. For example, the JA (jump if above) instruction and the JNBE (jump if not below or equal) instruction are alternate mnemonics for the opcode 77H.
They are just different synonyms for the same instruction. The instruction just branches based on the Z flag. The Z flag gets set if the result of a compare equal instruction is true. It also gets set it you test a value which happens to be zero.
Why do some english speakers say truck and others say lorry? Should we force everyone to conform to one standard? All hamburgers shall be big macs...
First of we still do program in assembly. Enough people do so that others dont have to. Your compilers rely heavily on it. Difficult to develop and debug the compilers and processors for that matter without it. Without compilers and processors, what would we do?
It is trivial to have the assembler parser accept jump if equal vs jump if zero bit is set, they are the same function, same instruction. Folks that understand and use the the flags (granted the z flag is easy but signed and unsigned carry are not) like to use the flags jump if carry, jump if zero, etc. Folks that think in terms of the relationship for those specific numbers for that specific operation want to see jump if equal jump if greater than jump if less than and so on. I would prefer getting rid of the jump if equal, jump if less than, and so on and just have the flags, jump if c set jump if c clear, jump if n==v jump if n!=v, etc.
Intel is not the first or last architecture where you will see this. I assume for the same reason, some people think in terms of the bit in the status register is on or off, and others think in terms of this is greater than that. It is an age thing in the sense that knowing the z flag means equal has been around as long as processors have had the z flag, but it has nothing to do with the age of the x86 family nor its goofy instruction set. Being developer friendly in this manner attracts developers to your processor, it is trivial to implement in the tools.
If you really want to get worked up about this why is there the intel syntax and the AT&T syntax for the same instruction set? That insanity goes way beyond jump if equal (zero bit set) vs jump if zero bit is set both encoding to a jump if zero bit is set instruction.
Even if it is not used much nowadays, the Intel assembly language is old. Remember that the original 8086 and 8088 processors are from the 1970's...
Once upon a time, when we still wrote in assembly for things like IBM PC/XT it made a lot of sense to have several instructions like
CMP AX, BX
JE Somewhere
or
AND AX, BX
JZ somewhere_else
That they happened to map to the same hardware instruction isn't important.
While not the most widely used programming language today, it is still used. g++ can compile assembly code. If you know what you are doing then it gives you a definite speed advantage.
In regards to your question, Yes your are right. Depending upon the circumstances it helps to think one way or another that leads to different instructions having the same opcode.
