From: "Jeff V. Merkey" <jmerkey@timpanogas.org>
To: David Lang <david.lang@digitalinsight.com>
Cc: kernel@kvack.org, Martin Josefsson <gandalf@wlug.westbo.se>,
Tigran Aivazian <tigran@veritas.com>,
Anil kumar <anils_r@yahoo.com>,
linux-kernel@vger.kernel.org
Subject: Re: Installing kernel 2.4
Date: Tue, 07 Nov 2000 16:39:29 -0700 [thread overview]
Message-ID: <3A0892B1.81396527@timpanogas.org> (raw)
In-Reply-To: <Pine.LNX.4.21.0011071606490.8417-100000@dlang.diginsite.com>
David Lang wrote:
>
> Jeff, the problem is not detecting the CPU type at runtime, the problem is
> trying to re-compile the code to take advantage of that CPU at runtime.
>
> depending on what CPU you have the kernel (and compiler) can use different
> commands/opmizations/etc, if you want to do this on boot you have two
> options.
>
> 1. re-compile the kernel
>
> 2. change all the CPU specific places from inline code to function calls
> into a table that get changed at boot to point at the correct calls.
The macros would be a problem. Some of the options, like MTRR, should
be auto-detected.
Jeff
>
> doing #2 will cost you so much performance that you would be better off
> just compiling for a 386 and not going through the autodetect hassle in
> the first place.
>
> David Lang
>
> On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
>
> > Date: Tue, 07 Nov 2000 16:10:58 -0700
> > From: Jeff V. Merkey <jmerkey@timpanogas.org>
> > To: kernel@kvack.org
> > Cc: Martin Josefsson <gandalf@wlug.westbo.se>,
> > Tigran Aivazian <tigran@veritas.com>, Anil kumar <anils_r@yahoo.com>,
> > linux-kernel@vger.kernel.org
> > Subject: Re: Installing kernel 2.4
> >
> >
> > There are tests for all this in the feature flags for intel and
> > non-intel CPUs like AMD -- including MTRR settings. All of this could
> > be dynamic. Here's some code that does this, and it's similiar to
> > NetWare. It detexts CPU type, feature flags, special instructions,
> > etc. All of this on x86 could be dynamically detected.
> >
> > :-)
> >
> > ;*************************************************************************
> > ;
> > ; check current processor type and state
> > ;
> > ;*************************************************************************
> >
> > public DetectProcessorInformation
> > DetectProcessorInformation proc near
> >
> > mov ax, cs
> > mov ds, ax
> > mov es, ax
> >
> > pushf
> > call get_cpuid
> > call get_fpuid
> > call print
> > popf
> > ret
> >
> > DetectProcessorInformation endp
> >
> > get_cpuid proc near
> >
> > check_8086:
> >
> > pushf
> > pop ax
> > mov cx, ax
> > and ax, 0fffh
> > push ax
> > popf
> > pushf
> > pop ax
> > and ax, 0f000h
> > cmp ax, 0f000h ; flag bits 12-15 are always set on an 8086
> > mov CPU_TYPE, 0 ; 8086 detected
> > je end_get_cpuid
> >
> > check_80286:
> > or cx, 0f000h
> > push cx
> > popf
> > pushf
> > pop ax
> > and ax, 0f000h ; flag bits 12-15 are always clear on 80286 in
> > real mode
> > mov CPU_TYPE, 2 ; 80286 processor
> > jz end_get_cpuid
> >
> > check_80386:
> > mov bx, sp
> > and sp, not 3
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > mov cx, ax
> > OPND32 35h, 40000h
> > OPND32
> > push ax
> > OPND32
> > popf
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > xor ax, cx ; AC bit won't toggle, 80386 detected
> > mov sp, bx
> > mov CPU_TYPE, 3 ; 80386 detected
> > jz end_get_cpuid
> >
> > and sp, not 3
> > OPND32
> > push cx
> > OPND32
> > popf
> > mov sp, bx ; restore stack
> >
> >
> > check_80486:
> > mov CPU_TYPE, 4 ; default to 80486
> >
> > OPND32
> > mov ax, cx
> > OPND32 35h, 200000h ; xor ID bit
> > OPND32
> > push ax
> > OPND32
> > popf
> > OPND32
> > pushf
> > OPND32
> > pop ax
> > OPND32
> > xor ax, cx ; cant toggle ID bit
> > je end_get_cpuid
> >
> >
> > check_vendor:
> > mov ID_FLAG, 1
> > OPND32
> > xor ax, ax
> > CPUID
> > OPND32
> > mov word ptr VENDOR_ID, bx
> > OPND32
> > mov word ptr VENDOR_ID[+4], dx
> > OPND32
> > mov word ptr VENDOR_ID[+8], cx
> > mov si, offset VENDOR_ID
> > mov di, offset intel_id
> > mov cx, length intel_id
> >
> > compare:
> > repe cmpsb
> > or cx, cx
> > jnz end_get_cpuid
> >
> > intel_processor:
> > mov INTEL_PROC, 1
> >
> > cpuid_data:
> > OPND32
> > cmp ax, 1
> >
> > jl end_get_cpuid
> > OPND32
> > xor ax, ax
> > OPND32
> > inc ax
> > CPUID
> > mov byte ptr ds:STEPPING, al
> > and STEPPING, STEPPING_MASK
> >
> > and al, MODEL_MASK
> > shr al, MODEL_SHIFT
> > mov byte ptr ds:CPU_MODEL, al
> >
> > and ax, FAMILY_MASK
> > shr ax, FAMILY_SHIFT
> > mov byte ptr ds:CPU_TYPE, al
> >
> > mov dword ptr FEATURE_FLAGS, edx
> >
> > end_get_cpuid:
> > ret
> >
> > get_cpuid endp
> >
> >
> > get_fpuid proc near
> >
> > fninit
> > mov word ptr ds:FP_STATUS, 5a5ah
> >
> > fnstsw word ptr ds:FP_STATUS
> > mov ax, word ptr ds:FP_STATUS
> > cmp al, 0
> >
> > mov FPU_TYPE, 0
> > jne end_get_fpuid
> >
> > check_control_word:
> > fnstcw word ptr ds:FP_STATUS
> > mov ax, word ptr ds:FP_STATUS
> > and ax, 103fh
> > cmp ax, 3fh
> >
> > mov FPU_TYPE, 0
> > jne end_get_fpuid
> > mov FPU_TYPE, 1
> >
> >
> > check_infinity:
> > cmp CPU_TYPE, 3
> > jne end_get_fpuid
> > fld1
> > fldz
> > fdiv
> > fld st
> > fchs
> > fcompp
> > fstsw word ptr ds:FP_STATUS
> > mov ax, word ptr ds:FP_STATUS
> > mov FPU_TYPE, 2
> >
> > sahf
> > jz end_get_fpuid
> > mov FPU_TYPE, 3
> > end_get_fpuid:
> > ret
> > get_fpuid endp
> >
> >
> >
> > print proc near
> > cmp ID_FLAG, 1
> > je print_cpuid_data
> >
> > if (VERBOSE)
> > mov dx, offset id_msg
> > call OutputMessage
> > endif
> >
> > print_86:
> > cmp CPU_TYPE, 0
> > jne print_286
> >
> > if (VERBOSE)
> > mov dx, offset c8086
> > call OutputMessage
> > endif
> > cmp FPU_TYPE, 0
> > je end_print
> >
> > if (VERBOSE)
> > mov dx, offset fp_8087
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_286:
> > cmp CPU_TYPE, 2
> > jne print_386
> > if (VERBOSE)
> > mov dx, offset c286
> > call OutputMessage
> > endif
> > cmp FPU_TYPE, 0
> > je end_print
> > if (VERBOSE)
> > mov dx, offset fp_80287
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_386:
> > cmp CPU_TYPE, 3
> > jne print_486
> > if (VERBOSE)
> > mov dx, offset c386
> > call OutputMessage
> > endif
> > cmp FPU_TYPE, 0
> > je end_print
> > cmp FPU_TYPE, 2
> > jne print_387
> > if (VERBOSE)
> > mov dx, offset fp_80287
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_387:
> > if (VERBOSE)
> > mov dx, offset fp_80387
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_486:
> > cmp FPU_TYPE, 0
> > je print_Intel486sx
> > if (VERBOSE)
> > mov dx, offset c486
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_Intel486sx:
> > if (VERBOSE)
> > mov dx, offset c486nfp
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > print_cpuid_data:
> >
> > cmp_vendor:
> > cmp INTEL_PROC, 1
> > jne not_GenuineIntel
> >
> > cmp CPU_TYPE, 4
> > jne check_Pentium
> > if (VERBOSE)
> > mov dx, offset Intel486_msg
> > call OutputMessage
> > endif
> > jmp print_family
> >
> > check_Pentium:
> > cmp CPU_TYPE, 5
> > jne check_PentiumPro
> > if (VERBOSE)
> > mov dx, offset Pentium_msg
> > call OutputMessage
> > endif
> > jmp print_family
> >
> > check_PentiumPro:
> > cmp CPU_TYPE, 6
> > jne print_features
> > if (VERBOSE)
> > mov dx, offset PentiumPro_msg
> > call OutputMessage
> > endif
> >
> > print_family:
> >
> > IF VERBOSE
> > mov dx, offset family_msg
> > call OutputMessage
> > ENDIF
> >
> > mov al, byte ptr ds:CPU_TYPE
> > mov byte ptr dataCR, al
> > add byte ptr dataCR, 30h
> >
> > IF VERBOSE
> > mov dx, offset dataCR
> > call OutputMessage
> > ENDIF
> >
> > print_model:
> >
> > IF VERBOSE
> > mov dx, offset model_msg
> > call OutputMessage
> > ENDIF
> >
> > mov al, byte ptr ds:CPU_MODEL
> > mov byte ptr dataCR, al
> > add byte ptr dataCR, 30h
> >
> > IF VERBOSE
> > mov dx, offset dataCR
> > call OutputMessage
> > ENDIF
> >
> > print_features:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > and ax, FPU_FLAG
> > jz check_mce
> >
> > if (VERBOSE)
> > mov dx, offset fpu_msg
> > call OutputMessage
> > ENDIF
> >
> > check_mce:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > and ax, MCE_FLAG
> > jz check_wc
> >
> > IF VERBOSE
> > mov dx, offset mce_msg
> > call OutputMessage
> > ENDIF
> >
> > check_CMPXCHG8B:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > and ax, CMPXCHG8B_FLAG
> > jz check_4MB_paging
> >
> > IF VERBOSE
> > mov dx, offset cmp_msg
> > call OutputMessage
> > ENDIF
> >
> > chekc_io_break:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > test ax, 4
> > jz check_4MB_paging
> >
> > IF VERBOSE
> > mov dx, offset io_break_msg
> > call OutputMessage
> > ENDIF
> >
> > ; Enable Debugging Extensions bit in CR4
> > CR4_TO_ECX
> > or ecx, 08h
> > ECX_TO_CR4
> >
> > if (VERBOSE)
> > mov dx, offset io_break_enable
> > call OutputMessage
> > endif
> >
> > check_4MB_paging:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > test ax, 08h
> > jz check_PageExtend
> >
> > IF VERBOSE
> > mov dx, offset page_4MB_msg
> > call OutputMessage
> > ENDIF
> >
> > ; Enable page size extension bit in CR4
> > CR4_TO_ECX
> > or ecx, 10h
> > ECX_TO_CR4
> >
> > if (VERBOSE)
> > mov dx, offset p4mb_enable
> > call OutputMessage
> > endif
> >
> > check_PageExtend:
> > mov ax, word ptr ds:FEATURE_FLAGS
> > test ax, 40h
> > jz check_wc
> >
> > ;; DEBUG DEBUG DEBUG !!!
> > ; Enable page address extension bit in CR4
> >
> > ;; CR4_TO_ECX
> > ;; or ecx, 20h
> > ;; ECX_TO_CR4
> >
> > check_wc:
> > mov dx, word ptr ds:FEATURE_FLAGS
> > test dx, 1000h ; MTRR support flag
> > jz end_print
> >
> > if (VERBOSE)
> > mov dx, offset wc_enable
> > call OutputMessage
> > endif
> > jmp end_print
> >
> > not_GenuineIntel:
> > if (VERBOSE)
> > mov dx, offset not_Intel
> > call OutputMessage
> > endif
> >
> > end_print:
> > ret
> > print endp
> >
> >
> > kernel@kvack.org wrote:
> > >
> > > On Tue, 7 Nov 2000, Jeff V. Merkey wrote:
> > >
> > > > So how come NetWare and NT can detect this at run time, and we have to
> > > > use a .config option to specifiy it? Come on guys.....
> > >
> > > Then run a kernel compiled for i386 and suffer the poorer code quality
> > > that comes with not using newer instructions and including the
> > > workarounds for ancient hardware.
> > >
> > > -ben
> > >
> > > -
> > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > > the body of a message to majordomo@vger.kernel.org
> > > Please read the FAQ at http://www.tux.org/lkml/
> > -
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > Please read the FAQ at http://www.tux.org/lkml/
> >
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-07 23:47 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-07 20:52 Installing kernel 2.4 Anil kumar
2000-11-07 20:59 ` Jeff V. Merkey
2000-11-07 21:39 ` Tigran Aivazian
2000-11-07 22:28 ` Martin Josefsson
2000-11-07 22:32 ` Jeff V. Merkey
2000-11-07 22:51 ` kernel
2000-11-07 23:10 ` Jeff V. Merkey
2000-11-07 23:57 ` Jeff Garzik
2000-11-08 0:01 ` Jeff V. Merkey
2000-11-08 0:10 ` Jeff Garzik
2000-11-08 0:12 ` Jeff V. Merkey
2000-12-10 8:22 ` Mark W. McClelland
2000-11-09 13:40 ` Alan Cox
2000-11-08 2:18 ` H. Peter Anvin
2000-11-08 7:35 ` Jeff V. Merkey
2000-11-08 0:54 ` Alan Cox
2000-11-08 3:31 ` Matthew Kirkwood
2000-11-08 0:11 ` David Lang
2000-11-07 23:39 ` Jeff V. Merkey [this message]
2000-11-07 23:51 ` Sven Koch
2000-11-07 23:59 ` Jeff Garzik
2000-11-08 0:18 ` David Relson
2000-11-08 0:23 ` Jeff V. Merkey
2000-11-08 0:50 ` Jeff Garzik
2000-11-08 0:52 ` Jeff V. Merkey
2000-11-08 0:49 ` Alan Cox
2000-11-08 0:47 ` Jeff V. Merkey
2000-11-08 0:57 ` Alan Cox
2000-11-08 0:54 ` Jeff V. Merkey
2000-11-07 22:52 ` J . A . Magallon
2000-11-07 22:54 ` J Sloan
-- strict thread matches above, loose matches on Subject: below --
2000-11-07 22:49 Bruce_Holzrichter
2000-11-07 23:24 davej
2000-11-07 23:37 ` Jeff V. Merkey
2000-11-07 23:47 ` Jeff V. Merkey
2000-11-07 23:59 ` Jeff V. Merkey
2000-11-08 0:51 ` David Lang
2000-11-08 0:10 ` Jeff V. Merkey
2000-11-08 3:39 ` davej
2000-11-08 4:41 ` Jeff V. Merkey
2000-11-08 3:57 ` davej
2000-11-08 12:05 ` Horst von Brand
2000-11-08 15:29 ` Eric W. Biederman
2000-11-08 16:51 ` James A. Sutherland
2000-11-08 17:36 ` George Anzinger
2000-11-08 19:43 ` James A. Sutherland
2000-11-08 20:32 ` George Anzinger
2000-11-08 22:01 ` James A. Sutherland
2000-11-09 13:25 ` David Woodhouse
2000-11-09 18:24 ` James A. Sutherland
2000-11-08 3:30 ` davej
2000-11-08 0:03 ` Jeff Garzik
2000-11-08 0:06 ` Jeff V. Merkey
2000-11-08 3:25 ` davej
2000-11-08 4:36 ` Jeff V. Merkey
2000-11-08 3:50 ` davej
2000-11-08 2:19 Marty Fouts
2000-11-08 2:25 Marty Fouts
2000-11-08 3:43 ` davej
2000-11-08 13:43 Jesse Pollard
2000-11-08 18:52 ` Jeff V. Merkey
2000-11-08 13:49 Bruce_Holzrichter
2000-11-08 15:10 ` davej
2000-11-08 19:16 ` Jeff V. Merkey
2000-11-08 19:19 David Feuer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A0892B1.81396527@timpanogas.org \
--to=jmerkey@timpanogas.org \
--cc=anils_r@yahoo.com \
--cc=david.lang@digitalinsight.com \
--cc=gandalf@wlug.westbo.se \
--cc=kernel@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tigran@veritas.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.