where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: Dirk Wolfgang Glomp on 16 Aug 2007 01:40 Am Wed, 15 Aug 2007 17:17:17 -0400 schrieb CodeMonk: > Dirk Wolfgang Glomp wrote: >> Am Tue, 14 Aug 2007 15:27:44 -0400 schrieb CodeMonk: >> >>> For the *old* Hercules cards, both text and graphics mode memory began >>> at B0000h. No graphics on your card? That is fossil-like old. >>> >>> - Scott >> >> RBIL->Inter61a.zip->Interrup.a > > > > <snip> > Dirk > > Not sure if you're actually replying to me, but since you did: > > http://www.everything2.com/index.pl?node_id=1130121 If the server online? Dirk
From: Wolfgang Kern on 16 Aug 2007 06:33 "Alexei A. Frounze" 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? .... > > 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. Only if it switches from RM to PM16 and the IRQ routine wont access any data .... RM to PM32 will triple fault immediate. But anyway a forced crash either on start, during or Iret. >>> 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). Right, this gray zone is where Big Real with its limited use reside. __ wolfgang
From: Matt on 16 Aug 2007 13:54 Wolfgang Kern wrote: > Wiktor (opexoc) asked: > > > >>> After the jump of course, because CS is loaded by the FAR jump >>> and exactly there occure the mode-transition. > >>> If the distance of clear_pipe is beyond 16 bit limits, or if the >>> clear_pipe is already defined as a 32-bit label, then you should >>> either have the [bits 32] before the label, or manually extend >>> the jump by an '66h'-prefix and the two more bytes in the offset. >>> >>> Not sure if your tool will handle this by itself, >>> the produced code should then look like: >>> >>> 66 EA xx xx xx xx 08 00 JMPF 0008: xxxxxxxxh >>> [BITS 32] after the jump > >> I want to be sure about that: Can I exploit 32 bit address in 16 bit >> mode? ( I want to be really sure. ) > > This is the reason why 66h and 67h overrides exists at all :) > > Yes you can with BIG-REAL mode, but be aware that any IRQ-routine > will alter CS and then crash for sure. > So Big Real is of limited use because IRQs must be disabled during it. > > And of course you can use the 66/67 overrides while in PM16 > (if your tool is unable to figure it out by its own) > to access data in 32-bit 'segments' > > ie: assume this GDT entries: > 00h > 08 16-bit stack (at 1.MB) > 10 16-bit code (at 1.MB) > 18 32-bit code (unlimited flat) > 20 32-bit stack and data (flat) > .... > and what could be done with it: > > ;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). > > __ > wolfgang > > > 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? Matt
From: Matt on 16 Aug 2007 13:59 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 > >>> 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: James Harris on 16 Aug 2007 16:50
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> |