I'm using a machine which I believe has a 64-bit-capable processor (Intel 
e2140), but is running 32-bit Vista.

Are there any useful 64-bit operations which are easily available in 32-bit 
mode, such as 64-bit arithmetic?

-- 
Bartc 

On Wed, 30 Jul 2008 21:43:13 GMT
"Bartc"  <spamtrap@crayne.org> wrote:

> Are there any useful 64-bit operations which are easily available in
> 32-bit mode, such as 64-bit arithmetic?

Unfortunately, no. The 64-bit operations are implemented by redefining
valid 32-bit operations, and, therefore, can only be executed when the
OS has put the CPU into 64-bit mode.

-- 
Chuck 
http://www.pacificsites.com/~ccrayne/charles.html

On Jul 30, 5:43�pm, "Bartc"  <spamt...@crayne.org> wrote:
> I'm using a machine which I believe has a 64-bit-capable processor (Intel
> e2140), but is running 32-bit Vista.
>
> Are there any useful 64-bit operations which are easily available in 32-bit
> mode, such as 64-bit arithmetic?
>

You can still use 64-bit code via emulation of an x86_64 CPU in your
32-bit environment:

http://bellard.org/qemu/status.html

Nathan.

Bartc wrote:
> I'm using a machine which I believe has a 64-bit-capable processor 
> (Intel e2140), but is running 32-bit Vista.
> 
> Are there any useful 64-bit operations which are easily available in 
> 32-bit mode, such as 64-bit arithmetic?
> 
Get a copy of VMWare and install a virtual 64-bit OS as a guest.

This actually works pretty nicely, even if the host OS is 32-bit!

I've used it many times to debug/verify 64-bit operation on code that 
needed to be portable.

(Currently I'm running 32-bit XP and 64-bit Linux as guest with Vista-64 
as the host OS.)

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

Do you know if VMware emulates the 64-bit instructions (when running on a 
32-bit host OS), or it actually puts the CPU into longmode?

"Terje Mathisen" <spamtrap@crayne.org> wrote in message 
news:xZadna8Q18b_JgzVnZ2dnUVZ_qTinZ2d@giganews.com...
> Bartc wrote:
>> I'm using a machine which I believe has a 64-bit-capable processor (Intel 
>> e2140), but is running 32-bit Vista.
>>
>> Are there any useful 64-bit operations which are easily available in 
>> 32-bit mode, such as 64-bit arithmetic?
>>
> Get a copy of VMWare and install a virtual 64-bit OS as a guest.
>
> This actually works pretty nicely, even if the host OS is 32-bit!
>
> I've used it many times to debug/verify 64-bit operation on code that 
> needed to be portable.
>
> (Currently I'm running 32-bit XP and 64-bit Linux as guest with Vista-64 
> as the host OS.)
>
> Terje
>
> -- 
> - <Terje.Mathisen@hda.hydro.com>
> "almost all programming can be viewed as an exercise in caching"
> 

On Aug 4, 3:22�pm, "comrade"  <spamt...@crayne.org> wrote:
> Do you know if VMware emulates the 64-bit instructions (when running on a
> 32-bit host OS), or it actually puts the CPU into longmode?


It emulates.

"robertwessel2@yahoo.com"  <spamtrap@crayne.org> wrote:

>On Aug 4, 3:22�pm, "comrade"  <spamt...@crayne.org> wrote:
>> Do you know if VMware emulates the 64-bit instructions (when running on a
>> 32-bit host OS), or it actually puts the CPU into longmode?
>
>It emulates.

Really?  I'm dubious.  I have a 64-bit Linux VM on my XP 32-bit machine,
and it runs at essentially native speed.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

robertwessel2@yahoo.com wrote:
> On Aug 4, 3:22 pm, "comrade"  <spamt...@crayne.org> wrote:
>> Do you know if VMware emulates the 64-bit instructions (when running on a
>> 32-bit host OS), or it actually puts the CPU into longmode?
> 
> 
> It emulates.
> 
Nope.

I depends on having a cpu with virtualization (VTX) support, and this 
must be enabled in the BIOS.

Given this, VMware runs 64-bit operating systems natively on a 32-bit 
host OS. The only thing that's really needed, and which Intel have been 
working on since about 1992-93, is that a task switch must be able to 
save all the (64-bit) state, not just the parts that a 32-bit OS knows 
about.

This works because the task switch opcodes currently in use have a 
fairly large save area, much larger than theoretically needed for a 
32-bit cpu.

Intel wanted to have this area variable size, i.e. the OS would use 
CPUID to read of the needed size of each task block, but Microsoft said 
"No way, it has to be static size!", so the compromise was to make it a 
bit larger than what Intel needed immediately.

OK?

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

