Re: Crash on app startup with cpuemu=vm86(corrected)

["Andrew Bird (Sphere Systems)" <ajb@spheresystems.co.uk>]

My understanding of $_cpu_emu=vm86 is that it's also simulated by software, 
just that it's done on demand and cached.

On Sunday 25 October 2009, Bryan J Smith wrote:
> It has to do with Long Mode (48-bit) v. Legacy Mode (32-bit).
> Memory models and what addressing/pointers are supported
> in the registers of processor are everything.
> 
> The "sim" mode works because software is being leveraged.
> 
> --
> Bryan J Smith - mailto:b.j.smith@ieee.org
> http://www.linkedin.com/in/bjsmith
> Sent via BlackBerry from T-Mobile
> 
> 
> -----Original Message-----
> From: "Andrew Bird (Sphere Systems)" <ajb@spheresystems.co.uk>
> Date: Mon, 26 Oct 2009 00:33:02
> To: Bryan J. Smith<b.j.smith@ieee.org>
> Cc: <linux-msdos-owner@vger.kernel.org>; <linux-msdos@vger.kernel.org>
> Subject: Re: Crash on app startup with cpuemu=vm86(corrected)
> 
> Hi Bryan,
> 	Thanks for the confirmation, it aligns with what I'm being told off list
>  too. And from my previous tests 18 months ago, it explains why the app
>  works in 32bit OS with $_cpu_emu=off, but fails in 64bit OS with
>  $_cpu_emu=off.
> 
> I can also confirm that with 64bit OS today the app :
> 	fails when $_cpu_emu=vm86
> 	# this is the simulator but has JIT compiler
> 
> 	runs OK when $_cpu_emu=vm86sim
> 	# this is simulator with no code caching
> 
> I don't think the 32/64 bitness here should affect the simulator/JIT code,
>  do you agree?
> 
> 
> Thanks,
> 
> 
> Andrew
> 
> On Sunday 25 October 2009, Bryan J. Smith wrote:
> > Confirmed ...
> >
> > As clarified in Volume 2 on page 14 (9/07 revision):
> > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/2
> >45 93.pdf
> >
> >   "Virtual-8086 mode is not supported when the processor is operating in
> >   long mode.  When long mode is enabled, any attempt to enable
> > virtual-8086 mode is silently ignored."
> >
> > If you read through Section 1.3, it explains much of this.  Starting with
> >  Table 1-1 on page 11, it breaks down how there is A) Long Mode and B)
> >  Legacy Mode, and how the former has A1) 64-bit Mode and A2)
> > Compatibility Mode, whereas the latter has B1) Protected Mode, B2)
> > Virtual 86 mode and B3) Real Mode.
> >
> > Now it seems that A2 (Compatibility Mode) supports 16-bit/16-bit and
> > might be a bit confusing.  But if you look at B1 (Protected Mode), you'll
> > note 16-bit/16-bit is also supported.  Here's the key.  A2 (Compatibility
> > Mode) _requires_ Protected Mode.  The processor can_not_ exit Protected
> > mode. Although Virtual 8086 is a form of it, it is not the same thing,
> > and does not work in A2.
> >
> > Again, I regularly invite people to read Chapter 1 in Volume 2 because it
> >  explains a lot about the x86-64 architecture, including how register
> >  addresses v. page addresses v. physical addresses are also at work.  The
> >  whole idea behind "Long Mode" is maximum compatibility with i386+MMU
> >  (basically the i486 TLB, as well as i686 PAE).  That means there are
> >  constraints on 16-bit/32-bit compatibility, as well as "hard" limits at
> >  48-bit flat and 52-bit paging as well.
> >
> >
> >
> >
> > ----- Original Message ----
> > From: Bryan J Smith <b.j.smith@ieee.org>
> >
> > Virtual86 != Protected386
> >
> > Long Mode supports Protected386, but not Virtual86.
> > At least that's what I remember from first reading the
> > AMD x86-64 Programmer's docs over 5 years ago.  I'll
> > check when I'm in front of a computer again.
> >
> > Protected386 can still provide DPMI, but it's not the same
> > as Virtual86.  Long Mode is designed for 4-byte flat and
> > 6-byte segmented/normalized pointer compatibility, not
> > 4-byte segmented/normalized pointer compatiblity.
> >
> > Again, it's still quite possible to run DPMI programs, but the
> > processor won't be using Virtual86 IIRC.  If you study how
> > Long Mode works (which is_not_ 64-bit), it starts to make
> > sense how it has its limitations (which allows for i486 TLB
> > compatibility).
> >
> > --
> > Bryan J Smith - mailto:b.j.smith@ieee.org
> > http://www.linkedin.com/in/bjsmith
> > Sent via BlackBerry from T-Mobile
> >
> >
> > -----Original Message-----
> > From: "Andrew Bird (Sphere Systems)" <ajb@spheresystems.co.uk>
> > Date:     Sun, 25 Oct 2009 19:57:37
> > To: <b.j.smith@ieee.org>
> > Cc: <linux-msdos-owner@vger.kernel.org>; <linux-msdos@vger.kernel.org>
> > Subject: Re: Crash on app startup with cpuemu=vm86(corrected)
> >
> > Hi Bryan,
> >     Mmm I wondered about that, but thought that DPMI support meant that
> > the executable had to be running in protected mode. The fly in the
> > ointment of course in that argument is whether a TSR(btrieve) could be
> > run in.  So am I better off to rebuild the host machine to i386 arch
> > (32bit) and run with _cpu_emu=off, will that give me near native speed?
> >
> > Thanks,
> >
> >
> > Andrew
> >
> > On Sunday 25 October 2009, Bryan J Smith wrote:
> > > I'm fairly certain thay when the processor is in "Long Mode"
> > > (48-bit flat, 52-bit PAE) that Virtual86 is not supported.
> > > "Long Mode" is only compatible with 32-bit flat, 36-bit PAE
> > > addressing, and not 20-bit.
> > >
> > > ------Original Message------
> > > From: Andrew Bird (Sphere Systems)
> > > Sender: linux-msdos-owner@vger.kernel.org
> > > To: linux-msdos@vger.kernel.org
> > > Sent: Oct 25, 2009 12:20
> > > Subject: Crash on app startup with cpuemu=vm86(corrected)
> > >
> > > Hi guys,
> > >     I wonder if anyone can help me? I have a bespoke app(DPMI), which
> > > uses the btrieve TSR, it is misbehaving on startup. The test hardware
> > > is x86_64 Athlon X2 , Fedora 11(64 bit install).
> > >
> > > The app is working fine with_cpu_emu=vm86sim and as far back as dosemu
> > >  1.2.2.
> > >
> > > I'd like to get this running with_cpu_emu=vm86 and dosemu 1.4.0 for
> > > extra speed. Here's the relevant log at crash time, it was generated by
> > > SVN 1988
> > >
> > > Thanks
> > >
> > >
> > > Andrew
> > >
> > > EMU86: directly calling int 0x10 ax=0x20e at 0xf800:0x6330
> > > SetSeg REAL CS:f800
> > > SetSeg REAL SS:2390
> > > SetSeg REAL DS:2390
> > > SetSeg REAL ES:b800
> > > SetSeg REAL FS:0000
> > > SetSeg REAL GS:0000
> > > INTERP: enter=000fe330
> > > SetSeg REAL CS:f000
> > > INTERP: exit=000fc010 err=13
> > > EMU86: retval=VM86_UNKNOWN
> > > Sys timers d=0
> > > Do INT0x10: Using caller_function()
> > > 3d4 { 40e
> > > 3d4 { 820f
> > > SetSeg REAL CS:1091
> > > SetSeg REAL SS:2390
> > > SetSeg REAL DS:2390
> > > SetSeg REAL ES:b800
> > > SetSeg REAL FS:0000
> > > SetSeg REAL GS:0000
> > > INTERP: enter=000109a6
> > > SetSeg REAL CS:0d69
> > > ** JMP: ignored
> > > SetSeg REAL CS:901f
> > > SetSeg REAL CS:1be6
> > > ** JMP: ignored
> > > SetSeg REAL CS:958f
> > > SetSeg REAL CS:10f6
> > > SetSeg REAL CS:958f
> > > leavedos(47810|0xbac2) called - shutting down
> > >
> > > killed while in vm86(), trying to dump DOS-registers:
> > > Program=emu.c, Line=492
> > > EIP: 1091:00000096 ESP: 2390:0000e9a2  VFLAGS(b): 00000 00110010
> > > 01000110 EAX: 0104020e EBX: 00000000 ECX: 00000050 EDX: 00000e22
> > > VFLAGS(h): 00003246 ESI: 0000ebe4 EDI: 00000904 EBP: 0000e9a8 DS: 2390
> > > ES: b800 FS: 0000 GS: 0000 FLAGS: PF ZF IF RF VM VIF  IOPL: 3
> > > STACK: 1c 00 00 00 96 00 91 10 46 32 -> 97 32 90 23 90 23 d4 ec 5c 08
> > > OPS  : 03 90 8a f0 33 db b4 02 cd 10 -> 9d 07 1f 5d ca 0a 00 00 00 00
> > >         9d                  1091:0096 popf
> > > closing debugger pipes
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-msdos"
> > > in the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > >
> > >
> > > --
> > > Bryan J Smith - mailto:b.j.smith@ieee.org
> > > http://www.linkedin.com/in/bjsmith
> > > Sent via BlackBerry from T-Mobile
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±šÇh²)í…æèw*jg¬±¨¶‰šŽŠÝ¢j/�êäz¹Þ–Šà
> >2Š Þ™¨è­Ú&¢)ß¡«a¶Úþø®G«�éh®æj:+v‰¨Šwè†Ù¥
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html