where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: Ciaran Keating on 17 Aug 2007 00:42 On Fri, 17 Aug 2007 07:16:48 +1000, Wolfgang Kern <nowhere(a)never.at> wrote: > btw: "readed"(sic) doesn't exist in English, use "read" in 'all time' > forms. But pronounced like "red". -- Ciaran Keating Amadan Technologies
From: Bx.C / x87asm on 17 Aug 2007 04:09 > 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. for the same reason that you have to disable interrupts before the pmode bit is set.... the moment you make a change to CR0, the processor instantly starts acting appropriately to the change... when you set the pmode bit, the processor is now in protected mode, so you have to make sure your GDT is set up, reload CS for the descriptor to update, and set up appropriate IDT for protected mode before enabling interrupts... ....likewise, the moment the paging bit is set, you have to make sure you have all appropriate tables set up and that the code you are working from is identity mapped... once paging has been enabled via setting the bit in CR0, instruction fetches are run through the paging tables to find the correct physical address that cooresponds to the linear address pointed to by CS:EIP.... anyone want to run a test to see if the prefetch queue can safely shield you from a non-identity mapped instruction?
From: Alexei A. Frounze on 17 Aug 2007 05:14 On Aug 16, 10:56 am, Matt <travellingmatt2...(a)yahoo.co.uk> wrote: > Wolfgang Kern 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. Wrong, it must not (not in non-64-bit mode, at least). Alex
From: Alexei A. Frounze on 17 Aug 2007 05:22 On Aug 16, 10:59 am, Matt <travellingmatt2...(a)yahoo.co.uk> wrote: > Alexei A. Frounze wrote: > > On Aug 16, 1:24 am, "Wolfgang Kern" <nowh...(a)never.at> wrote: > >> James Harris asked: > >> ... > > >>> 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 Sure, but what's the point of doing that instead of fixing CS? Alex
From: opexoc on 17 Aug 2007 05:33
On 16 Sie, 23:16, "Wolfgang Kern" <nowh...(a)never.at> wrote: > Yes, but both is correct, > bits 15..3 of an seg-selector are the index and the offset (mask -8) > within a GTD or LDT table. > Thanks for that. > btw: "readed"(sic) doesn't exist in English, use "read" in 'all time' forms. and thanks for that, I always don't remember about it. > __ > wolfgang (not a native English speaker as well) |