So the question is:

Assume we had 15 CPU instructions and, for each instruction, we were trusting one particular component of the kernel to handle it. How many modes do we need to support (including the user mode), and how many bits we had to use to represent these modes? What is an advantage and a disadvantage of using this scheme instead of the kernel/user mode scheme, where one kernel component is trusted to handle all 15 instructions?

Is it 16 modes (1 kernel mode for each component, then the 1 user mode) or is it just the regular 2 modes?

Would it be 4 or 1 bit(s) for 16 modes or 2 modes respectively?

I want to say an advantage are that 15 components would be more powerful, but I feel like I should be able to explain more. I think a disadvantage would be power and memory allocation.

Is that somewhat in the right direction?


1 Answer 1


for each instruction, we were trusting one particular component of the kernel to handle it

This seems to represent a misunderstanding of how code is executed. That's not how CPUs work. Instructions are executed by the CPU -- not handled by the kernel. So, the question seems to be based on a faulty premise.

(OK, there are sometimes occasional exceptions to this in real-world architectures -- e.g., in old x86 platforms, some floating-point instructions might be emulated by the kernel when running on a CPU that didn't have floating-point support -- but that's a detail. Treat what I've described above as the basic rule.)

  • $\begingroup$ I suspect that “instruction” is a mistranslation. The question almost makes sense if you read “system call” instead. $\endgroup$ Commented Jul 12, 2016 at 12:35
  • 2
    $\begingroup$ I think such kernel-executed instructions exist on most architectures — many architectures have variants where some instructions are not available — but such features don't exist at the processor architecture level, only at the assembly instruction level. The way that works is that the instruction that is to be performed by the kernel triggers an illegal instruction trap; the kernel handles that trap by looking at the opcode, decides that it wants to implement the instruction rather than (typically) crash the process, and treats the instruction basically like a system call. $\endgroup$ Commented Jul 12, 2016 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.