Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #19747 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  Program in 32-bit, run on 64-bit OK? "sl@exabyte" <sb5309@hotmail.com> - 2012-11-14 21:58 +0800
    Re: Program in 32-bit, run on 64-bit OK? "sl@exabyte" <sb5309@hotmail.com> - 2012-11-14 22:01 +0800
    Re: Program in 32-bit, run on 64-bit OK? Arne Vajhøj <arne@vajhoej.dk> - 2012-11-14 09:12 -0500
      Re: Program in 32-bit, run on 64-bit OK? Cholo Lennon <chololennon@hotmail.com> - 2012-11-14 14:11 -0300
        Re: Program in 32-bit, run on 64-bit OK? Arne Vajhøj <arne@vajhoej.dk> - 2012-11-14 12:14 -0500
          Re: Program in 32-bit, run on 64-bit OK? Joerg Meier <joergmmeier@arcor.de> - 2012-11-14 18:36 +0100
            Re: Program in 32-bit, run on 64-bit OK? "sl@exabyte" <sb5309@hotmail.com> - 2012-11-15 10:48 +0800
              Re: Program in 32-bit, run on 64-bit OK? Stuart <DerTopper@web.de> - 2012-11-16 00:08 +0100
                Re: Program in 32-bit, run on 64-bit OK? "SL@maxis" <ecp_gen@my-rialto.com> - 2012-11-16 09:23 +0800
                  Re: Program in 32-bit, run on 64-bit OK? BGB <cr88192@hotmail.com> - 2012-11-15 22:52 -0600
                  Re: Program in 32-bit, run on 64-bit OK? Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-16 16:44 +0100
                    Re: Program in 32-bit, run on 64-bit OK? Joerg Meier <joergmmeier@arcor.de> - 2012-11-17 13:18 +0100
                      Re: Program in 32-bit, run on 64-bit OK? BGB <cr88192@hotmail.com> - 2012-11-17 12:42 -0600
                Re: Program in 32-bit, run on 64-bit OK? BGB <cr88192@hotmail.com> - 2012-11-15 22:46 -0600
                  Re: Program in 32-bit, run on 64-bit OK? Stuart <DerTopper@web.de> - 2012-11-16 12:08 +0100
                    Re: Program in 32-bit, run on 64-bit OK? BGB <cr88192@hotmail.com> - 2012-11-16 18:08 -0600
                      Re: Program in 32-bit, run on 64-bit OK? Stuart <DerTopper@web.de> - 2012-11-17 23:59 +0100
                Re: Program in 32-bit, run on 64-bit OK? Anonymous <nobody@remailer.paranoici.org> - 2012-11-16 12:42 +0000
              Re: Program in 32-bit, run on 64-bit OK? Roedy Green <see_website@mindprod.com.invalid> - 2012-11-16 05:17 -0800
      Re: Program in 32-bit, run on 64-bit OK? Jan Burse <janburse@fastmail.fm> - 2012-11-14 20:08 +0100

#19747 — Program in 32-bit, run on 64-bit OK?

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.

[toc] | [next] | [standalone]

#19748

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). 

[toc] | [prev] | [next] | [standalone]

#19749

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
Build for 64          no               yes

Arne

[toc] | [prev] | [next] | [standalone]

#19750

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.


> Build for 64          no               yes
>


Best Regards


-- 
Cholo Lennon
Bs.As.
ARG

[toc] | [prev] | [next] | [standalone]

#19751

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

[toc] | [prev] | [next] | [standalone]

#19752

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.

[toc] | [prev] | [next] | [standalone]

#19759

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.

[toc] | [prev] | [next] | [standalone]

#19760

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

[toc] | [prev] | [next] | [standalone]

#19761

On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <DerTopper@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/

[toc] | [prev] | [next] | [standalone]

#19763

On 11/15/2012 7:23 PM, SL@maxis wrote:
> On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <DerTopper@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 ?
>
>

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.

[toc] | [prev] | [next] | [standalone]

#19768

"SL@maxis" <ecp_gen@my-rialto.com> wrote:

> On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <DerTopper@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 ?

No standard 64 bit OS will run on a P4.

[toc] | [prev] | [next] | [standalone]

#19772

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.

Liebe Gruesse,
		Joerg

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

[toc] | [prev] | [next] | [standalone]

#19773

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.

[toc] | [prev] | [next] | [standalone]

#19762

On 11/15/2012 5:08 PM, Stuart 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). 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.
>

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...

[toc] | [prev] | [next] | [standalone]

#19764

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

[toc] | [prev] | [next] | [standalone]

#19769

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.

[toc] | [prev] | [next] | [standalone]

#19775

Am 11/17/12 1:08 AM, schrieb 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.
>

Thanks for sharing.

Stuart

[toc] | [prev] | [next] | [standalone]

#19766

Stuart <DerTopper@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! ;-)

[toc] | [prev] | [next] | [standalone]

#19767

On Thu, 15 Nov 2012 10:48:38 +0800, "sl@exabyte" <sb5309@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.

[toc] | [prev] | [next] | [standalone]

#19753

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web