Program in 32-bit, run on 64-bit OK?

[sl@exabyte]

I am too sure on this.

I am preparing to install OpenSuse v10 32-bit on my pc. This pc is for
testing my C programs, which will eventually be transferred to my internet
host which is running the 64-bit version.

Can my programs run ?

Off my head I think they should, but the reverse may not. Please correct me.

Do I have to pick the correct compiler ? Thanks.

[sl@exabyte]

sl@exabyte wrote:
> I am too sure on this.
>
> I am preparing to install OpenSuse v10 32-bit on my pc. This pc is for
> testing my C programs, which will eventually be transferred to my
> internet host which is running the 64-bit version.
>

Sorry Java and C programs (I think I need not post it to the C/C++ group).

[Arne Vajhøj]

Pure Java:

Run with 32 Run with 64
Build with 32 yes yes
Build with 64 yes yes


Pure C:

Run on 32 Run on 64
Build for 32 yes yes
Build for 64 no yes

Mix of Java and C via JNI:

Run on/with 32 Run on/with 64
Build for 32 yes no
Build for 64 no yes

Arne

[Cholo Lennon]

The OP can still run a 32-bit JNI java/C application on 64-bit: He/She
just needs to use a 32-bit JVM.

> Build for 64 no yes
>

Best Regards


--
Cholo Lennon
Bs.As.
ARG

[Arne Vajhøj]

On 11/14/2012 12:11 PM, Cholo Lennon wrote:

> On 14/11/2012 11:12, Arne Vajh�j wrote:
>> On 11/14/2012 8:58 AM, sl@exabyte wrote:
>>> I am too sure on this.
>>>
>>> I am preparing to install OpenSuse v10 32-bit on my pc. This pc is for
>>> testing my C programs, which will eventually be transferred to my
>>> internet
>>> host which is running the 64-bit version.
>>>
>>> Can my programs run ?
>>>
>>> Off my head I think they should, but the reverse may not. Please
>>> correct me.
>>>
>>> Do I have to pick the correct compiler ?
>>
>> Pure Java:
>>
>> Run with 32 Run with 64
>> Build with 32 yes yes
>> Build with 64 yes yes
>>
>>
>> Pure C:
>>
>> Run on 32 Run on 64
>> Build for 32 yes yes
>> Build for 64 no yes
>>
>> Mix of Java and C via JNI:
>>
>> Run on/with 32 Run on/with 64
>> Build for 32 yes no
>
> The OP can still run a 32-bit JNI java/C application on 64-bit: He/She
> just needs to use a 32-bit JVM.

Yes.

What do you think "with 64" meant?

>> Build for 64 no yes

Arne

[Joerg Meier]

On Wed, 14 Nov 2012 12:14:56 -0500, Arne Vajh�j wrote:

> On 11/14/2012 12:11 PM, Cholo Lennon wrote:
>> On 14/11/2012 11:12, Arne Vajh�j wrote:
>>> On 11/14/2012 8:58 AM, sl@exabyte wrote:
>>>> I am preparing to install OpenSuse v10 32-bit on my pc. This pc is for
>>>> testing my C programs, which will eventually be transferred to my
>>>> internet
>>>> host which is running the 64-bit version.

>>>> Can my programs run ?

>>> Mix of Java and C via JNI:

>>> Run on/with 32 Run on/with 64
>>> Build for 32 yes no
>>
>> The OP can still run a 32-bit JNI java/C application on 64-bit: He/She
>> just needs to use a 32-bit JVM.
> Yes.

> What do you think "with 64" meant?

The answer to the OPs question - can a program compiled on 32 bit SuSE run
on 64 bit SuSE. To which your answer would be wrong, because you addressed
whether or not it would run on the 64-bit-VM, but there is no reason to
assume his "internet host" would be incapable of also running a 32-bit-VM.

Unless I missunderstand how Java and JNI works - are you saying a 64-bit-OS
is incapable of running 32-bit-JNI programs, even with a 32-bit-VM ?

In other words, it seems like you answered a different question than the OP
wanted the answer for.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

