Switching between 64-bit and compatibility mode as you please

[_japheth]

Hello,

for those who are interested in low-level stuff here's a little toy: A 32-bit PE binary that's launched in DOS,
and initially runs in long mode, compatibility sub-mode. With a simple far jmp it switches to 64-bit mode.

I had to adjust jwasm' to make it accept both 32- and 64-bit sections in one source module - there's no linker, AFAIK, that's capable to create such "mixed" binaries.

[jj2007]

msdos.exe mon32x.exe gives me "illegal instruction"

Other 16-bit applications work just fine with msdos.exe, so I guess it's a bit more complex. Nice idea, though

2. Requirements
 
  to run an image with Dos32cm attached one needs:

   - a 64-bit CPU
   - an installed DOS
   - an installed XMS host
   - enough extended memory to load the image

[_japheth]

[Other 16-bit applications work just fine with msdos.exe, so I guess it's a bit more complex. Nice idea, though

Sometimes I wonder why you have to pollute so many threads with your troll posts ... I wouldn't go so far as to conclude that it "tells a lot about you", but it surely is an indication for ...

AFAIR I never posted nonsense in your precious Masmbasic forum?

[jj2007]

Dear Andreas,

Nothing in my comment is aimed at denigrating you or your work, on the contrary, I admire what you are doing!

I am just expressing that I find the idea interesting, but that it apparently does not work in my simple 16-bit DOS setup. 

Instead of playing beleidigte Leberwurst for no reason at all, you might explain what you mean with "an installed DOS" on a 64-bit machine: DOSBOX? Some other emulator? And why does it crash with "illegal instruction" when launched with Toshiya's DOS emulator (not sure if it can be called an emulator)?

I had to adjust jwasm' to make it accept both 32- and 64-bit sections in one source module - there's no linker, AFAIK, that's capable to create such "mixed" binaries.

This works fine with UAsm64 and the March 98 linker that comes with the Masm32 SDK:

Code Select Expand

.686p ; create 32 bit code
.model flat, stdcall ; 32 bit memory model
option casemap:none ; case sensitive
.code
.x64
MbX64 SEGMENT EXECUTE USE64
sometest proc far
  push rax

Probably you will now explain to me that I haven't understood anything, but if that makes you happy, so be it

[Gunther]

Andreas,

thank you for this notable tool. 

It works very well under FreeDOS 1.1 and 1.3 with HIMEM.SYS. However, it also works under VirtualBox 6.1, as the following output shows:

Code Select Expand


Mon32x loaded at 400000, rsp=408ff0
ax=200 bx=400000 cx=400020 dx=a si=402006 di=690200 bp=1161
(cmds: a,d,q):

It would be very nice to have the current JWASM also as DOS version. Is that possible?

Please excuse my late response. But my water cooling for the CPU was damaged and the replacement cooling only arrived in the mail yesterday. Because of this I wasn't online for a while and read
your post only today after the repair.

Quite incidentally: You shouldn't react to every humbug from Italy.

[_japheth]

it also works under VirtualBox 6.1, as the following output shows:

thanks for the info, The last time I tried VBox wasn't able to support 64-bit in DOS ( or perhaps I was unable to create such a VM ). Will try again.

It would be very nice to have the current JWASM also as DOS version. Is that possible?

Yes.

I made a little benchmark demo ( attached ) that compares execution times in 32-/64-bit modes. Qemu - with KVM enabled - runs it with virtually no time penalty compared to pure DOS ( at least the 64-bit variants ).

[_japheth]

It would be very nice to have the current JWASM also as DOS version. Is that possible?

Yes.

[Gunther]

Andreas,

very special thanks for the new DOS JWASM. 

Here are the results of the benchmark under VirtualBox:

Code Select Expand


running bm in 32bit...
time: 228 ms for 100000000 iterations
running bm in 64bit, 32-bit regs...
time: 229 ms for 100000000 iterations
running bm in 64bit, 64-bit regs...
time: 2011 ms for 100000000 iterations
bye


Thank you for sharing that code. Hopefully the test will be of some help for you.

[_japheth]

Hopefully the test will be of some help for you.

It was actually meant as a demonstration only - how this tool could be used to test 32-/64-bit code in an environment with just 1 active core and no threads running in the background.

But your results are quite interesting - so I also created a VBox DOS VM and run the benchmark. The interesting thing is that on my machine ( AMD Ryzen ) the 32-bit register calculations are a lot slower ( 700 ms ), while the 64-bit register results are significantly faster ( 1070 ms ).

[Gunther]

Andreas,

... so I also created a VBox DOS VM and run the benchmark. The interesting thing is that on my machine ( AMD Ryzen ) the 32-bit register calculations are a lot slower ( 700 ms ), while the 64-bit register results are significantly faster ( 1070 ms ).

that is indeed a bit strange. What does Qemu have to say about this?

Here are the values from me under plain DOS:

Code Select Expand


running bm in 32bit...
time: 253 ms for 100000000 iterations
running bm in 64bit, 32-bit regs...
time: 253 ms for 100000000 iterations
running bm in 64bit, 64-bit regs...
time: 2224 ms for 100000000 iterations
bye


[zedd151]

... the 32-bit register calculations are a lot slower ( 700 ms ), while the 64-bit register results are significantly faster ( 1070 ms ).

Hmmm. Actually 700ms is faster than 1070ms. I.e., 32 bit faster than 64 bit. Either that was an error in your post, or I'm missing something.

[_japheth]

Hmmm. Actually 700ms is faster than 1070ms. I.e., 32 bit faster than 64 bit. Either that was an error in your post, or I'm missing something.

I guess my English was too bad. 

> that is indeed a bit strange. What does Qemu have to say about this?

Qemu, VBox and plain DOS are all virtually the same.
However, running the bm on an Intel machine (I5 3330) also gives that strange result. So it's pretty likely a AMD/Intel CPU difference.

[zedd151]

Hmmm. Actually 700ms is faster than 1070ms. I.e., 32 bit faster than 64 bit. Either that was an error in your post, or I'm missing something.

I guess my English was too bad. 

It happens, no apology necessary. The numbers presented did illustrate the intention, even though it was erroneously worded. No harm, no foul.

[Gunther]

Andreas,

Qemu, VBox and plain DOS are all virtually the same.

Interesting enough.

However, running the bm on an Intel machine (I5 3330) also gives that strange result. So it's pretty likely a AMD/Intel CPU difference.

This is indeed quite strange. Unfortunately, I don't have access to an AMD CPU at the moment.