CareerCup

Well.. first of all, why would kernel need a floating point operation.
Secondly, if it ever requires, I don't see any hurdles in it specially if those operations are trivial and non-blocking.
Why would interrupt handler get blocked? Its just that it has to handle all possible errors/exceptions including unhandled one, and probably take care to save/restore FPU context.
The best alternative would be using 'software fp operations' through compilers - if one is not sure about restoring FPU state.

Any comments/suggestions anyone?

Hi Hope the below post about ISR is useful

The ISR code does not run in the normal task context. It has no task control block and all ISR's share a single stack. Because of these differences there are restrictions to the type of routines that can be used in the ISR.

ISR's should not invoke functions which may cause ``blocking'' of the caller. For example, semTake. malloc and free cannot be used because they call functions which may cause blocking and thus all creation and deletion functions are forbidden since they use malloc and free. An ISR must not perform I/O through the VxWorks I/O system. A call to a device driver may block the system if the caller needs to wait for the device. However, the VxWorks pipe driver has been designed to permit writes by interrupt service code.

The best way to print out messages from an ISR is to use the function logMsg or other functions provided by the library logLib. ISRs should not use floating point instructions since these registers are not saved on entry to the ISR. If floating point instructions are to be used the registers must be saved using the functions in fppALib. However, floating point operations are time intensive and should be avoided in ISRs.

You may or may not.
Any floating point operation is much expensive than a fixed point operation.( because it is more complicated to store it & manipulate).

The Many Operating Systems, when it switches from some running-process to run in interrupt context, saves all the registers values(of current running process) and restores them back later but does not save the floating point registers.

So if you perform a FP operation in the interrupt context, you may overwrite the FP registers and in the end restoring wrong FP values to the original process that was running.

I guess you cannot because, when there is a context switch and if it is a hardware context switch, then only the general purpose registers get stored in the hardware.

I guess the answer is on these lines. Do post your ideas!!

You can't tough FPU in ISR routine on x86 systems.
In x64 you can do that...

You can put print messages in the interrupt handler to print the struct reg arg and int # for debug purposes.
Usually the kernel doesn't do floating point computation and hence it doesn't save/restore the context of floating point regs (this is about the linux kernel on x86). There can be kernels which might do FP computations and they might need to save/restore FP regs and computations.

Interrupt operations only allow non blocking operations;
print statement is a nonblocking operation and floating point computation may not be.

Well.. first of all, why would kernel need a floating point operation.
Secondly, if it ever requires, I don't see any hurdles in it specially if those operations are trivial and non-blocking.
Why would interrupt handler get blocked? Its just that it has to handle all possible errors/exceptions including unhandled one, and probably take care to save/restore FPU context.
The best alternative would be using 'software fp operations' through compilers - if one is not sure about restoring FPU state.

Any comments/suggestions anyone?

Well.. first of all, why would kernel need a floating point operation.
Secondly, if it ever requires, I don't see any hurdles in it specially if those operations are trivial and non-blocking.
Why would interrupt handler get blocked? Its just that it has to handle all possible errors/exceptions including unhandled one, and probably take care to save/restore FPU context.
The best alternative would be using 'software fp operations' through compilers - if one is not sure about restoring FPU state.

Any comments/suggestions anyone?

You can do anykind of non blocking operation and non recurssive operation in the ISR. But make sure before doing any operation in the ISR, ISR Stack is not used. switch to System mode or Supervisor mode. and perform operations in the corresponding stack.

You can do anykind of non blocking operation and non recurssive operation in the ISR. But make sure before doing any operation in the ISR, ISR Stack is not used. switch to System mode or Supervisor mode. and perform operations in the corresponding stack.

The interrupt handler can not sleep because it is taking some other process's time. So, printing out message is not allowed in interrupt handler: the print operation might block.

Ah.. Sorry for those repeated posts... My browser just said some error.. on each of the tries..

which fucking browser you use? can u core dump it please? merci!!