Oh, but if you mean ALU, no, no effect/issue. Long mode supports full 8 to 32-bit operands/operators. -- Bryan J Smith - mailto:b.j.smith@xxxxxxxx http://www.linkedin.com/in/bjsmith Sent via BlackBerry from T-Mobile -----Original Message----- From: "Bryan J Smith" <b.j.smith@xxxxxxxx> Date: Sun, 25 Oct 2009 23:36:20 To: Andrew Bird \(Sphere Systems\)<ajb@xxxxxxxxxxxxxxxxxxx>; 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) 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/245 > 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è†Ù¥ > N������y��X��ǧv��){.n�����{����)�� jg��� �����ݢj/���ޖ��ޙ��&�)ߡ�a�������+v���w����.n��������+%������w��{.n�����{��k ����n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�m
