64-bit WinUAE?

[kolla]

For this it would make sense for m68k emulator devs to do a joint effort; aranym, uae and basilisk.

[turrican3]

not a beta 64 bits yet Toni ?
do you work on it ?

[AmigaBoy]

I'm not a 64-bit Windows user so I have no need for a 64-bit WinUAE, and I don't really see the point of it unless you want to address more than 4gb of memory. Speedwise it won't be much quicker, if at all. Those of you wanting a 64-bit version really don't need it. Regardless, I would like to see some progress in the area, if only to clean up the JIT code and take WinUAE closer to portability.

Converting x86 opcodes to instructions is a fairly simple problem to solve.

Looking at the WinUAE source, specifically codegen_x86.c in the jit folder, I see:

LOWFUNC(NONE,WRITE,2,raw_mov_w_mi,(MEMW d, IMM s))
{
    emit_byte(0x66);
    emit_byte(0xc7);
    emit_byte(0x05);
    emit_long(d);
    emit_word(s);
}
LENDFUNC(NONE,WRITE,2,raw_mov_w_mi,(MEMW d, IMM s))

This would equate to something like:

66C705 00112233 4455   MOV WORD PTR DS:[33221100],5544

Where the bytes 00112233 equate to 'd' and 5544 equate to 's'.
Now that we know what the opcodes map to, we can easily create a mov_w_mi () function which, when called, will dynamically convert to the assembly required by the architecture.

Now take the following:

LOWFUNC(NONE,WRITE,1,raw_push_l_r,(R4 r))
{
	emit_byte(0x50+r);
}
LENDFUNC(NONE,WRITE,1,raw_push_l_r,(R4 r))

This equates to PUSH EAX, however that 'r' complicates things a little and could lead to some messy code if implemented badly. It's clear why it was done. Adding 1 to 0x50 gives 0x51 which is PUSH ECX, 0x52 is PUSH EDX, etc. Will the converted code test each case individually? Still not a problem if portability is key, it just leads to some messy code.

The ultimate problem is that it's extremely time consuming if you don't have adequate x86 knowledge. Want proof? The process, as I see it, is as follows:

- Get OllyDBG
- Drag in any Windows executable so you have something to edit
- Left click on the first line, then right click and go to Follow In Dump -> Selection. The memory window should now be pointing to the memory area of that line.
- Click on the first byte in the memory window and begin typing the opcode. In the case of the MOV line, I would type 66 then press OK. Click on the next byte and begin typing the next opcode, C7. Do the same with the final one, 05.
- Look at the disassembly and you will see that the line has changed to reflect the instruction. eg.

66:C705 28994900 E8D3 MOV WORD PTR DS:[499928],0D3E8

It's simple, but considering codegen_x86.c is so long, it'll take much more time than it's worth. Only someone really bored should tackle it.

With all that said, if Toni was talking about something else entirely, forgot this post

[AmigaBoy]

Actually, ignore that post entirely. I just reread the thread. Basilisk II almost does what we want, so it's a matter of implementing the remaining code into its JIT implementation, but I have no idea how difficult that is. I assume Toni's already looked into it before, and if it's not already done, it's doubtful that it's an easy task.

[Toni Wilen]

I don't want to touch any intel assembly (x86 or x64)

I can merge the BasiliskII JIT _IF_ there is someone who knows how to implement the exception handler. (which is extremely confusing in x86 version..)

[Ian]

people always talk about the "addressing 4gb" thing but there is obviously more to it than that as mame is significantly faster in x64 builds than x86

Originally Posted by Toni Wilen

I don't want to touch any intel assembly (x86 or x64)

I can merge the BasiliskII JIT _IF_ there is someone who knows how to implement the exception handler. (which is extremely confusing in x86 version..)

Well said and should end the discussion until someone comes forward to
do this.
WinUAE is the cat's meow and totally usable on a 64 bit machine so -I-
couldn't ask for more!
How much faster does one need to run an emulated Amiga?


regards,
DJ

[AmigaBoy]

Originally Posted by Ian

people always talk about the "addressing 4gb" thing but there is obviously more to it than that as mame is significantly faster in x64 builds than x86

