where [BITS 32] directive?
in [ASM]
|
Prev: NASM HelloWorld - DOS
Next: ELF loading
From: Wolfgang Kern on 21 Aug 2007 14:18 Alexei A. Frounze wrote: [about VM86 speed ...] .... >> Interesting, how to you determine between a bug-#GP and a VM86-#GP ? >> By the offending selector only ? > Forgot about EFLAGS on the stack? :) Analyze its VM bit. Yeah this is a rare bit used by me indeed :) .... >> Ah yes, a forced exception to return. >> But wouldn't the same as enter VM86 work for return as well ? >> PUSH.. |IRET > If you load SP with 1 and then do PUSH or if you load SP with 0xffff > and then do IRET, an exception is guaranteed and in principle you > could use that to get out of V86. ;) But no, other than an interrupt > or exception there's no way out and neither PUSH nor IRET under normal > conditions would result an exception. Ok, I see. >> So far I understood you push the INT10 vector and don't use INT10h. >> Well, this could be faster than what I last tried with VM86. > Yes, if you want the code behind int N to be executed, you can just > emulate the real-mode effect of INT N (PUSHF+FAR CALL) w/o having to > handle #GP resulting in from execution of INT N. Of course, if that > code in turn does INT X, then you still have to handle #GP for that > INT X. So you can save on exception handling a bit. I've seen VideoBIOS call itself quite often with INT10/6D and may call the MainBIOS with INT15/1A/1C/4F/.. in some functions. I'd like to see more PM32 support in grapicsBios as we got yet. .... >> It would be really interesting to compare the overall performance >> on a trivial thing like a palette-load in 256-bit VGA mode, >> as this are 772 I/O accesses and 256 dword RAM reads. > I remember only one number about VGA: 1.6 GHz Pentium CPU doing 30 FPS > maximum in 640x480 4bpp mode. Paging effect with such a slow VGA > buffer access at the hardware level is just a joke. :) Non-planar > modes w/o those sliding VESA windows/banks should be fast, but I have > no numbers. We got a problem with the comparision anyway, you don't like to destroy your code, and I wont change mine either, so perhaps we can find and convince a neat coder to check on speed in both variants on one single machine :) __ wolfgang
From: Alexei A. Frounze on 23 Aug 2007 01:41 On Aug 21, 11:18 am, "Wolfgang Kern" <nowh...(a)never.at> wrote: > Alexei A. Frounze wrote: > > [about VM86 speed ...] > ... > > >> Interesting, how to you determine between a bug-#GP and a VM86-#GP ? > >> By the offending selector only ? > > Forgot about EFLAGS on the stack? :) Analyze its VM bit. > > Yeah this is a rare bit used by me indeed :) > ... > > >> Ah yes, a forced exception to return. > >> But wouldn't the same as enter VM86 work for return as well ? > >> PUSH.. |IRET > > If you load SP with 1 and then do PUSH or if you load SP with 0xffff > > and then do IRET, an exception is guaranteed and in principle you > > could use that to get out of V86. ;) But no, other than an interrupt > > or exception there's no way out and neither PUSH nor IRET under normal > > conditions would result an exception. > > Ok, I see. > > >> So far I understood you push the INT10 vector and don't use INT10h. > >> Well, this could be faster than what I last tried with VM86. > > Yes, if you want the code behind int N to be executed, you can just > > emulate the real-mode effect of INT N (PUSHF+FAR CALL) w/o having to > > handle #GP resulting in from execution of INT N. Of course, if that > > code in turn does INT X, then you still have to handle #GP for that > > INT X. So you can save on exception handling a bit. > > I've seen VideoBIOS call itself quite often with INT10/6D and may > call the MainBIOS with INT15/1A/1C/4F/.. in some functions. > I'd like to see more PM32 support in grapicsBios as we got yet. > > ... > > >> It would be really interesting to compare the overall performance > >> on a trivial thing like a palette-load in 256-bit VGA mode, > >> as this are 772 I/O accesses and 256 dword RAM reads. > > I remember only one number about VGA: 1.6 GHz Pentium CPU doing 30 FPS > > maximum in 640x480 4bpp mode. Paging effect with such a slow VGA > > buffer access at the hardware level is just a joke. :) Non-planar > > modes w/o those sliding VESA windows/banks should be fast, but I have > > no numbers. > > We got a problem with the comparision anyway, you don't like to > destroy your code, and I wont change mine either, so perhaps we > can find and convince a neat coder to check on speed in both > variants on one single machine :) Honestly, I've been busy lately and I'm also a bit lazy. :) I might do some very simple measurements but not necessarily soon. Alex
From: Wolfgang Kern on 23 Aug 2007 08:18 Alexei A. Frounze wrote: [about VM86 speed ...] >>>> It would be really interesting to compare the overall performance ..... >> We got a problem with the comparision anyway, you don't like to >> destroy your code, and I wont change mine either, so perhaps we >> can find and convince a neat coder to check on speed in both >> variants on one single machine :) > Honestly, I've been busy lately and I'm also a bit lazy. :) > I might do some very simple measurements but not necessarily soon. If we just wait long enough (when we both are gone to long mode) then this problem will disapear anyway :) __ wolfgang
From: Rod Pemberton on 31 Aug 2007 02:05
"Wolfgang Kern" <nowhere(a)never.at> wrote in message news:fa11k9$2p5$1(a)newsreader2.utanet.at... > > 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. > > > Or does the CPU remain in real mode until a far jump? > > Yes "until CS become altered", ..the playground for BigReal. > > > If the former is the case then should interrupts be disabled over the > > transition to protected mode? > > The former is the case. > So better disable IRQS during RM/PM switches/LGDT/LIDT/LLDT/.. :) > Sorry for the delay... There is also the extremely rare possibility that an interrupt will trigger between the two instructions when most interrupts are disabled. How is that possible? The cli instruction will block all but NMI interrupt. For the paranoid, you may also want to disable NMI interrupts. My understanding is this is done via write to port 0x70 with an NMI register value that's been or'd with 0x80 (0x0D is safe port, i.e., 0x8D) and a read from port 0x71 (a discard, but required...). Rod Pemberton |