How do we detect that cause of undefined instruction exception is due to a floating point instruction in Arm V7 ISA

Question

In ARMv7 ISA, how to determine that undefined instruction exception has occurred due to one of the floating point exceptions? Also I read that by default VFP units are disabled and when VFP instruction if used by an application for first time, then kernal will use the excpetion handling to enable the VFP unit and let the application continue. I suppose this exception will be undefined instruction exception. I understand undefined instruction could be due to other cases also. I did some reading on undef handler in document ARM DUI 0471C page 128 where it says

Examine the undefined instruction to see if it has to be emulated. This is similar to the way in which an SVC handler extracts the number of an SVC, but rather than extracting the bottom 24 bits, the emulator must extract bits [27:24]

If bits [27:24] = b1110 or b110x, the instruction is a coprocessor instruction

The bit field do not seem to give me acurate indication that instruction was a floating point instruction, for instance bit [27:24] of VADD =0010. So this method dose not seem like best method to figure out.

From what i read in ARM ARM I could use FPEXC.DEX bit to figure out it was a floating point instruction exception. But this is so after we enable VFP unit. I will need to do this check first thing in the undef handler. What is the most appropriate method to detect exception from floating point instruction?

Have another read of the subsequent bullet that you've missed out of your quote (about bits [8:11]) - in what way do you think catching instructions targeting the VFP coprocessors (10 and 11) not sufficient? — Notlikethat
@Notlikethat I read the second bullet. It asked to look [8:11]. I can see that VFP instruction have [101x] encoding. But need to look at [27:24] also right? bit [8:11] can be equal to [101x] for other instructions also i think. Bits [27:24] vary with VFP instructions. Is this the only way to do it or are there other way? — Gautam
So surely you just have two conditions to identify the two classes of coprocessor instructions, plus a further condition to check if they target a relevant coprocessor? By basic logic, if ((a || b) && c) then VFP else not VFP? — Notlikethat

user3124812 user3124812 · Accepted Answer · 2017-08-24T01:19:23

fpexc.en bit could be used for this purpose. The idea is simple

if VFP is disabled, make assumption that VFP instruction is a reason of this fault -> Enable VFP and try to execute the instruction again.
if VFP is enabled than there is indeed something really bad.

Handler looks pretty like this:

ctrl    .req    r0
push    {...}

vmrs    ctrl,   fpexc             // Check vfp status
tst     ctrl,   #(1 << 30)        // fpexc.en
bne     .L.undefinedHandler.die   // if vfp enabled -> there is another reason for this exception

// enable VFP and try again
ldr     ctrl,   =fpexc.en.mask              // enable vfp
vmsr    fpexc,  ctrl

// Reloading vfp state & d0-d31 regs
// some code is skipped here

pop     {...}
subs    pc,     lr,     #4  // return & try faulty instructions again

.L.undefinedHandler.die:
// F... really unknown instruction

Simply speaking instruction is executed twice with VFP disabled and VFP enabled. Valid VFP instruction will generate exception only once. Unknown instruction will generate exception twice. Pros: instruction parsing is redundant.

PS: A bit late, but might be useful for somebody :)

How do we detect that cause of undefined instruction exception is due to a floating point instruction in Arm V7 ISA

1 Answers