What's new

Compiling issues on AMD64

stealthdave

New member
Hello. I'm trying to compile mupen64 on Gentoo 2006.0 for AMD64, and I'm running into problems compiling the glN64 plugin. After a few minor changes, I was able to get everything else to compile. The changes I made were:

- patching source with the Archlinux patch found in the source code thread
- changing the CFLAGS line in Makefile, removing "-mcpu=athlon" and adding " -fPIC":
Code:
CFLAGS          =-DX86 -O3 -fexpensive-optimizations -fomit-frame-pointer -funroll-loops -ffast-math -fno-strict-aliasing -Wall -pipe -fPIC

After that, things seem to go much more smoothly. Everything compiles nicely until I get to glN64 when I get the following warnings and error message:
Code:
g++ -DX86 -O3 -fexpensive-optimizations -fomit-frame-pointer -funroll-loops -ffast-math -fno-strict-aliasing -Wall -pipe -fPIC -D__LINUX__ -DX86_ASM `sdl-config --cflags` -c -o glN64/Textures.o glN64/Textures.cpp
In file included from glN64/Textures.h:5,
                 from glN64/FrameBuffer.h:5,
                 from glN64/gDP.h:5,
                 from glN64/gSP.h:6,
                 from glN64/OpenGL.h:22,
                 from glN64/Textures.cpp:13:
glN64/convert.h: In function `void UnswapCopy(void*, void*, u32)':
glN64/convert.h:422: warning: cast from pointer to integer of different size
glN64/convert.h:430: warning: cast from pointer to integer of different size
glN64/convert.h:430: warning: cast to pointer from integer of different size
glN64/convert.h:434: warning: cast from pointer to integer of different size
glN64/convert.h:434: warning: cast to pointer from integer of different size
glN64/convert.h:435: warning: cast from pointer to integer of different size
glN64/convert.h:435: warning: cast to pointer from integer of different size
glN64/convert.h:437: warning: cast from pointer to integer of different size
glN64/convert.h:437: warning: cast to pointer from integer of different size
glN64/convert.h:447: warning: cast from pointer to integer of different size
glN64/convert.h:447: warning: cast to pointer from integer of different size
glN64/convert.h:448: warning: cast from pointer to integer of different size
glN64/convert.h:448: warning: cast to pointer from integer of different size
glN64/convert.h:455: warning: cast from pointer to integer of different size
glN64/convert.h:455: warning: cast to pointer from integer of different size
glN64/convert.h:459: warning: cast from pointer to integer of different size
glN64/convert.h:459: warning: cast to pointer from integer of different size
glN64/convert.h:460: warning: cast from pointer to integer of different size
glN64/convert.h:460: warning: cast to pointer from integer of different size
glN64/convert.h: In function `void DWordInterleave(void*, u32)':
glN64/convert.h:507: warning: cast from pointer to integer of different size
glN64/convert.h:507: warning: cast to pointer from integer of different size
glN64/convert.h:508: warning: cast from pointer to integer of different size
glN64/convert.h:508: warning: cast to pointer from integer of different size
glN64/convert.h:508: warning: cast from pointer to integer of different size
glN64/convert.h:508: warning: cast to pointer from integer of different size
glN64/convert.h:509: warning: cast from pointer to integer of different size
glN64/convert.h:509: warning: cast to pointer from integer of different size
glN64/convert.h:511: warning: cast from pointer to integer of different size
glN64/convert.h:511: warning: cast to pointer from integer of different size
glN64/convert.h: In function `void QWordInterleave(void*, u32)':
glN64/convert.h:574: warning: cast from pointer to integer of different size
glN64/convert.h:574: warning: cast to pointer from integer of different size
glN64/convert.h:575: warning: cast from pointer to integer of different size
glN64/convert.h:575: warning: cast to pointer from integer of different size
glN64/convert.h:575: warning: cast from pointer to integer of different size
glN64/convert.h:575: warning: cast to pointer from integer of different size
glN64/convert.h:576: warning: cast from pointer to integer of different size
glN64/convert.h:576: warning: cast to pointer from integer of different size
glN64/convert.h:578: warning: cast from pointer to integer of different size
glN64/convert.h:578: warning: cast to pointer from integer of different size
glN64/convert.h:579: warning: cast from pointer to integer of different size
glN64/convert.h:579: warning: cast to pointer from integer of different size
glN64/convert.h:579: warning: cast from pointer to integer of different size
glN64/convert.h:579: warning: cast to pointer from integer of different size
glN64/convert.h:580: warning: cast from pointer to integer of different size
glN64/convert.h:580: warning: cast to pointer from integer of different size
glN64/convert.h:582: warning: cast from pointer to integer of different size
glN64/convert.h:582: warning: cast to pointer from integer of different size
{standard input}: Assembler messages:
{standard input}:1658: Error: Incorrect register `%rbx' used with `l' suffix
{standard input}:1690: Error: Incorrect register `%r13' used with `l' suffix
{standard input}:1702: Error: Incorrect register `%r15' used with `l' suffix
{standard input}:1714: Error: Incorrect register `%r11' used with `l' suffix
{standard input}:1726: Error: Incorrect register `%rbp' used with `l' suffix
{standard input}:1738: Error: Incorrect register `%r14' used with `l' suffix
{standard input}:1750: Error: Incorrect register `%rax' used with `l' suffix
{standard input}:1762: Error: Incorrect register `%r9' used with `l' suffix
{standard input}:1776: Error: Incorrect register `%rbx' used with `l' suffix{standard input}:1786: Error: Incorrect register `%rax' used with `l' suffix
{standard input}:1796: Error: Incorrect register `%r14' used with `l' suffix
{standard input}:1806: Error: Incorrect register `%rsi' used with `l' suffix
{standard input}:1816: Error: Incorrect register `%r9' used with `l' suffix
{standard input}:1826: Error: Incorrect register `%rax' used with `l' suffix
{standard input}:1836: Error: Incorrect register `%r14' used with `l' suffix
{standard input}:1846: Error: Incorrect register `%rsi' used with `l' suffix
make: *** [glN64/Textures.o] Error 1
Any thoughts as to how to procede from here would be appreciated.

