On Thu, Jul 28, 2022 at 3:37 AM Jeroen Massar <jer...@massar.ch> wrote: > > > > > On 28 Jul 2022, at 04:18, Daniel Dickman <didick...@gmail.com> wrote: > > > > The diff below removes support for 386SX/DX processors. We already claim > > we don't support anything older than a Pentium so there's no point to keep > > this code. > [..] > > ok? > > I personally would not touch the .h definitions: > > > > > Index: i386/include/cputypes.h > > [..] > > > > -#define CPUCLASS_386 0 > > #define CPUCLASS_486 1 > > #define CPUCLASS_586 2 > > #define CPUCLASS_686 3 > > @@ -42,8 +41,6 @@ > > * that might not have a cpuid instruction. > > */ > > > > -#define CPU_386SX 0 /* Intel 80386SX */ > > -#define CPU_386 1 /* Intel 80386DX */ > > #define CPU_486SX 2 /* Intel 80486SX */ > > #define CPU_486 3 /* Intel 80486DX */ > > #define CPU_486DLC 4 /* Cyrix 486DLC */ > > > This, so one still knows that these used to be defined for that purpose, and > not that they are possibly free to re-use. > > But more importantly, as there might be code using those definitions to > define including or excluding things. > > Though, one could argue for the include users that they should also be > stripping their code of this use and super special casing...
How much of a real problem is this? These defines are ONLY available on the i386 platform. Wouldn't you have to be doing something super unportable to begin with if you're using these defines for anything? > > One option is maybe to comment those definitions out, so that they still > exist and one knows what they where. > I can leave them in but I'd be interested to understand if this is a real problem or hypothetical. > Greets, > Jeroen >
