Comment Re:Don't be so hard on him... (Score 1) 323
Although you're correct about traps vs. interrupts, the reason I use the term "trap" is because the word "interrupt" is a much broader term. Most of the time, when we talk about interrupts, we're talking about some hardware device telling the CPU that it needs attention, rather than an application doing so. Thus, if you ask what an interrupt is, you'll probably get a very different answer from most programmers.
I'd expect anybody who has taken a basic OS course to have at least heard of traps and understand the basic concept at a high level—an application executes an instruction whose purpose is to tell the operating system to jump into the kernel and do something special. Anything beyond that is gravy. But if they stare at you looking confused, offer, "or you might also know it as an interrupt instruction".
As for JE... yes, you could ostensibly write code without ever checking to see if two values are equal, but it would likely involve very contrived, inefficient code (e.g. subtract the value, branch if zero, add it back). And if you don't recognize that jump or branch instructions typically start with J or B, and that EQ likely means "equal", chances are very good that you've never written a single line of assembly language for any major CPU architecture—not ARM, not MIPS, not i386/x86-64, not PPC, not even 6502.