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:33:02 +0100 Message-ID: <200910252333.02848.ajb@spheresystems.co.uk> References: <1390946726-1256496427-cardhu_decombobulator_blackberry.rim.net-276119471-@bda667.bisx.prod.on.blackberry> <463435000-1256497852-cardhu_decombobulator_blackberry.rim.net-1029225029-@bda667.bisx.prod.on.blackberry> <206606.13714.qm@web110814.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <206606.13714.qm@web110814.mail.gq1.yahoo.com> Sender: linux-msdos-owner@vger.kernel.org List-ID: Content-Type: Text/Plain; charset="utf-8" To: "Bryan J. Smith" Cc: linux-msdos-owner@vger.kernel.org, linux-msdos@vger.kernel.org Hi Bryan, Thanks for the confirmation, it aligns with what I'm being told off li= st too.=20 And from my previous tests 18 months ago, it explains why the app works= in=20 32bit OS with $_cpu_emu=3Doff, but fails in 64bit OS with $_cpu_emu=3Do= ff. I can also confirm that with 64bit OS today the app : fails when $_cpu_emu=3Dvm86 # this is the simulator but has JIT compiler runs OK when $_cpu_emu=3Dvm86sim # this is simulator with no code caching I don't think the 32/64 bitness here should affect the simulator/JIT co= de, do=20 you agree? Thanks, Andrew On Sunday 25 October 2009, Bryan J. Smith wrote: > Confirmed ... >=20 > As clarified in Volume 2 on page 14 (9/07 revision): > http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_do= cs/245 > 93.pdf >=20 > "Virtual-8086 mode is not supported when the processor is operating= in > long mode. When long mode is enabled, any attempt to enable virtua= l-8086 > mode is silently ignored." >=20 > 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) Compatib= ility > Mode, whereas the latter has B1) Protected Mode, B2) Virtual 86 mode= and > B3) Real Mode. >=20 > 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 mo= de.=20 > Although Virtual 8086 is a form of it, it is not the same thing, and= does > not work in A2. >=20 > Again, I regularly invite people to read Chapter 1 in Volume 2 becaus= e 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. >=20 >=20 >=20 >=20 > ----- Original Message ---- > From: Bryan J Smith >=20 > Virtual86 !=3D Protected386 >=20 > 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. >=20 > 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. >=20 > 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). >=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: Sun, 25 Oct 2009 19:57:37 > To: > Cc: ; > Subject: Re: Crash on app startup with cpuemu=3Dvm86(corrected) >=20 > Hi Bryan, > Mmm I wondered about that, but thought that DPMI support meant th= at the > executable had to be running in protected mode. The fly in the ointme= nt of > course in that argument is whether a TSR(btrieve) could be run in. S= o am I > better off to rebuild the host machine to i386 arch (32bit) and run w= ith > _cpu_emu=3Doff, will that give me near native speed? >=20 > Thanks, >=20 >=20 > Andrew >=20 > 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), whi= ch > > uses the btrieve TSR, it is misbehaving on startup. The test hardwa= re 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 generate= d 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 01= 000110 > > EAX: 0104020e EBX: 00000000 ECX: 00000050 EDX: 00000e22 VFLAGS(h): > > 00003246 ESI: 0000ebe4 EDI: 00000904 EBP: 0000e9a8 DS: 2390 ES: b80= 0 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-msd= os" 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 >=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 > 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=A02=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