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

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

[Bryan J Smith]

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  
    

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

[Andrew Bird (Sphere Systems)]

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
> 

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

[Bryan J Smith]

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

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

[Bryan J. Smith]

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/24593.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

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

[Andrew Bird (Sphere Systems)]

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@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

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

[Bryan J Smith]

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/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@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è†Ù¥
> 

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

[Bryan J Smith]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="windows-1254", Size: 8593 bytes --]

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@ieee.org  
http://www.linkedin.com/in/bjsmith
Sent via BlackBerry from T-Mobile  
    

-----Original Message-----
From: "Bryan J Smith" <b.j.smith@ieee.org>
Date: 	Sun, 25 Oct 2009 23:36:20 
To: Andrew Bird \(Sphere Systems\)<ajb@spheresystems.co.uk>; 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)

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/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@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è†Ù¥
> 

N‹§²æìr¸›yúèšØb²X¬¶Ç§vØ^–)Þº{.nÇ+‰·¥Š{±šÇh²)í…æèw*\x1fjg¬±¨\x1e¶‰šŽŠÝ¢j/êäz¹Þ–Šà2ŠÞ™¨è­Ú&¢)ß¡«a¶Ú\x7fþø\x1e®G«éh®\x0fæj:+v‰¨Šwè†Ù¥

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

[Andrew Bird (Sphere Systems)]

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

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

[Bryan J Smith]

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@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:40:12 
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)

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

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

[Bart Oldeman]

On Sun, Oct 25, 2009 at 7:40 PM, Andrew Bird (Sphere Systems)
<ajb@spheresystems.co.uk> wrote:
> My understanding of $_cpu_emu=vm86 is that it's also simulated by software,
> just that it's done on demand and cached.

You are 100% right here. Chunks of vm86 code are translated to 64-bit
native long mode code and then executed. With vm86sim the code is
interpreted instead of translated.

On i386 kernels, DOSEMU can use the vm86 syscall which is native, but
on x86-64 it can't, at least without a special kernel module
(http://v86-64.sourceforge.net/) which switches the CPU from long to
legacy mode and back, somewhat tricky.

What you are running into is a bug in DOSEMU, where it uses a JIT
emulator to execute vm86 code (the default on x86-64, and also used
when $_cpu_emu="off" there). The bug is not present in the slower, but
sometimes more reliable simulator. You could try current SVN to see if
it fixed it, because there have been quite a few emulator fixes. I'm
sorry I haven't had time to do a new release so far.

Bart

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

[Andrew Bird (Sphere Systems)]

Hi Bart,
	The original crash report was against SVN 1988, I've pasted it in below for 
ease. Do I need to post the whole thing, or is this segment enough? What 
should I do next to help fix the problem? Unfortunately I can't post or pass 
on the executable that caused it.

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












 
On Monday 26 October 2009, Bart Oldeman wrote:
> On Sun, Oct 25, 2009 at 7:40 PM, Andrew Bird (Sphere Systems)
> 
> <ajb@spheresystems.co.uk> wrote:
> > My understanding of $_cpu_emu=vm86 is that it's also simulated by
> > software, just that it's done on demand and cached.
> 
> You are 100% right here. Chunks of vm86 code are translated to 64-bit
> native long mode code and then executed. With vm86sim the code is
> interpreted instead of translated.
> 
> On i386 kernels, DOSEMU can use the vm86 syscall which is native, but
> on x86-64 it can't, at least without a special kernel module
> (http://v86-64.sourceforge.net/) which switches the CPU from long to
> legacy mode and back, somewhat tricky.
> 
> What you are running into is a bug in DOSEMU, where it uses a JIT
> emulator to execute vm86 code (the default on x86-64, and also used
> when $_cpu_emu="off" there). The bug is not present in the slower, but
> sometimes more reliable simulator. You could try current SVN to see if
> it fixed it, because there have been quite a few emulator fixes. I'm
> sorry I haven't had time to do a new release so far.
> 
> Bart
>