On Aug 5, 12:17 am, Terje Mathisen  <spamt...@crayne.org> wrote:
> robertwess...@yahoo.com wrote:
> > On Aug 4, 3:22 pm, "comrade"  <spamt...@crayne.org> wrote:
> >> Do you know if VMware emulates the 64-bit instructions (when running on a
> >> 32-bit host OS), or it actually puts the CPU into longmode?
>
> > It emulates.
>
> Nope.
>
> I depends on having a cpu with virtualization (VTX) support, and this
> must be enabled in the BIOS.
>
> Given this, VMware runs 64-bit operating systems natively on a 32-bit
> host OS. The only thing that's really needed, and which Intel have been
> working on since about 1992-93, is that a task switch must be able to
> save all the (64-bit) state, not just the parts that a 32-bit OS knows
> about.
>
> This works because the task switch opcodes currently in use have a
> fairly large save area, much larger than theoretically needed for a
> 32-bit cpu.
>
> Intel wanted to have this area variable size, i.e. the OS would use
> CPUID to read of the needed size of each task block, but Microsoft said
> "No way, it has to be static size!", so the compromise was to make it a
> bit larger than what Intel needed immediately.
>
> OK?

What does the task switching has to do with this (apart from the need
to be emulated by the host when the hardware virtualization is on)?

Alex

Alexei A. Frounze wrote:
> On Aug 5, 12:17 am, Terje Mathisen  <spamt...@crayne.org> wrote:
>> Intel wanted to have this area variable size, i.e. the OS would use
>> CPUID to read of the needed size of each task block, but Microsoft said
>> "No way, it has to be static size!", so the compromise was to make it a
>> bit larger than what Intel needed immediately.
>>
>> OK?
> 
> What does the task switching has to do with this (apart from the need
> to be emulated by the host when the hardware virtualization is on)?

The job becomes much easier if the host OS can switch between a native 
task and one or more independent 64-bit virtual tasks.

Otherwise the VMware device driver would need to hook into the host OS 
task scheduler, to make certain all the 64-bit stuff got saved away each 
time the host would switch away from a VMware task.

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"

On Aug 5, 10:24 am, Terje Mathisen  <spamt...@crayne.org> wrote:
> Alexei A. Frounze wrote:
> > On Aug 5, 12:17 am, Terje Mathisen  <spamt...@crayne.org> wrote:
> >> Intel wanted to have this area variable size, i.e. the OS would use
> >> CPUID to read of the needed size of each task block, but Microsoft said
> >> "No way, it has to be static size!", so the compromise was to make it a
> >> bit larger than what Intel needed immediately.
>
> >> OK?
>
> > What does the task switching has to do with this (apart from the need
> > to be emulated by the host when the hardware virtualization is on)?
>
> The job becomes much easier if the host OS can switch between a native
> task and one or more independent 64-bit virtual tasks.
>
> Otherwise the VMware device driver would need to hook into the host OS
> task scheduler, to make certain all the 64-bit stuff got saved away each
> time the host would switch away from a VMware task.

Well, if the long 64-bit mode is active, hardware TSS-based task
switching no longer works and therefore must be emulated (by VMWare,
Hyper-V, etc). If SVM/VMX is enabled for virtualization purposes, then
the context switching between the host and guest OSes is accomplished
by:
- executing the VMRUN/VMLAUNCH instruction (host->guest)
- executing an instruction that causes a return to the host operation
(many instructions and reasons; some conditions are programmable, some
not; the return appears to the host as if VMRUN/VMLAUNCH just
completed execution)
- external interrupt (also guest->host)
And the CPU state for the host OS and guest OS in this case is kept in
a large data structure called VMCB/VMCS. This is somewhat similar to
the TSS and apparently not very fast as well.
All of this info exists in the AMD and Intel CPU manuals.

The Hyper-V's hypervisor does the switching between the host and guest
OSes entirely (or almost entirely) transparently to the host OS. It
merely makes a bunch of virtual processors out of the physical ones
and runs the former on the latter (there's a scheduler distinct from
the Windows' own scheduler). The hypervisor probably also takes care
of the emulation of the TSS-based switching since the CPU no longer
does that and for performance reasons it would make sense to do so.
You can find this in the documents available at the Microsoft's web
site (presentations and Hypervisor TLFS). I don't know exactly how
VMWare works, though, as I never read technical docs on them.

So, if you're worrying about the separation of the host and guest CPU
and memory state in the case of a Hypervisor, you don't need to. It's
taken care of.

Alex

Alexei A. Frounze wrote:
> So, if you're worrying about the separation of the host and guest CPU
> and memory state in the case of a Hypervisor, you don't need to. It's
> taken care of.

I wasn't worried, but thanks for the info!
:-)

Terje

-- 
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"