4 ms·
I believe the point was that the software worked 100% correctly. Your point seems to be that the software should have been updated to support Intel CPUs when th
by j_s 14y ago
I believe the point was that the software worked 100% correctly. Your point seems to be that the software should have been updated to support Intel CPUs when they were released.
From my perspective, Intel implemented an instruction, differently. I do not know enough about the low-level details to know best practices when detecting features supported by processors, but if the existing software is told (or figures out) "Yeah, I can do that" by/with the processor, Intel must have expected every single program using the instruction to ship an update? Nice.
- mikeash 14y agoThis isn't "every single program", it's only OS system call code. My understanding is that code in the kernel sometimes needs adjustment for new CPUs, due to errata or just plain old changes.
- j_s 14y agoNice quote there; I said "every single program using the instruction".
- mikeash 14y agoSorry about that. Given that the code which uses the instruction is not a "program" per se but rather is found in OS kernels, I hope you can understand my confusion. How many x86-64 kernels existed and had to be changed at the time?
- j_s 14y agoNo worries! This whole issue is way lower-level than anything I deal with on a regular basis so the whole time I've been looking at it from the very general perspective, eg. 'a cpu instruction' rather than 'the specific cpu instruction used by operating systems to switch to user mode on 64-bit processors, originally implemented by AMD and later implemented by Intel in accordance to the spec but differing in implementation' as happened here.
- mikeash 14y agoMy understanding is that instructions which are only used by OS kernels tend to be a little less stable than those used by general-purpose user programs. However, this is not exactly my area of expertise.