32-bit and 64-bit x86 on Windows

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

32-bit and 64-bit x86 on Windows

Neil Brown-2
Hi,

I have a feeling that this veers on being off-topic, but I can't seem to
find the answer anywhere so I'd appreciate some clarification.  I have a
program that uses 64-bit integers that I want to benchmark.  I have done
so by compiling on my 32-bit linux machine and my 32-bit windows
machine, but naturally I really want to benchmark it on a 64-bit
processor that will do the additions etc using 64-bit registers rather
than the somewhat messy method that I imagine the 32-bit compilation
must be using.  I have a friend with a 64-bit processor, but currently
on 32-bit windows.  When I say 32-bit I mean x86, 64-bit is x86-64.
So:

1) Can his machine - which is running 32-bit Windows XP - run a 64-bit
compiled program?  If not, I presume he'd need to be running 64-bit
Windows XP to be able to run the program.  I don't need to access
anything specifically 64-bit outside my program, I just want to be able
to use the native 64-bit registers.

2) Assuming we have solved the above question and got the right OS, what
flag would I use to cross-compile for 64-bit from my 32-bit windows
mingw/msys environment?  (I'm using autoconf/automake with msys)  If he
does need to have 64-bit Windows, would I have to set any extra flags to
account for this?

3) My benchmark program links with a couple of libraries.  For 64-bit
compilation, would I have to re-compile this libraries as 64-bit (they
are all open source), or can I link with their already compiled 32-bit
versions?  They are not used in the part I'm actually benchmarking so
having them as 32-bit rather than 64-bit won't matter to me.

If anyone could help with these queries, I would be very grateful.
Hopefully the answers would also prove useful to others on this list.

Thanks,

Neil.



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: 32-bit and 64-bit x86 on Windows

adah
1) No, not possible. He must be running a 64-bit OS.

2) No, MSYS/MinGW currently does not target x86_64.

3) I think all the libraries need re-compilation targeting the 64-bit
platform to link with a 64-bit program.

Best regards,

Yongwei





[hidden email]


 
        To:     [hidden email]
        CC:
        Subject:        [Mingw-users] 32-bit and 64-bit x86 on Windows

Hi,

I have a feeling that this veers on being off-topic, but I can't seem to
find the answer anywhere so I'd appreciate some clarification.  I have a
program that uses 64-bit integers that I want to benchmark.  I have done
so by compiling on my 32-bit linux machine and my 32-bit windows
machine, but naturally I really want to benchmark it on a 64-bit
processor that will do the additions etc using 64-bit registers rather
than the somewhat messy method that I imagine the 32-bit compilation
must be using.  I have a friend with a 64-bit processor, but currently
on 32-bit windows.  When I say 32-bit I mean x86, 64-bit is x86-64.
So:

1) Can his machine - which is running 32-bit Windows XP - run a 64-bit
compiled program?  If not, I presume he'd need to be running 64-bit
Windows XP to be able to run the program.  I don't need to access
anything specifically 64-bit outside my program, I just want to be able
to use the native 64-bit registers.

2) Assuming we have solved the above question and got the right OS, what
flag would I use to cross-compile for 64-bit from my 32-bit windows
mingw/msys environment?  (I'm using autoconf/automake with msys)  If he
does need to have 64-bit Windows, would I have to set any extra flags to
account for this?

3) My benchmark program links with a couple of libraries.  For 64-bit
compilation, would I have to re-compile this libraries as 64-bit (they
are all open source), or can I link with their already compiled 32-bit
versions?  They are not used in the part I'm actually benchmarking so
having them as 32-bit rather than 64-bit won't matter to me.

If anyone could help with these queries, I would be very grateful.
Hopefully the answers would also prove useful to others on this list.

Thanks,

Neil.




-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

Re: 32-bit and 64-bit x86 on Windows

Chan Kar Heng

interesting...

someone please tell me if i'm right or wrong. or
tell me more details of what's happening...

1) you'll need at least something that will generate
machine codes that use 64 bit registers. afaik even
if you have long long types in mingw, it's probably
faked (by adding 2 32 bit types together, add result
of carry flag to the next 2 32 bit addition,
etc).
address space gets switched to 64 bit address space
in 64bit progs, while winxp lives in 32bit addr space,
not too sure what's gonna happen here, but am quite
sure no 32bit functions can be called from a 64bit
program directly.