[Jan Burse]

Arne Vajhøj schrieb:

> Pure Java:
>
> Run with 32 Run with 64
> Build with 32 yes yes
> Build with 64 yes yes

There are different shades of 64-bit I guess,
i.e. the -XX:+UseCompressedOops option. Not sure
how this influences C interaction.

Bye

[sl@exabyte]

Joerg Meier wrote:
>
> The answer to the OPs question - can a program compiled on 32 bit
> SuSE run on 64 bit SuSE. To which your answer would be wrong, because
> you addressed whether or not it would run on the 64-bit-VM, but there
> is no reason to assume his "internet host" would be incapable of also
> running a 32-bit-VM.
>
> Unless I missunderstand how Java and JNI works - are you saying a
> 64-bit-OS is incapable of running 32-bit-JNI programs, even with a
> 32-bit-VM ?
>
> In other words, it seems like you answered a different question than
> the OP wanted the answer for.
>

It seems there are more than I have asked.

I don't know what JVM is the host running, it just states OpenSuse v11
64-bit, and I just suppose it is JVM 64-bit.

And I suppose only hardware with 64-bit address bus can run 64-bit OS.

[Stuart]

On 11/15/12 sl@exabyte wrote:
[snip]

> And I suppose only hardware with 64-bit address bus can run 64-bit OS.

Wrong. Typical 64 bit processors have either a 36 bit or a 40 bit
physical address bus (40 bits are 1 TB, an almost incredible amount of
RAM, wikipedia mentions that some AMD chips even offer a 48 bit memory
bus). Note that bus width and register width do not have to have a
one-to-one relationship. The early 286 processor had a register width of
16 bits but an address bus with 24 bits (4MB), so they had to invent
this segmentation model in order to compute a 20bit address from two 16
bit registers. Twenty years later, the segmenation unit is still present
at the Intel architecture while the numbers have been reversed: now the
36 or 40 bit physical address is computed from a 16 bit value and a 64
bit value. Sounds like overkill, and yes, it is. That's just for
backwards compatibility for applications from 1985.

Regards,
Stuart

[SL@maxis]

On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <DerT...@web.de> wrote:

>
> Wrong. Typical 64 bit processors have either a 36 bit or a 40 bit
> physical address bus (40 bits are 1 TB, an almost incredible amount of
> RAM, wikipedia mentions that some AMD chips even offer a 48 bit memory
> bus). Note that bus width and register width do not have to have a
> one-to-one relationship. The early 286 processor had a register width of
> 16 bits but an address bus with 24 bits (4MB), so they had to invent
> this segmentation model in order to compute a 20bit address from two 16
> bit registers. Twenty years later, the segmenation unit is still present
> at the Intel architecture while the numbers have been reversed: now the
> 36 or 40 bit physical address is computed from a 16 bit value and a 64
> bit value. Sounds like overkill, and yes, it is. That's just for
> backwards compatibility for applications from 1985.
>
> Regards,
> Stuart

