> Date: Sat, 20 Jun 2020 18:52:03 -0700 > From: Erik Fair <f...@netbsd.org> > > Back in the day, these additional (potentially optional) computation > units (e.g., FPU, GPU, vector engine(s)) were generically referred > to as "co-processors" as a class.
Only units that are normally accessible through ordinary CPU instructions by user processes but prohibited in the kernel, with registers that must be preserved across context switches according to the architecture's ABI, are in scope in this proposal. Thus, for example, the Intel x87 floating-point unit, the Intel SSE FP/vector unit, the ARM VFP or NEON units, and the PowerPC FPU and Altivec unit are all in scope; GPUs, FPGAs, crypto decelerator devices on the PCI bus, and Cell SPEs are nowhere near the scope. I considered `fpu', `simd', `vector', and `vfp'. `vfp' is a specific family of floating-point vector units in the ARM world, so that would be confusing in an ARM context where it would also apply to NEON or the AArch64 SIMD/FP unit. Neither `simd' nor `vector' applies to the x87, and `fpu' doesn't apply to the MIPS DSP, but `fpu' struck me as more recognizable and distinct -- for instance, we also have interrupt `vectors' and operations `vectors' in the kernel which are unrelated. I'm open to other naming suggestions but I'm deliberately keeping the scope narrow and grounded by specific needs.
