Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help! Porting to 64-bit intel machines but some problems.

1 view
Skip to first unread message

Timothy Stark

unread,
Feb 26, 2007, 10:48:25 PM2/26/07
to
Hello folks,

I am working on my emulator. When I am porting to 64-bit Intel from old
32-bit, I ended up many bugs in my emulator! I think that I found a bug in
GNU C/C++ v4.1 compiler to treat 32-bit integer as 64-bit integer. For
examples:

typedef unsigned long uint32;

:
:

uint32 instr, opcode;

opcode = instr >> 26; // extract high 6-bit opcode from instruction word.

That bring garbage from upper 32-bit into lower 32-bit and it cause my
emulator to crash with segementation fault errors. With a solution, I had
to revise it:

opcode = (instr >> 26) & 0x3F;
cpu->fnCode[opcode](cpu);

It now works...

How do I force my GNU C/C++ compiler to treat 32-bit integers instead of
default 64-bit integer? When I used -S option, I found out that alot of
instructions like movq, addq, etc for just uint32!

Does anyone have any information about porting to 64-bit Intel (x86-64) by
using GNU C/C++ v4.1 compiler?

Thanks!
Tim


Conrad J. Sabatier

unread,
May 23, 2007, 9:50:12 PM5/23/07
to
In article <Mr-dnZyC79qTN37Y...@comcast.com>,

Have you tried using:

typedef unsigned int uint32;

To the best of my knowledge, the "int" type is still only 32 bits. What
made you decide to use "long" instead?

--
Conrad J. Sabatier <con...@cox.net>

amateur

unread,
Jun 2, 2007, 11:58:28 PM6/2/07
to
You are right. The 64-bit version of x86 from intel is called IA32E.
And in GNU/Linux, the so called LP64 model is used, which means long
and pointer are all 64-bit. So if you want to use 32 bit, use int
instead of long. With glibc, you can use uint32_t directly for
32-bit data, and uint64_t for 64-bit data.

0 new messages