From: Frank Kotler on
//\\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

"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
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

"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


> 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


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10 11 12
Prev: NASM HelloWorld - DOS
Next: ELF loading