where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: Wolfgang Kern on 16 Aug 2007 16:42 Matt wrote: >>>> If the CPU were to take an interrupt between >>>> mov cr0,eax >>>> and >>>> jmp 08h:clear_pipe >>>> could it return from the interrupt already in Protected mode? In other >>>> words, does the mov cr0,eax actually set protected mode and the >>>> following jump just clear the prefetch queue. >>> No, it probably wont even enter the correct IRQ-routine >>> because the IRQ itself loads CS:EIP. >> It most likely will enter the correct ISR (given properly set up GDT, >> IDT and the interrupt controller). But there will be #GP on IRET > > because of popping invalid CS from the stack. > > Could this be eliminated by using a 32 bit 'wrapper' function for the > interrupt, that places the correct value on the stack and JUMPS to the > interrupt code? > Matt > > > > >>> Or does the CPU remain in real mode until a far jump? > >> Yes "until CS become altered", ..the playground for BigReal. > > > > No, it does not remain in real mode until a far jump. The mode is > > already not real after PE is set to 1. I can agree to call this a > > transitive mode or gray mode or whatever, but it's definitely neither > > properly functioning real mode nor properly setup protected mode > > (potentially not yet properly functioning either). > > > > Alex > >
From: Wolfgang Kern on 16 Aug 2007 16:54 Matt wrote: >>>> If the CPU were to take an interrupt between >>>> mov cr0,eax >>>> and > >>> jmp 08h:clear_pipe > >>> could it return from the interrupt already in Protected mode? In other > >>> words, does the mov cr0,eax actually set protected mode and the > >>> following jump just clear the prefetch queue. > >> No, it probably wont even enter the correct IRQ-routine > >> because the IRQ itself loads CS:EIP. > > > > It most likely will enter the correct ISR (given properly set up GDT, > > IDT and the interrupt controller). But there will be #GP on IRET > > because of popping invalid CS from the stack. > > Could this be eliminated by using a 32 bit 'wrapper' function for the > interrupt, that places the correct value on the stack and JUMPS to the > interrupt code? Not sure what you mean by a wrapper function,... As far as I'm concerned with (always use Flat mem and all code runs PL=0) if any IRQ occures then it always (at any time) will be recognised and messaged to the kernals main idle (poll for HW/SW-events) loop. __ wolfgang
From: Wolfgang Kern on 16 Aug 2007 17:05 "James Harris" <james.harris.1(a)googlemail.com> schrieb im Newsbeitrag news:1187297427.625459.180540(a)g4g2000hsf.googlegroups.com... > On 16 Aug, 10:28, "Alexei A. Frounze" <alexfrun...(a)gmail.com> wrote: > ... > > No, it does not remain in real mode until a far jump. The mode is > > already not real after PE is set to 1. I can agree to call this a > > transitive mode or gray mode or whatever, but it's definitely neither > > properly functioning real mode nor properly setup protected mode > > (potentially not yet properly functioning either). > > I think it safest to say that this 'mode' is undefined (a word to > strike fear into the heart of an engineer) and may not be the same > across the processor family as it is strictly out of step with Intel's > documentation. I haven't checked AMD but to abbreviate Intel's > instructions (note the use of the word 'random'): > > -------- > 1. Software must guarantee that no exceptions or interrupts are > generated during the mode switching operation. > ... > 3. Execute a MOV CR0 instruction that sets the PE flag > 4. Immediately following the MOV CR0 instruction, execute a far JMP or > far CALL instruction. (This operation is typically a far jump or call > to the next instruction in the instruction stream.) > ... > Random failures can occur if other instructions exist between steps 3 > and 4 above. > ... > 9. After entering protected mode, the segment registers continue to > hold the contents they had in real-address mode. The JMP or CALL > instruction in step 4 > resets the CS register. Perform > > /one/ > > of the following operations to update the > contents of the remaining segment registers. > - Reload segment registers DS, SS, ES, FS, and GS. If the ES, FS, and/ > or GS registers are not going to be used, load them with a null > selector. > - Perform a JMP or CALL instruction to a new task, which automatically > resets the values of the segment registers and branches to a new code > segment. > > > Also, interestingly, regarding paging: > 6. If paging is enabled, the code for the MOV CR0 instruction and the > JMP or CALL > instruction must come > > /from/ > > a page that is identity mapped (that is, the linear address before the > jump is the same as the physical address after paging and protected > mode is enabled). The > > /target/ > > instruction for the JMP or CALL instruction does not need to be > identity mapped. > -------- > > Not sure why the address one jumps /from/ needs to be identity mapped. > Ours is not to question, just to obey. <g> Now guess how on an OS which doesnt use paging like KESYS would work on it. instructions like LIDT LGTD give you a fart on virtual/paged addresses ... But Yes, the way/reason of CPU designers is not part of our decisions how to use it, even some of us (HW-freaks) may understand the why. __ wolfgang
From: Wolfgang Kern on 16 Aug 2007 17:22 Matt wrote: [..] >> The way of how descriptor entries are merged together is really weird, >> but look at the bits in the above, the low three bits are just ignored >> by the CPU when accessing GDT- or LDT-entries, so it already got the >> table offset without further calculation needs. > this is why the GDT must be aligned to an 8 byte boundary. Right Matt, it's always good to have some conformation :) it helps newbees to trust in our notes and to avoid confusion.. __ wolfgang
From: Wolfgang Kern on 16 Aug 2007 17:37
Matt asked: .... >> ;bits16 yet >> 6a 20 push +20h >> 1f pop ds >> 66 67 a1 10 20 30 D8 mov eax,dword[D8302010h] >> I use things like this very rare, as I need the opposite more often, >> ie: calling true Realmode BIOS service from within PM32. >> This needs a full back and forward switch (VM86 is just too slow for me). > That's interesting. Are you saying that it is faster to switch back to > true real mode than to switch to VM86, or that it is too slow to RUN in > VM86? Yeah. I checked both and found that renounce of VM86 at all speeds up everything against true RM linked BIOS-calls by a factor 15..30. (one more time: "Sorry Alexei" VM86 is dead since long, at least for me). Ok, my OS and all 'my code' runs at PL=0, perhaps in any paranoid protected environment like windoze/LinDoNix, a slow VM86-task may not be recognised as a main time-eater anyway. __ wolfgang |