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

Discussion in 'Java' started by Arne Vajhøj, Nov 14, 2012.

  1. Arne Vajhøj

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Nov 14, 2012
    #1
    1. Advertising

  2. Arne Vajhøj

    Cholo Lennon Guest

    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
    Cholo Lennon, Nov 14, 2012
    #2
    1. Advertising

  3. Arne Vajhøj

    Arne Vajhøj Guest

    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
    Arne Vajhøj, Nov 14, 2012
    #3
  4. Arne Vajhøj

    Joerg Meier Guest

    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.
    Joerg Meier, Nov 14, 2012
    #4
  5. Arne Vajhøj

    Jan Burse Guest

    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
    Jan Burse, Nov 14, 2012
    #5
  6. Arne Vajhøj

    sl@exabyte Guest

    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.
    sl@exabyte, Nov 15, 2012
    #6
  7. Arne Vajhøj

    Stuart Guest

    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
    Stuart, Nov 15, 2012
    #7
  8. Arne Vajhøj

    SL@maxis Guest

    On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <> 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/
    SL@maxis, Nov 16, 2012
    #8
  9. Arne Vajhøj

    BGB Guest

    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:eek:ffset -> 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, Nov 16, 2012
    #9
  10. Arne Vajhøj

    BGB Guest

    On 11/15/2012 7:23 PM, SL@maxis wrote:
    > On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <> 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.
    BGB, Nov 16, 2012
    #10
  11. Arne Vajhøj

    Stuart Guest

    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:eek:ffset -> 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
    Stuart, Nov 16, 2012
    #11
  12. Arne Vajhøj

    Anonymous Guest

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


    IBM offers a 64 bit data bus for a theoretical max storage 2^64
    bytes. Unfortunately they only support 256T the heartless bastards! ;-)
    Anonymous, Nov 16, 2012
    #12
  13. Arne Vajhøj

    Roedy Green Guest

    On Thu, 15 Nov 2012 10:48:38 +0800, "sl@exabyte" <>
    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.
    Roedy Green, Nov 16, 2012
    #13
  14. "SL@maxis" <> wrote:

    > On Fri, 16 Nov 2012 07:08:58 +0800, Stuart <> 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.
    Fritz Wuehler, Nov 16, 2012
    #14
  15. Arne Vajhøj

    BGB Guest

    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:eek:ffset -> 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.
    BGB, Nov 17, 2012
    #15
  16. Arne Vajhøj

    Joerg Meier Guest

    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.
    Joerg Meier, Nov 17, 2012
    #16
  17. Arne Vajhøj

    BGB Guest

    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.
    BGB, Nov 17, 2012
    #17
  18. Arne Vajhøj

    Stuart Guest

    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:eek:ffset -> 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
    Stuart, Nov 17, 2012
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jcc
    Replies:
    15
    Views:
    4,698
    Nigel Wade
    May 12, 2006
  2. Replies:
    3
    Views:
    1,743
    Timothy Bendfelt
    Jan 19, 2007
  3. Replies:
    9
    Views:
    968
    Juha Nieminen
    Aug 22, 2007
  4. Jeff.M
    Replies:
    6
    Views:
    172
    Lasse Reichstein Nielsen
    May 4, 2009
  5. sl@exabyte
    Replies:
    0
    Views:
    369
    sl@exabyte
    Nov 14, 2012
Loading...

Share This Page