3) i read that the windows architecture has something
called "windows on/over windows" layers, or WOW layers.
the 64 bit versions of windows has WOW32 to support
32 bit programs, requiring a copy of all 32bit libraries
required by 32bit programs. the 64bit progs can still
talk to 32bit progs, but via some obscure means which
i can't remember.
it would be something similar to how 32 bit windows
supported 16 bit windows back then.
msdn has much more info on this.
(i wondered how linux handles transition from 32bit to
64bit & asked on a linux user group, but no one seemed
to know).

rgds,

kh


[hidden email] wrote:

> 1) No, not possible. He must be running a 64-bit OS.
>
> 2) No, MSYS/MinGW currently does not target x86_64.
>
> 3) I think all the libraries need re-compilation targeting the 64-bit
> platform to link with a 64-bit program.
>
> Best regards,
>
> Yongwei
>
>
>
>
>
> [hidden email]
>
>
>  
>         To:     [hidden email]
>         CC:
>         Subject:        [Mingw-users] 32-bit and 64-bit x86 on Windows
>
> Hi,
>
> I have a feeling that this veers on being off-topic, but I can't seem to
> find the answer anywhere so I'd appreciate some clarification.  I have a
> program that uses 64-bit integers that I want to benchmark.  I have done
> so by compiling on my 32-bit linux machine and my 32-bit windows
> machine, but naturally I really want to benchmark it on a 64-bit
> processor that will do the additions etc using 64-bit registers rather
> than the somewhat messy method that I imagine the 32-bit compilation
> must be using.  I have a friend with a 64-bit processor, but currently
> on 32-bit windows.  When I say 32-bit I mean x86, 64-bit is x86-64.
> So:
>
> 1) Can his machine - which is running 32-bit Windows XP - run a 64-bit
> compiled program?  If not, I presume he'd need to be running 64-bit
> Windows XP to be able to run the program.  I don't need to access
> anything specifically 64-bit outside my program, I just want to be able
> to use the native 64-bit registers.
>
> 2) Assuming we have solved the above question and got the right OS, what
> flag would I use to cross-compile for 64-bit from my 32-bit windows
> mingw/msys environment?  (I'm using autoconf/automake with msys)  If he
> does need to have 64-bit Windows, would I have to set any extra flags to
> account for this?
>
> 3) My benchmark program links with a couple of libraries.  For 64-bit
> compilation, would I have to re-compile this libraries as 64-bit (they
> are all open source), orb can I link with their already compiled 32-bit
> versions?  They are not used in the part I'm actually enchmarking so
> having them as 32-bit rather than 64-bit won't matter to me.
>
> If anyone could help with these queries, I would be very grateful.
> Hopefully the answers would also prove useful to others on this list.
>
> Thanks,
>
> Neil.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Reply | Threaded
Open this post in threaded view
|

RE: 32-bit and 64-bit x86 on Windows

Christopher Nelson
In reply to this post by Neil Brown-2

There are three essential components.  

First, when running in 64-bit mode, the processor is in the so-called
"long" mode.  When running in 32-bit mode, it's running the so-called
"enhanced" or "extended mode."  When running in 16-bit mode, you have
the "real" mode.

If your operating system supports it, process segments can be set up so
that the processor switches into one of these modes during task
execution.  So that's the first step.

The second step is obviously providing binary support for the
executables.  

Finally, you have "legacy" OS support via libraries, and usually via
thunks to the kernel.  In the case of windows, 16-bit apps had a
compatibility layer that translated 16-bit calls into 32-bit calls and
then back down.  That was called "WOW16".  The same is true on Windows
x64, except that WOW32 and WOW16 are supported.  

They actually go a little bit farther and separate all of the programs
into different Program Files directories depending on if it's a "native"
64-bit app, or 32-bit app.  I'm currently using one of these systems as
my primary workstation, and it's interesting what works and what
doesn't.

If you are talking about ABI then you are correct, just as the 16-bit
ABI is different from the 32-bit ABI.  However, "winxp" doesn't "live"
in a 32-bit space.  Some of the apps still require 32-bit support and
exist in 32-bit segments with all that implies, but the kernel and all
of the drivers are 64-bit apps.  In any case, so long as you know a
function requires the 16-bit API or 32-bit API, you can call it.  That's
usually what a thunk does.

