Emulator Trap

Depends on	Exceptions

A processor may throw a hardware exception when it tries to execute an instruction it doesn’t recognise. This can occur if:

• the code was compiled for a later version of the processor with new instructions
• the executing processor is a ‘budget’ implementation (e.g. it is a floating-point instruction but this processor lacks a floating-point processing unit)
• the programmer is trying something a bit unorthodox
• the application has crashed and this isn’t really code

In all these cases it is useful to be able to take some action. In the last case the action is liable to be terminating the process; in the other cases it can be possible to provide a service and return.

The service can be executing a model of the instruction in software. This enables old hardware processors to run newer code by adding software upgrades to the models; it allows cheaper silicon to emulate the same code as the ‘full’ versions, and so forth.

Providing this as part of the operating system means that individual applications do not need to care about the particular hardware, even if it might be a bit out of date. In effect the OS is fulfilling a bit more of the traditional hardware role.

Of course, software models can be quite a bit slower than the hardware ought to be.

---

‘Advanced’ bit!

Another use of this form of trap is to deliberately disable certain instruction classes to see if they are used by the running program. This is the same principle as may be used (for example) to detect writes to valid memory pages: see here for an illustration of that.

The principle is:

• switch something off
• see if anyone complains
  • if someone does then it was in use and turn it back on
  • if no one does then we no it didn’t get changed

This can be used to facilitate partial context switching.

---

Context Dependencies Dependants

Max. number:

Max. distance:

Next

Articles on Exceptions

Boot • Emulator traps • Errors • Exceptions • Interrupt Controller • Interrupt Service Routines (ISRs) • Interrupts • Memory Fault • Reset • Software Exceptions • System Calls

Articles on User

"Everything is a File" • Application Binary Interface (ABI) • Arrays • Boot • Buffer Overflow • Containers • Daemons • Disk Partition • Dynamic Memory Allocation • Emulator traps • Environment Variables • Errors • Exceptions • File Attributes • File Locking • File Permissions • Introduction to Operating Systems • Journalling File System • Links • Locks • Man(ual pages in Unix) • Memory Mapped Files • Monitoring • Network File System (NFS) • PATH • Pipes • Pointers • Relocatable Code • Reset • SETUID • Shell • Sockets • Spooling and Buffering • Streams • Structures • Superuser • System Calls • Unix Signals • User • Using Peripherals