VOGONS

Common searches


First post, by jukivili

User metadata
Rank Newbie
Rank
Newbie

Hello,

I tried Carmageddon 1 with dosbox-0.74, got those horrible vertical bars. So I searched for solution and found out about 80bit vs 64bit floating point issue. Then I checked code and saw that on 32bit x86 dosbox uses i387 fpu using assembler macros and started wondering why it is not used for x86_64 (as it's perfectly allowed to use i387 FPU in 64bit mode).

So I hacked a bit,

1. added some #ifdef __x86_64__ ... #else ... #endif to fpu_instructions_x86.h
2. made new x86_64 macros for gcc (simply by renamed all %eax => %rax, all movl/incl/decl/shll/[op]l => movq/incq/decq/shlq/[op]q, that's all)
3. Edited configure.in to enable x86 assembler fpu on x86_64

And it just worked on first run, Carmageddon 1 on x86_64 dosbox without graphics glitch.

So do you want me to send patch for this? I really would not want to touch the MSVC part and this really is trivial fix anyways.

Reply 2 of 9, by jukivili

User metadata
Rank Newbie
Rank
Newbie

Linux distributions don't provide 32bit dosbox on x86_64.

And building working dosbox required building required 32bit libraries... adding i387 FPU to x86_64 build of dosbox is less work than that.

Reply 3 of 9, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

I don't mind seeing the patch. Won't promise that I will put it in, but I am curious. My 64 bit asm is none existent

Water flows down the stream
How to ask questions the smart way!

Reply 6 of 9, by jukivili

User metadata
Rank Newbie
Rank
Newbie

I decided to do some refactoring. Instead of duplicating all fpu macros for x86_64, I modified existing ones to work on both 32bit and 64bit (as maintaining duplicates would mean more work).

Patch does following:

1. Rename all %%eax => to AX macro, which is defined as:
#ifdef __x86_64__
#define AX "rax"
#else
#define AX "eax"
#endif

So that 64bit "rax" is used on x86_64 and 32bit "eax" on i386.

2. Remove instruction operation size modifiers (trailing Ls from ops), gcc so that selects correct type by itself (for example, movl on 32bit, movq on 64bit).

3. Modify configure.in to enable x86-fpu on x86_64.

Tested on x86_64 linux, compile tested on i386 linux.

Attachments

Reply 7 of 9, by Tobis87

User metadata
Rank Newbie
Rank
Newbie
jukivili wrote:

Is it ok to leave MSVC asm out? I don't how to do 64bit asm on with it, and would not have means to test it.

It does not work with MSVC anyway, because there is no 64bit Inline Assembler support. They only support Compiler Intrinsics.

However I tried to compile it with the Intel C Compiler, also by changing eax to rax and ebx to rbx. But it does not work, I always get "error: operand size mismatch -- __asm mov".

I don't know maybe because Windows uses the LLP64 Modell instead of LP64. But I would like to have this enabled as well, if someone has an idea...

Reply 8 of 9, by wd

User metadata
Rank DOSBox Author
Rank
DOSBox Author

As already pointed out it's useless for win64 since it runs 32bit executables just fine.
I was not aware that 64bit linux has *that* gross problems in some distros but
that may just be a move of focus anyways.
If you're really interested then check out the c-based recompiler which should be
in a quite good shape for 64bit windows albeit non-working. It does not need any
assembler blocks at all.