The thing is, it's entirely true. The only false statement that I made is the addressing 4gb memory thing, when it's more like 3.2gb in Windows (due to addressing I/O). 4gb is the theoretical maximum (ie. a perfect world).

The reason why MAME x64 is faster than x86 is because running a 32-bit application on a 64-bit OS will have an inherent slowdown. This is due to a 64-bit OS spending time manipulating numbers/strings/whatever from 32-bit to 64-bit. This takes time, so that's why MAME seems significantly faster to you. Theoretically it'll be 2 times faster than the 32-bit, however realistically, it will be under 2 times (I can't say by how much without seeing or performing actual benchmarks).

I stand by my statement. WinUAE doesn't need to be made 64-bit since the speed increases you will see are marginal. You can't just run an x86 application under x64 and say x64 rocks your world. It's just not possible.

[gilgamesh]

I don't think the problem is 32bit vs 64bit. The JIT is becoming sort of a black hole. It ties WinUAE inevitably to one dated platform, while even Toni says that he doesn't want to touch it. It is extremely confusing code. It seems practically unmaintainable, and therefore I think a complete overhaul would be a good idea.

But then, it works very well, and nobody seems to be a) competent and b) willing to change it in the moment.

[Toni Wilen]

Here is quickly compiled 64-bit winuae: http://www.winuae.net/files/b/winuae64.zip (same optimization options as 32-bit build)

- No JIT. Anyone asking about this will get his/her head examined.
- No tablet support (wintab appears to be 32-bit only)
- No prowizard (didn't bother to recompile, possibly not 64-bit safe anyway)
- No hq2x software filters (x86 assembly only)
- Something else missing? I wouldn't care less.

[flunky]

No capsimg.dll support.

[Toni Wilen]

Updated and uploaded to working site: http://files.winuae.net/beta/winuae64.zip

(Quiet here, I guess the main point was finally understood that 64-bit WinUAE is totally useless)

[PowerPie5000]

I personally don't see the need for 64-bit Winuae at the moment. The 32-bit version runs perfectly fine within a 64-bit OS and i doubt there will be a huge difference in performnce even if there was a 64-bit Winuae I mean how much more performance do you need from an Amiga emulator running on a current high end machine?

[Interceptor]

Originally Posted by flunky

No capsimg.dll support.

yes it does support capsimg.dll, you just need a 64bit version.

it's working here, there should be a 64bit download on the webpage in a day or so, i'll post here once its up there is just a couple of things to check.

[Ian]

Well, rather than make baseless assumptions I decided to actually test the x64 build

I ran some tests, first with P96Speed, which was not even a quarter of the speed of the x86 build, then I ran sysspeed in a virgin classicwb install with the results seen in the attached image (Unamed in the second column is from the x86 test with the same options/config used - config also attached) - I know benchmarks can be misleading but you can tell it's far slower in normal operation even getting sysspeed to start.

It seems as though the CPU speed is not being allowed to "run free" in Fastest Possible mode in the x64 build, but that is just from an end user point of view I have no clue what is causing the problem from a technical standpoint.

Anyway, unless it's an easy fix this build should be dropped in my opinion.

Edit: I was going to test if it was usable in cycle exact mode but that is a non starter, it will not even display the "insert disk" animation while booting.

Edit2: Used builds marked beta 11 for both tests.

[gilgamesh]

Did you compare non-JIT to non-JIT?

[Toni Wilen]

Originally Posted by Ian

Well, rather than make baseless assumptions I decided to actually test the x64 build

More information (at least logs) because x64 = minimal priority. Even replying to this post is going over my allocated x64 energy quota

Did you compare non-JIT to non-JIT?

It is obviously non-JIT test if you check the attached config file. At least I hope so

[Ian]

I will run some tests and attach the logs.

Of course I tested none JIT modes. Maybe I'll do a jit enabled test for reference of speed loss

[Ian]

Here are the logs, hope there is something useful in them.

[Interceptor]

Originally Posted by Interceptor

yes it does support capsimg.dll, you just need a 64bit version.

it's working here, there should be a 64bit download on the webpage in a day or so, i'll post here once its up there is just a couple of things to check.

windows x64 plugin can be downloaded from the website now

http://www.softpres.org/download