Thanks. I am not too sure now :-(

I have an old Intel Pentium 4 1500Mhz PC. Can it run 64-bit OS ?


--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[BGB]

corrections:
24 bits is 16MB (because 2^24 = 16777216), this bus size was used by
both the 286 and 386SX (the 386DX and 486 used full 32-bits);
the segments:offset -> 20 bit address thing was there since the 8086,
which could only address 1MB of RAM (in contrast to 64kB on the 8080);
on current 64-bit chips, the segmentation is also non-functional in 64
bit mode with the partial exception of the FS and GS segments (used
mostly for implementing TLS and similar).

(so, while the segment registers are still present, they don't really do
all that much anymore).

in effect, the chip is using a 64-bit flat address model, but may remap
the addresses mostly through the use of page-based address translation
(which maps from the program's virtual address space to the physical/RAM
address space).

yes, the CPU has backwards compatibility, but it actually involves a
fair amount of mode-changing (as control is passed from one program to
another, the CPU mode changes), but there are limits to this.

however, real-mode software (IOW: most of the software from 1985) can't
actually run on the CPU if it is running in "long mode", so it actually
requires use of either hardware emulation or virtualization to make this
work (for example, DOSbox does emulation, and VMware does virtualization).

as-is, about the oldest software that can be run directly in modern
Windows is roughly mid-to-late 90s era software (IOW: from when the
world moved solidly over to 32 bits), although the hardware can
technically still support running 16-bit protected-mode software in
long-mode (theoretically, MS could have made Win3.x apps work without
emulation, had they wanted to do so...).


or such...

[BGB]

it may or may not run 64-bits (depending on the specific core it has),
you would have to test and see if it does or not.

one way to test easily would be to get a Linux live-cd for x86-64. if it
boots up, the CPU does 64-bit, and if it refuses to boot up with an
error message about the type of CPU, then the CPU doesn't support it.

[Stuart]

On 11/15/2012 5:08 PM, Stuart wrote:

[snip]

>> The early 286 processor had a register width of
>> 16 bits but an address bus with 24 bits (4MB), so they had to invent
>> this segmentation model in order to compute a 20bit address from two 16
>> bit registers.

On 11/16/12 5:46 BGB wrote:
> corrections:
> 24 bits is 16MB (because 2^24 = 16777216), this bus size was used by
> both the 286 and 386SX (the 386DX and 486 used full 32-bits);
> the segments:offset -> 20 bit address thing was there since the 8086,
> which could only address 1MB of RAM (in contrast to 64kB on the 8080);
> on current 64-bit chips, the segmentation is also non-functional in 64
> bit mode with the partial exception of the FS and GS segments (used
> mostly for implementing TLS and similar).

Gosh, I got it all mixed up. Of course 24 bits is 16MB. I can't say
where my brain got the number 4MB from, probably because most 286 boards
could only handle 4MBs of memory at that time. Or was that only for EMS
modules?

> (so, while the segment registers are still present, they don't really do
> all that much anymore).

I don't know. As far as I can see it, it should still be possible under
a 64 bit processor to set up segment based memory protection using call
gates and such, so all the privilege level checking stuff should still
be present in 64 bit CPUs (albeit noone uses it anymore).

> in effect, the chip is using a 64-bit flat address model, but may remap
> the addresses mostly through the use of page-based address translation
> (which maps from the program's virtual address space to the physical/RAM
> address space).
>
> yes, the CPU has backwards compatibility, but it actually involves a
> fair amount of mode-changing (as control is passed from one program to
> another, the CPU mode changes), but there are limits to this.
>
> however, real-mode software (IOW: most of the software from 1985) can't
> actually run on the CPU if it is running in "long mode", so it actually
> requires use of either hardware emulation or virtualization to make this
> work (for example, DOSbox does emulation, and VMware does virtualization).
>
> as-is, about the oldest software that can be run directly in modern
> Windows is roughly mid-to-late 90s era software (IOW: from when the
> world moved solidly over to 32 bits), although the hardware can
> technically still support running 16-bit protected-mode software in
> long-mode (theoretically, MS could have made Win3.x apps work without
> emulation, had they wanted to do so...).

Um, does that mean that I can no longer install DOS on a modern 64 bit
PC? Not so long ago I bought a HP laptop without an OS (planned to run
Linux on it). It shipped with FreeDOS. Awesome. Reminded me of the good
old times when we messed with the LAN cards of four PCs for hours just
to be able to play Doom2 on Christmas Eve.

Regards,
Stuart

[Anonymous]

Stuart <DerT...@web.de> wrote:

> On 11/15/12 sl@exabyte wrote:
> [snip]
> > And I suppose only hardware with 64-bit address bus can run 64-bit OS.
>
> Wrong. Typical 64 bit processors have either a 36 bit or a 40 bit
> physical address bus (40 bits are 1 TB, an almost incredible amount of
> RAM, wikipedia mentions that some AMD chips even offer a 48 bit memory
> bus).

IBM offers a 64 bit data bus for a theoretical max storage 2^64
bytes. Unfortunately they only support 256T the heartless bastards! ;-)

