Date: Mon, 24 Feb 1997 17:06:46 +1100 From: Bruce Evans <bde@zeta.org.au> To: dpb@kafka.hqs.crc.com, syssgm@devetir.qld.gov.au Cc: freebsd-bugs@freebsd.org Subject: Re: kern/2787: Cyrix 150+ CPU is seen as a 486, Kernels made for i586 don't recognize the chip as 586. Message-ID: <199702240606.RAA24906@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>At boot time, Freebsd sees the Cyrix 150+ (120Mhz) as a 486 instead of a >>Pentium 120. When I build a kernel with the i586 option, it fails >>to boot, the error "unrecognized cpu" so I must re-make the kernel with >>the i486 option instead - and loose performance. > >A Cyrix 686 has none of the Pentium features that I586_CPU selects. From >an instruction set perspective it is a 486. But it plugs into a Pentium >socket. Run it with I486_CPU defined. That is your only option. Kato Takenori (the chief pc98 committer) has a lot of changes for better Cyrix identification. The 6x86 is still a 486, but it is identified and some of its features are enabled. Some more of its features can be enabled using compile-time options. >Basically, the CPU naming game is pretty complex now, and is likely to get >worse when Cyrix releases the M2 and Intel releases Klamath. It seems to >me that I386_CPU and I486_CPU were good names, but I586_CPU and I686_CPU are >not. We could replace them all with: CPU_386, CPU_486, CPU_PENTIUM, >CPU_PENTIUM_PRO, CPU_CYRIX_M1, etc. Or we could conditionalise on the >feature bits (and probably add some more of our own), without relying much >on the actual CPU type. With MMX (and maybe other stuff) it looks like you >have to anyway. Even I[5-6]86_CPU vs the rest require messy code with ifdefs for the features and runtime tests to check the actual cpu_class. I486_CPU isn't so good either, since non-Intel 486's sometimes have i586 features including a cpuid instruction to tell you which features they have. I think we should conditionalize on the features classified by cpuid to begin with. Many of the ifdefs would have to go away. This is good provided the runtime cost is tiny. >PS Umm, how does one close a PR? Or re-label it as a handbook/doc PR? Run `edit-pr <number>' and change the relevant words (often simply change "open" to "closed"). Save the file, quit the editor, then write something for a log entry. The log entry gets mailed. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702240606.RAA24906>