- Stealth Dave
 

Toasty

Sony battery
stealthdave said:
So would less attitude.
So would a little gratitude - hey that rhymes. For future reference, it's good forum etiquette to search before posting, to see if your question has already been answered. Just remember for next time and let's be happy. :flowers:
 

ali_malla

New member
ciruZ said:


So what exactly is the point of this?? That it doesn't work?

It's really quite irritating when people write non-portable code. Going from 16bits to 32 wasn't enough of a lesson obviously.

I can't wait to see what'll happen in 10-15 years when everyone and their dog will be going from 64 to 128!

PS. Assembly cores have long gone out of fashion.
 

ciruZ

New member
ali_malla: Assembly actually _IS_ needed for Mupen64's dynarec. Don't judge about it if you have no knowledge about it.
Additionally: Yes, it works in 32-bit mode only. And that's IMO no problem at all. And it has several reasons that it's not 64-bit compatible. So it's not just Hacktarux' lazyness...
 

ali_malla

New member
ciruZ said:
ali_malla: Assembly actually _IS_ needed for Mupen64's dynarec. Don't judge about it if you have no knowledge about it.
Additionally: Yes, it works in 32-bit mode only. And that's IMO no problem at all. And it has several reasons that it's not 64-bit compatible. So it's not just Hacktarux' lazyness...

You are right about one thing - I don't know what "dynarec" does. Dynamic recompilation of code? Whatever it is, don't tell me it can't be done in C! And pretty quickly too.

A decent optimizing compiler will give you a code comparable to hand-made assembly. Even if it's 10% slower, such margin is not going to make or break anything.
 

ciruZ

New member
Yes, dynarec is the abbrev for dynamic recompiler. And no, it can't be done in C. This actually recompiles the game into x86 assembly when you load it.
Generating C code from the N64 game would be _REALLY_ hard, and loading a game would take ages then, because the resultig C code would be compiled with GCC then. As you can see, it's not possible.
I don't know why you want a 64 bit version that hard. It bringts you such a small performance booth that it's not even worth the work. You said that you don't give a damn about 10%, but that would be less than 10%. So where's the problem to just add -m32 to the CFLAGS?
 
Last edited:

ali_malla

New member
Runtime interpretation will be just fine and portable.

The only advantage dyn. rec gives you is some speed increase. However the way hardware is getting more powerful and cheaper, there is little point to that.

In conclusion, consider that DOS/Windows software just 10 years old (not all of which are games) already require an emulator to run on today's OSs/PCs.

Good luck with your emulation efforts!
 

Doomulation

?????????????????????????
ali_malla said:
Runtime interpretation will be just fine and portable.

The only advantage dyn. rec gives you is some speed increase. However the way hardware is getting more powerful and cheaper, there is little point to that.

In conclusion, consider that DOS/Windows software just 10 years old (not all of which are games) already require an emulator to run on today's OSs/PCs.

Good luck with your emulation efforts!
Try doing an nintendo 64 emulator in LLE. Good luck getting it to run at full speed.
 

ali_malla

New member
Doomulation said:
Try doing an nintendo 64 emulator in LLE. Good luck getting it to run at full speed.

your very own system is a perfect example. You have 3GHz CPU and 7800 GT.

7800 GT has pixel fill rate of 6800 MP and N64 30MP. Regardless of whether these numbers are hyped up or not, the idea is that today's video hardware is in the order of several magnitudes more powerful than 10yr old console.

With that hardware, If you can't emulate poor N64 with your eyes closed, something is VERY wrong ;)
 