[Roedy Green]

On Thu, 15 Nov 2012 10:48:38 +0800, "sl@exabyte" <sb5...@hotmail.com>
wrote, quoted or indirectly quoted someone who said :

>
>I don't know what JVM is the host running, it just states OpenSuse v11
>64-bit, and I just suppose it is JVM 64-bit.

run wassup on it.

see http://mindprod.com/applet/wassup.html
--
Roedy Green Canadian Mind Products http://mindprod.com
Types of Garbage Collection:
()In Canada, the government sends men to your house every every week
to take away your garbage. Hoarders are free to hang onto things
they don’t really need.
()In third world countries, it is up to you to take your own garbage away.
()Java’s garbage collection system is analogous to a garbage removal
system where every hour, workers scan your house for junk mail, the
contents of waste baskets and anything else they are absolutely sure you
don’t want to keep.
()C++’s system for disposing of unreferenced objects is similar to India’s,
with the strange feature that undiscarded garbage becomes invisible but
still stinks.

[Fritz Wuehler]

No standard 64 bit OS will run on a P4.

[BGB]

On 11/16/2012 5:08 AM, Stuart wrote:
> On 11/15/2012 5:08 PM, Stuart wrote:
> [snip]
>>> The early 286 processor had a register width of
>>> 16 bits but an address bus with 24 bits (4MB), so they had to invent
>>> this segmentation model in order to compute a 20bit address from two 16
>>> bit registers.
>
> On 11/16/12 5:46 BGB wrote:
>> corrections:
>> 24 bits is 16MB (because 2^24 = 16777216), this bus size was used by
>> both the 286 and 386SX (the 386DX and 486 used full 32-bits);
>> the segments:offset -> 20 bit address thing was there since the 8086,
>> which could only address 1MB of RAM (in contrast to 64kB on the 8080);
>> on current 64-bit chips, the segmentation is also non-functional in 64
>> bit mode with the partial exception of the FS and GS segments (used
>> mostly for implementing TLS and similar).
>
> Gosh, I got it all mixed up. Of course 24 bits is 16MB. I can't say
> where my brain got the number 4MB from, probably because most 286 boards
> could only handle 4MBs of memory at that time. Or was that only for EMS
> modules?
>

can't really say there.

the motherboards may have set smaller limits, given that was a fairly
large amount of memory at the time.

>> (so, while the segment registers are still present, they don't really do
>> all that much anymore).
>
> I don't know. As far as I can see it, it should still be possible under
> a 64 bit processor to set up segment based memory protection using call
> gates and such, so all the privilege level checking stuff should still
> be present in 64 bit CPUs (albeit noone uses it anymore).
>

yes, things like gates and interrupts still work, just you can't use
segmented addressing with 64-bit code (as in, the part where the segment
base address is added to the virtual address to get another address).

in 32-bit mode, the segments could still do this, just 32-bit OS's
didn't really bother to do so (it was much more convenient simply to use
a single large flat 4GB address space).


basically, if all the segment registers really do is give things like
the operating mode and protection-level, and are basically set up by the
OS and largely ignored by code, this isn't really doing a whole lot.

FWIW: they could at this point almost just as easily remove segmentation
entirely, and application software wouldn't really notice (although the
OS would notice).

the partial exception here was FS and GS, which operating systems use
for accessing TLS variables and similar. these segments are handled
specially by the processor.

