where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: Frank Kotler on 13 Aug 2007 06:10 //\\o//\\annabee wrote: > P� Mon, 13 Aug 2007 09:54:22 +0100, skrev Frank Kotler > <fbkotler(a)verizon.net>: > >> Well... the latter is correct. While you may be in "protected mode" >> after setting cr0, it's a bit in the descriptor loaded into cs that >> puts the CPU into 32-bit mode... so you're still in 16-bit mode until >> cs is loaded by the far jump. (I *think* that's the explanation...) > > > http://www.youtube.com/watch?v=cxzs46Nxohk&playnext=1 > > Whats this talk about NAU Frank. Do you know? No. Political yak-yak of no import whatsoever, AFAIK. They may set the bit in cr0, but they ain't going to make the jump. (any time soon...) Possibly an attempt to frighten EU countries into giving up more of their sovereignty(???). I really don't know... Best, Frank
From: Rod Pemberton on 13 Aug 2007 07:03 "Frank Kotler" <fbkotler(a)verizon.net> wrote in message news:WWVvi.1161$Gz4.57(a)trndny05... > Rod Pemberton wrote: > > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > > news:2%Uvi.1429$hK5.87(a)trndny02... > > > >>opexoc(a)gmail.com wrote: > >> > >>>Hello, > >>> > >>>look at some piece of code which is to be booted by BIOS at startup > >>>and enter CPU into protected mode: > >>> > >>> 1[BITS 16] ; We need 16-bit intructions for Real mode > >>> 2 > >>> 3 [ORG 0x7C00] ; The BIOS loads the boot sector into memory > >>>location 0x7C00 4 > >>> 5 cli ; Disable interrupts, we want to > >>>be alone > >>> 6 > >>> 7 xor ax, ax > >>> 8 mov ds, ax ; Set DS-register to 0 - used by > >>>lgdt > >>> 9 > >>> 10 lgdt [gdt_desc] ; Load the GDT descriptor > >>> 11 > >>> 12 mov eax, cr0 ; Copy the contents of CR0 into > >>>EAX > >>> 13 or eax, 1 ; Set bit 0 > >>> 14 mov cr0, eax > >>> 15 ; Copy the contents of EAX into > >>>CR0 > >>> 16 ;[BITS 32] > >>> 17 jmp 08h:clear_pipe ; Jump to code segment, offset > >>>clear_pipe > >>> 18 [BITS 32] > >>> 19 clear_pipe: > >>> 20 mov ax, 10h ; Save data segment identifyer > >>> 21 mov ds, ax > >>> > >>>In which location directive [BITS 32] should appear ( first or > >>>second )? When I use first location then computer hang on and doesn't > >>>execute properly code in clear_pipe. When I change first bit in cr0 > >>>register then I enter into protected mode so I should use 32 bit > >>>instruction. Despite of this fact only when I use second directive > >>>[BITS 32] ( without first ) everything works ok. > >> > >>Well... the latter is correct. While you may be in "protected mode" > >>after setting cr0, it's a bit in the descriptor loaded into cs that puts > >>the CPU into 32-bit mode... so you're still in 16-bit mode until cs is > >>loaded by the far jump. (I *think* that's the explanation...) > >> > > > > > > Or is it, > > 1) setting cr0 bit 0 (PE) allows switching into protected mode, but doesn't > > do the switch > > 2) reloading CS with a selector instead of a segment actually does the > > switch into protected mode > > 3) the bit in the descriptor decides if it's 32-bit or 16-bit protected mode > > Yeah, that's probably a better way to put it. In any case, we're not in > 32-bit mode until after the jump. > Yeah, but if he wanted the jump in BITS32 he should be able to put an operand size override prefix, o16, right? Like so: [BITS 32] o16 jmp 08h:clear_pipe ; Jump to code segment, offset clear_pipe: mov ax, 10h ; Save data segment identifyer mov ds, ax Rod Pemberton
From: Alexei A. Frounze on 13 Aug 2007 07:02 On Aug 13, 2:32 am, "Rod Pemberton" <do_not_h...(a)nowhere.cmm> wrote: > "Frank Kotler" <fbkot...(a)verizon.net> wrote in message > > news:2%Uvi.1429$hK5.87(a)trndny02... > > > > > ope...(a)gmail.com wrote: > > > Hello, > > > > look at some piece of code which is to be booted by BIOS at startup > > > and enter CPU into protected mode: > > > > 1[BITS 16] ; We need 16-bit intructions for Real mode > > > 2 > > > 3 [ORG 0x7C00] ; The BIOS loads the boot sector into memory > > > location 0x7C00 4 > > > 5 cli ; Disable interrupts, we want to > > > be alone > > > 6 > > > 7 xor ax, ax > > > 8 mov ds, ax ; Set DS-register to 0 - used by > > > lgdt > > > 9 > > > 10 lgdt [gdt_desc] ; Load the GDT descriptor > > > 11 > > > 12 mov eax, cr0 ; Copy the contents of CR0 into > > > EAX > > > 13 or eax, 1 ; Set bit 0 > > > 14 mov cr0, eax > > > 15 ; Copy the contents of EAX into > > > CR0 > > > 16 ;[BITS 32] > > > 17 jmp 08h:clear_pipe ; Jump to code segment, offset > > > clear_pipe > > > 18 [BITS 32] > > > 19 clear_pipe: > > > 20 mov ax, 10h ; Save data segment identifyer > > > 21 mov ds, ax > > > > In which location directive [BITS 32] should appear ( first or > > > second )? When I use first location then computer hang on and doesn't > > > execute properly code in clear_pipe. When I change first bit in cr0 > > > register then I enter into protected mode so I should use 32 bit > > > instruction. Despite of this fact only when I use second directive > > > [BITS 32] ( without first ) everything works ok. > > > Well... the latter is correct. While you may be in "protected mode" > > after setting cr0, it's a bit in the descriptor loaded into cs that puts > > the CPU into 32-bit mode... so you're still in 16-bit mode until cs is > > loaded by the far jump. (I *think* that's the explanation...) > > Or is it, > 1) setting cr0 bit 0 (PE) allows switching into protected mode, but doesn't > do the switch It (maybe along with the following near/far jump) does switch, but the CPU state isn't completely valid for protected mode yet. > 2) reloading CS with a selector instead of a segment actually does the > switch into protected mode And this is what makes the state more valid. > 3) the bit in the descriptor decides if it's 32-bit or 16-bit protected mode Correct. Alex
From: Rod Pemberton on 13 Aug 2007 07:13 "Rod Pemberton" <do_not_have(a)nowhere.cmm> wrote in message news:f9pdnk$nje$1(a)aioe.org... > > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > news:WWVvi.1161$Gz4.57(a)trndny05... > > Rod Pemberton wrote: > > > "Frank Kotler" <fbkotler(a)verizon.net> wrote in message > > > news:2%Uvi.1429$hK5.87(a)trndny02... > > > > > >>opexoc(a)gmail.com wrote: > > >> > > >>>Hello, > > >>> > > >>>look at some piece of code which is to be booted by BIOS at startup > > >>>and enter CPU into protected mode: > > >>> > > >>> 1[BITS 16] ; We need 16-bit intructions for Real mode > > >>> 2 > > >>> 3 [ORG 0x7C00] ; The BIOS loads the boot sector into memory > > >>>location 0x7C00 4 > > >>> 5 cli ; Disable interrupts, we want to > > >>>be alone > > >>> 6 > > >>> 7 xor ax, ax > > >>> 8 mov ds, ax ; Set DS-register to 0 - used by > > >>>lgdt > > >>> 9 > > >>> 10 lgdt [gdt_desc] ; Load the GDT descriptor > > >>> 11 > > >>> 12 mov eax, cr0 ; Copy the contents of CR0 into > > >>>EAX > > >>> 13 or eax, 1 ; Set bit 0 > > >>> 14 mov cr0, eax > > >>> 15 ; Copy the contents of EAX into > > >>>CR0 > > >>> 16 ;[BITS 32] > > >>> 17 jmp 08h:clear_pipe ; Jump to code segment, offset > > >>>clear_pipe > > >>> 18 [BITS 32] > > >>> 19 clear_pipe: > > >>> 20 mov ax, 10h ; Save data segment identifyer > > >>> 21 mov ds, ax > > >>> > > >>>In which location directive [BITS 32] should appear ( first or > > >>>second )? When I use first location then computer hang on and doesn't > > >>>execute properly code in clear_pipe. When I change first bit in cr0 > > >>>register then I enter into protected mode so I should use 32 bit > > >>>instruction. Despite of this fact only when I use second directive > > >>>[BITS 32] ( without first ) everything works ok. > > >> > > >>Well... the latter is correct. While you may be in "protected mode" > > >>after setting cr0, it's a bit in the descriptor loaded into cs that puts > > >>the CPU into 32-bit mode... so you're still in 16-bit mode until cs is > > >>loaded by the far jump. (I *think* that's the explanation...) > > >> > > > > > > > > > Or is it, > > > 1) setting cr0 bit 0 (PE) allows switching into protected mode, but > doesn't > > > do the switch > > > 2) reloading CS with a selector instead of a segment actually does the > > > switch into protected mode > > > 3) the bit in the descriptor decides if it's 32-bit or 16-bit protected > mode > > > > Yeah, that's probably a better way to put it. In any case, we're not in > > 32-bit mode until after the jump. > > > > Yeah, but if he wanted the jump in BITS32 he should be able to put an > operand size override prefix, o16, right? Like so: > > [BITS 32] > o16 jmp 08h:clear_pipe ; Jump to code segment, offset > clear_pipe: > mov ax, 10h ; Save data segment identifyer > mov ds, ax > Actually, just as an FYI, I'm using an 'o32 retf' in a 'BITS 16' section. The retf instruction will allow you to use CS:EIP values you can't use in a jmp and let's you use computed CS:EIP values. Also, although I don't see much NASM code without the brackets, technically you should be using BITS 32 or BITS 16 without brackets. Rod Pemberton
From: CodeMonk on 13 Aug 2007 09:09
> No. Political yak-yak of no import whatsoever, AFAIK. They may set the > bit in cr0, but they ain't going to make the jump. (any time soon...) It does at least illustrate that their are some real Americans, even in the GOP. If they (the NWO pundits) do make the jump, then the curious part will be whether the first instruction encountered at CS:EIP is HALT or not. It seems I remember that Nancy did consult astrologers to provide recommendations to her hubby Ronny. Now who else did that, oh yea, Hitler. It seems the GOP has a battle within - the question is, who will win? - Scott |