On Tue, 9 Apr 2002, Jun Sun wrote: > How about "there will be likely no such CPUs/systems in the future"? Does it mean code needs to be dirty? There is no performance hit for new CPUs and the code bloat is minimal and even that is discarded after boot. > Your patch will force every new CPU to add FPUEX option to the cpu_option, > where apparently no place really need to use it. Well, I agree to some extent here. I may negate the flag, so it's not needed for most CPUs. > Leaving FPU exception enabled for a CPU that does not generate FPU exception > is acceptable. (because it does *not* generate FPU exceptions). And hooking You never know. You may get one due to a hardware fault. It's better to trap it and panic then, than to try to pretend nothing special happened. > up/dispatching the FPU exception interrupt is system-specific already anyway. But pretty generic -- you just need to grab the right IRQ line. See the top of decstation_handle_int in arch/mips/dec/int-handler.S -- nothing system-specific until after the FPU path branch. You may cut and paste it for any other system. > It, however, makes sense to provide a common wrapper code for fpu interrupt to > jump to fpu exception handling code. No additional code is actually generated -- only a label for a second entry point is added. > Over-abstraction can make the picture cloudy rather than clear. My 2 cents. I appreciate your point of view. You haven't convinced me, though. Apart from the negation of MIPS_CPU_FPUEX, which sounds reasonable indeed. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
