From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Andrew Bird (Sphere Systems)" Subject: Re: Crash on app startup with cpuemu=vm86(corrected) Date: Mon, 26 Oct 2009 00:40:12 +0100 Message-ID: <200910252340.13280.ajb@spheresystems.co.uk> References: <1390946726-1256496427-cardhu_decombobulator_blackberry.rim.net-276119471-@bda667.bisx.prod.on.blackberry> <200910252333.02848.ajb@spheresystems.co.uk> <456989766-1256513796-cardhu_decombobulator_blackberry.rim.net-1877636913-@bda667.bisx.prod.on.blackberry> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <456989766-1256513796-cardhu_decombobulator_blackberry.rim.net-1877636913-@bda667.bisx.prod.on.blackberry> Sender: linux-msdos-owner@vger.kernel.org List-ID: Content-Type: Text/Plain; charset="utf-8" To: b.j.smith@ieee.org Cc: linux-msdos-owner@vger.kernel.org, linux-msdos@vger.kernel.org My understanding of $_cpu_emu=3Dvm86 is that it's also simulated by sof= tware,=20 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. >=20 > The "sim" mode works because software is being leveraged. >=20 > -- > Bryan J Smith - mailto:b.j.smith@ieee.org > http://www.linkedin.com/in/bjsmith > Sent via BlackBerry from T-Mobile >=20 >=20 > -----Original Message----- > From: "Andrew Bird (Sphere Systems)" > Date: Mon, 26 Oct 2009 00:33:02 > To: Bryan J. Smith > Cc: ; > Subject: Re: Crash on app startup with cpuemu=3Dvm86(corrected) >=20 > 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 a= pp > works in 32bit OS with $_cpu_emu=3Doff, but fails in 64bit OS with > $_cpu_emu=3Doff. >=20 > I can also confirm that with 64bit OS today the app : > fails when $_cpu_emu=3Dvm86 > # this is the simulator but has JIT compiler >=20 > runs OK when $_cpu_emu=3Dvm86sim > # this is simulator with no code caching >=20 > I don't think the 32/64 bitness here should affect the simulator/JIT = code, > do you agree? >=20 >=20 > Thanks, >=20 >=20 > Andrew >=20 > 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 operati= ng 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. Startin= g 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 an= d > > 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 (Compati= bility > > Mode) _requires_ Protected Mode. The processor can_not_ exit Prote= cted > > mode. Although Virtual 8086 is a form of it, it is not the same thi= ng, > > and does not work in A2. > > > > Again, I regularly invite people to read Chapter 1 in Volume 2 beca= use it > > explains a lot about the x86-64 architecture, including how regist= er > > addresses v. page addresses v. physical addresses are also at work= =2E The > > whole idea behind "Long Mode" is maximum compatibility with i386+M= MU > > (basically the i486 TLB, as well as i686 PAE). That means there a= re > > constraints on 16-bit/32-bit compatibility, as well as "hard" limi= ts at > > 48-bit flat and 52-bit paging as well. > > > > > > > > > > ----- Original Message ---- > > From: Bryan J Smith > > > > Virtual86 !=3D 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)" > > Date: Sun, 25 Oct 2009 19:57:37 > > To: > > Cc: ; > > Subject: Re: Crash on app startup with cpuemu=3Dvm86(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 arc= h > > (32bit) and run with _cpu_emu=3Doff, 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=3Dvm86(corrected) > > > > > > Hi guys, > > > I wonder if anyone can help me? I have a bespoke app(DPMI), w= hich > > > uses the btrieve TSR, it is misbehaving on startup. The test hard= ware > > > is x86_64 Athlon X2 , Fedora 11(64 bit install). > > > > > > The app is working fine with_cpu_emu=3Dvm86sim and as far back as= dosemu > > > 1.2.2. > > > > > > I'd like to get this running with_cpu_emu=3Dvm86 and dosemu 1.4.0= for > > > extra speed. Here's the relevant log at crash time, it was genera= ted by > > > SVN 1988 > > > > > > Thanks > > > > > > > > > Andrew > > > > > > EMU86: directly calling int 0x10 ax=3D0x20e 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=3D000fe330 > > > SetSeg REAL CS:f000 > > > INTERP: exit=3D000fc010 err=3D13 > > > EMU86: retval=3DVM86_UNKNOWN > > > Sys timers d=3D0 > > > 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=3D000109a6 > > > 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=3Demu.c, Line=3D492 > > > 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 5= c 08 > > > OPS : 03 90 8a f0 33 db b4 02 cd 10 -> 9d 07 1f 5d ca 0a 00 00 0= 0 00 > > > 9d 1091:0096 popf > > > closing debugger pipes > > > -- > > > To unsubscribe from this list: send the line "unsubscribe linux-m= sdos" > > > in the body of a message to majordomo@vger.kernel.org > > > More majordomo info at http://vger.kernel.org/majordomo-info.htm= l > > > > > > > > > -- > > > 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-msd= os" in > > the body of a message to majordomo@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > N=E2=80=B9=C2=A7=C2=B2=C3=A6=C3=ACr=C2=B8=E2=80=BAy=C3=BA=C3=A8=C5=A1= =C3=98b=C2=B2X=C2=AC=C2=B6=C3=87=C2=A7v=C3=98^=E2=80=93)=C3=9E=C2=BA{.n= =C3=87+=E2=80=B0=C2=B7=C2=A5=C5=A0{=C2=B1=C5=A1=C3=87h=C2=B2)=C3=AD=E2=80= =A6=C3=A6=C3=A8w*jg=C2=AC=C2=B1=C2=A8=C2=B6=E2=80=B0=C5=A1=C5=BD=C5=A0=C3= =9D=C2=A2j/=EF=BF=BD=C3=AA=C3=A4z=C2=B9=C3=9E=E2=80=93=C5=A0=C3=A0 > >2=C5=A0 =C3=9E=E2=84=A2=C2=A8=C3=A8=C2=AD=C3=9A&=C2=A2)=C3=9F=C2=A1=C2= =ABa=C2=B6=C3=9A=C3=BE=C3=B8=C2=AEG=C2=AB=EF=BF=BD=C3=A9h=C2=AE=C3=A6j:= +v=E2=80=B0=C2=A8=C5=A0w=C3=A8=E2=80=A0=C3=99=C2=A5 >=20 -- 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