To take a guess, I'd say a few register modes are simulated. But I'll read up to find out more on the internals. The problem is that Long Mode can't do Real86/Virt86. It can still do everything else. DPMI can be implemented without them. -- Bryan J Smith - mailto:b.j.smith@xxxxxxxx http://www.linkedin.com/in/bjsmith Sent via BlackBerry from T-Mobile -----Original Message----- From: "Andrew Bird (Sphere Systems)" <ajb@xxxxxxxxxxxxxxxxxxx> Date: Mon, 26 Oct 2009 00:40:12 To: <b.j.smith@xxxxxxxx> Cc: <linux-msdos-owner@xxxxxxxxxxxxxxx>; <linux-msdos@xxxxxxxxxxxxxxx> Subject: Re: Crash on app startup with cpuemu=vm86(corrected) 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@xxxxxxxx > http://www.linkedin.com/in/bjsmith > Sent via BlackBerry from T-Mobile > > > -----Original Message----- > From: "Andrew Bird (Sphere Systems)" <ajb@xxxxxxxxxxxxxxxxxxx> > Date: Mon, 26 Oct 2009 00:33:02 > To: Bryan J. Smith<b.j.smith@xxxxxxxx> > Cc: <linux-msdos-owner@xxxxxxxxxxxxxxx>; <linux-msdos@xxxxxxxxxxxxxxx> > 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@xxxxxxxx> > > > > 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@xxxxxxxx > > http://www.linkedin.com/in/bjsmith > > Sent via BlackBerry from T-Mobile > > > > > > -----Original Message----- > > From: "Andrew Bird (Sphere Systems)" <ajb@xxxxxxxxxxxxxxxxxxx> > > Date: Sun, 25 Oct 2009 19:57:37 > > To: <b.j.smith@xxxxxxxx> > > Cc: <linux-msdos-owner@xxxxxxxxxxxxxxx>; <linux-msdos@xxxxxxxxxxxxxxx> > > 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@xxxxxxxxxxxxxxx > > > To: linux-msdos@xxxxxxxxxxxxxxx > > > 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@xxxxxxxxxxxxxxx > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > > > > > > > -- > > > Bryan J Smith - mailto:b.j.smith@xxxxxxxx > > > 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@xxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{��k ����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