>> in effect, the chip is using a 64-bit flat address model, but may remap
>> the addresses mostly through the use of page-based address translation
>> (which maps from the program's virtual address space to the physical/RAM
>> address space).
>>
>> yes, the CPU has backwards compatibility, but it actually involves a
>> fair amount of mode-changing (as control is passed from one program to
>> another, the CPU mode changes), but there are limits to this.
>>
>> however, real-mode software (IOW: most of the software from 1985) can't
>> actually run on the CPU if it is running in "long mode", so it actually
>> requires use of either hardware emulation or virtualization to make this
>> work (for example, DOSbox does emulation, and VMware does
>> virtualization).
>>
>> as-is, about the oldest software that can be run directly in modern
>> Windows is roughly mid-to-late 90s era software (IOW: from when the
>> world moved solidly over to 32 bits), although the hardware can
>> technically still support running 16-bit protected-mode software in
>> long-mode (theoretically, MS could have made Win3.x apps work without
>> emulation, had they wanted to do so...).
>
> Um, does that mean that I can no longer install DOS on a modern 64 bit
> PC? Not so long ago I bought a HP laptop without an OS (planned to run
> Linux on it). It shipped with FreeDOS. Awesome. Reminded me of the good
> old times when we messed with the LAN cards of four PCs for hours just
> to be able to play Doom2 on Christmas Eve.
>

the CPU will still run DOS, just not while running in "Long Mode".

this means you can still install DOS and Win9x on the computer, and they
will work as before.

but, if you boot up a 64-bit OS, then this OS can no longer run any DOS
code (unless it switches back out of long-mode, but it would be fairly
complicated and expensive to make an OS which does this).


basically, a way of thinking about it is that the CPU has several major
operating modes:
Real-Mode (AKA: "Legacy Mode");
Protected-Mode;
and Long-Mode.

and several sub-modes:
Protected-Mode: PM-32, PM-16, VM-86;
Long-Mode: Compatibility-32, Compatibility-16, Long-Mode-64.

VM-86 basically looks like a 16-bit real-mode address space, but it may
actually be located anywhere in memory.

when running DOS apps inside Windows, they would run in VM-86 mode.
given long-mode doesn't have VM-86 mode available, then the OS can't run
them.

MS decided while they were at it, to drop PM-16 as well, which basically
also broke all of the Windows 3.x era apps.


hence, this is part of the reason for needing things like DOSBox (or
running Win98 in VMware, which allows both DOS and Win3.x apps to run,
apart from the realization of just how crash-prone Win98 actually was,
like one goes about doing stuff for several hours and it blue-screens, ...).

DOSbox is basically an emulator which works either via interpretation
(faking the CPU and hardware entirely in software) or via dynamic
translation (dynamically rewriting the real-mode code into a form which
can run on a modern CPU).

VMware works by using virtualization, which gets a little more strange
(it involves nesting the page translation and processor state). in this
case, even though the host-OS is running in long-mode, the OS running
inside the emulator may be running in a different CPU mode.

[Joerg Meier]

On Fri, 16 Nov 2012 16:44:15 +0100, Fritz Wuehler wrote:

> No standard 64 bit OS will run on a P4.

I assure you both a default Windows XP 64 Bit CD and well as a defaul Linux
64 Bit CD ran perfectly fine on my old P4 before it was finally retired.
Nothing special was needed.

[BGB]

On 11/17/2012 6:18 AM, Joerg Meier wrote:
> On Fri, 16 Nov 2012 16:44:15 +0100, Fritz Wuehler wrote:
>
>> No standard 64 bit OS will run on a P4.
>
> I assure you both a default Windows XP 64 Bit CD and well as a defaul Linux
> 64 Bit CD ran perfectly fine on my old P4 before it was finally retired.
> Nothing special was needed.
>

the issue is that "P4" covers a fairly wide-range of hardware, where
some of the early hardware under the P4 name did not include 64-bit
support, they enabled it for later cores.

so, it depends on which core it has, for example, a P4 with a Willamette
or Northwood core will not have 64-bit support, but a P4 with a Prescott
or Cedar Mill core will have 64-bit support.

granted, an issue with some earlier computers with 64-bit support was
that, even if the CPU supports it, sometimes the MOBO would not, or
would not operate reliably in 64-bit mode.


for example, I had a computer with a ClawHammer core running on a MOBO
using Socket-754 (built around early/mid 2004), and although a plenty
usable computer, it did not run reliably in 64-bit mode.

[Stuart]

Am 11/17/12 1:08 AM, schrieb BGB:

Thanks for sharing.

Stuart