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

Groups > comp.lang.java.programmer > #19775

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

Show all headers | View raw

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

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web