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


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

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

From BGB <cr88192@hotmail.com>
Newsgroups comp.lang.java.programmer
Subject Re: Program in 32-bit, run on 64-bit OK?
Date 2012-11-16 18:08 -0600
Organization albasani.net
Message-ID <k86koj$3bb$1@news.albasani.net> (permalink)
References (4 earlier) <1ime9q5hlhcfs.x8wnfo60hr9g$.dlg@40tude.net> <k81l6c$oh3$1@news.albasani.net> <k83sma$3qm$1@dont-email.me> <k84gkt$mr0$1@news.albasani.net> <k856qm$aab$1@dont-email.me>

Show all headers | View raw


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.

Back to comp.lang.java.programmer | Previous | NextPrevious 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