In order to access non-native sized registers you have a segment
override prefix that tells the processor what size of instruction to
use.  There is a "default" native size for segments.  For 64-bit
segments, it's 64-bits, for 32-bit segments it's 32-bits, and for 16-bit
segments it's 16 bits.  No matter what the default size of the segment
is, if you use the correct override prefix for an instruction you can
access any register width.  Incidentally, this is also why it's usually
more efficient to use the segment-native word size for calculations.

 

> interesting...
>
> someone please tell me if i'm right or wrong. or tell me more
> details of what's happening...
>
> 1) you'll need at least something that will generate machine
> codes that use 64 bit registers. afaik even if you have long
> long types in mingw, it's probably faked (by adding 2 32 bit
> types together, add result of carry flag to the next 2 32 bit
> addition, etc).
> address space gets switched to 64 bit address space in 64bit
> progs, while winxp lives in 32bit addr space, not too sure
> what's gonna happen here, but am quite sure no 32bit
> functions can be called from a 64bit program directly.
>
> 3) i read that the windows architecture has something called
> "windows on/over windows" layers, or WOW layers.
> the 64 bit versions of windows has WOW32 to support
> 32 bit programs, requiring a copy of all 32bit libraries
> required by 32bit programs. the 64bit progs can still talk to
> 32bit progs, but via some obscure means which i can't remember.
> it would be something similar to how 32 bit windows supported
> 16 bit windows back then.
> msdn has much more info on this.
> (i wondered how linux handles transition from 32bit to 64bit
> & asked on a linux user group, but no one seemed to know).
>
> rgds,
>
> kh
>
>
> [hidden email] wrote:
> > 1) No, not possible. He must be running a 64-bit OS.
> >
> > 2) No, MSYS/MinGW currently does not target x86_64.
> >
> > 3) I think all the libraries need re-compilation targeting
> the 64-bit
> > platform to link with a 64-bit program.
> >
> > Best regards,
> >
> > Yongwei
> >
> >
> >
> >
> >
> > [hidden email]
> >
> >
> >  
> >         To:     [hidden email]
> >         CC:
> >         Subject:        [Mingw-users] 32-bit and 64-bit x86
> on Windows
> >
> > Hi,
> >
> > I have a feeling that this veers on being off-topic, but I
> can't seem
> > to find the answer anywhere so I'd appreciate some
> clarification.  I
> > have a program that uses 64-bit integers that I want to
> benchmark.  I
> > have done so by compiling on my 32-bit linux machine and my 32-bit
> > windows machine, but naturally I really want to benchmark it on a
> > 64-bit processor that will do the additions etc using
> 64-bit registers
> > rather than the somewhat messy method that I imagine the 32-bit
> > compilation must be using.  I have a friend with a 64-bit
> processor,
> > but currently on 32-bit windows.  When I say 32-bit I mean
> x86, 64-bit is x86-64.
> > So:
> >
> > 1) Can his machine - which is running 32-bit Windows XP -
> run a 64-bit
> > compiled program?  If not, I presume he'd need to be running 64-bit
> > Windows XP to be able to run the program.  I don't need to access
> > anything specifically 64-bit outside my program, I just want to be
> > able to use the native 64-bit registers.
> >
> > 2) Assuming we have solved the above question and got the right OS,
> > what flag would I use to cross-compile for 64-bit from my 32-bit
> > windows mingw/msys environment?  (I'm using autoconf/automake with
> > msys)  If he does need to have 64-bit Windows, would I have
> to set any
> > extra flags to account for this?
> >
> > 3) My benchmark program links with a couple of libraries.  
> For 64-bit
> > compilation, would I have to re-compile this libraries as
> 64-bit (they
> > are all open source), orb can I link with their already compiled
> > 32-bit versions?  They are not used in the part I'm actually
> > enchmarking so having them as 32-bit rather than 64-bit
> won't matter to me.
> >
> > If anyone could help with these queries, I would be very grateful.
> > Hopefully the answers would also prove useful to others on
> this list.
> >
> > Thanks,
> >
> > Neil.
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > MinGW-users mailing list
> > [hidden email]
> >
> > You may change your MinGW Account Options or unsubscribe at:
> > https://lists.sourceforge.net/lists/listinfo/mingw-users
> >
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration
> Strategies from IBM. Find simple to follow Roadmaps,
> straightforward articles, informative Webcasts and more! Get
> everything you need to get up to speed, fast.
> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>


-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. <a href="http://ads.osdn.com/?ad_idt77&alloc_id492&op=click">http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
_______________________________________________
MinGW-users mailing list
[hidden email]

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users