Last edited:

Doomulation

?????????????????????????
Emulation is not merely about numbers. First, you need the CPU to "emulate" all parts of the hardware. In the real thing, the processor does not handle all the graphics, for example. In emulation, the CPU needs to act as the GPU and handle all the graphics and translate it and send to the GPU. Furthermore, the nintendo 64 does not use an x86 processor. Therefore, it, too, needs to be emulated by the CPU.

...And this is why it requires such a great deal of processor power. Do not forget: consoles often have a better architecture than a PC. For example, the RAM typically runs at the same speed as the CPU (or so I've read) for maxiumum efficiency. This is not the case in the PC, so it slows it down many times. Plus windows steals resources and as does other programs.

This, all together, causes emulation to be an expensive process.
 

Hacktarux

Emulator Developer
Moderator
Are we discussing about the portability or about the point of having a dynarec ?

The dynarec is indeed usefull even with current processors. An interpreter is simply wasting too much time in function calls. It can't be avoided. I think i've nearly reached the maximum possible performance of the interpreter in mupen64 and my AMD64 3000+ is not enough for complex games. I agree that soon, processors will be fast enough but many people don't want to use the full power of their processor for emulation.... And if you want to emulate the RSP (one part of the n64) with an interpreter too, current processors are far from being fast enough.

The speed difference between an interpreter and a dynarec is much more important than what you think.

On the other hand, the dynarec is not the only reason for portability issues on 64 bit processors. In an emulator, you have to take care of variable sizes because you need to do exactly what the emulated hardware does. To emulate a 64 bit processor on a 32 bit processor, it was a bit tricky. And some things has to be rewritten.

The core should not be very hard to port to AMD64 without the dynarec. But it'd be slower than 32bits version because it doesn't have the dynarec. So in my opinion, it's not worth having it working until the dynarec has been ported too.

As i mentioned quite a few times, the plugins are a also a possible issues in porting to 64 bits. I have not written them, so it may hard to check everything. And most of them were written with win32 only in mind.
 

ciruZ

New member
ali_malla: Say me one, only _ONE_ reason, why you need it running in 64 bit mode. The AMD64 ones support 32 bit applications just fine, even if the operating system is in 64 bit mode. The speed increase with 64 bit would be around 1%, the decreases without a dynarec would be about 50%. So say me only _ONE_ reason why a 64 bit version would be needed. Also, you're free to port the dynarec to 64 bits instead of trolling in the forums here. If the dynarec is ported, someone can think about porting the rest. And it's not just easy to write an emulator independent of variable sizes.

// Edit: Sorry, I only saw the first page. This was already answered by Doomulation & Hacktarux.
 
Last edited:

ali_malla

New member
You are all wrong. This is not about speed or AMD64 specifically.

It's about portability.

I have both AMD and Mac (PPC). Before you say these are minority platforms, don't forget "appliances" such as Xbox360 and PS3. You think nobody will want to play emu's on them? Those are not / will not be a minority.

Children, time to grow up and leave the 20+ year old i386 environment!
 

Doomulation

?????????????????????????
Oh, please. Spare us your ramble. Some thing just aren't portable easily, and that's how it is. It isn't fair? The world isn't fair.
And mupen is a multi-platform emulator and should be able to run on most platforms.
 

Hacktarux

Emulator Developer
Moderator
You don't read what we're saying...

It is currently portable on all 32 bits architecture, but on other architecture you don't have the dynarec. For example it's working on mac (ppc) and i've got it working on my gamecube (although i never took the time to write a graphic renderer for it).

64 bits architecture of the core is easy to do and i'll do it whenever i'll have the time to do it, meanwhile, if you can't wait to have it done, you're free to do it yourself. I'm just afraid plugins will be a bit harder to port (it's not an asm problem).

The only thing we're saying is that there's no point in using a 64 bit binary on an AMD64 currently as it wouldn't have the dynarec and the processor is able to run the 32 bit version anyway. From the user point of view, it is better to use a 32 bit version with dynarec that a 64 bit version without. Then again, i'm also planning to write an amd64 dynarec backend. Only a small part has to be rewritten to port the dynarec, but it's not an easy part, and i can't do it for architectures i don't own.
 

Doomulation

?????????????????????????
Perhaps then, it should be forumlated as...
We're sorry, but mupen cannot be ported to everything at the moment and we just haven't had the time / no interest to do it, and therefore you may have to do it yourself if you really need it.
Also... dynarecs are, as stated, very, very, if not impossible, to do in C. Therefore it is done in assembly. As it is with assembly, it is not directly portable to other platforms that does not support these instructions, eg 64-bit (oh they do support 32-bit, but it can't take advantage of its 64-bit-ness).
I should think we should be happy with much work has been put into mupen and not complain straight out if there is something missing. Perhaps a suggestion.
 
Last edited:

Top