If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#31
|
|||
|
|||
X86 vs X64
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 Mayayana wrote: "Dan Purgert" wrote | Non-PAE systems would page memory though effectively one layer of | indirection (basically, page 0x1880BEAD ultimately corresponds to the | byte at that RAM address[1]). | | PAE systems on the other hand use two layers -- the first layer | selecting which of up to 16 banks are in play, and then the second | mapping that page to the given bank of addresses. Yet Windows itself would be dealing in 32-bit numbers, no? So you're saying that associating my pointer with an actual physical offset in RAM is a physical operation, done in hardware, and that the Windows kernel is not tracking were my virtual offset points to in physical memory? Not really. Maybe this'll help.. I hope. 32-bit, non-PAE - Program asks kernel to access memory address 0x1800BEAD. Kernel tells hardware to enable 0x1800BEAD. Process reads from / writes to physical memory 0x1800BEAD. 32-bit, PAE - Program asks kernel to access memory address 0x1800BEAD. Kernel performs a lookup "PID 1237, memory 0x1800BEAD ... OK, bank 12". Kernel then asks hardware to give it bank 12, address 0x1800BEAD. Process reads from / writes to physical memory location 0x*C*1800BEAD. Please note that the above is somewhat (over) simplified. It's been a long (LONG) time since I looked at x86 hardware in this detail. -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl37Zo oACgkQjhHd8xJ5 ooFCuQgAgReqrieDjapVFB9zwJl7zDWMI7gMwqZVt1wTNdEfJx Cn4uqjPe6hgfQe 9kjIKv+07edkUzpm3vjZHJzzQGKqF5GWrHj7GoS/2X0Fi1kYMG+wbVGZu6xZ1dxR yCvbSHHpSPCk1KCifKAEEshn9DyAhbREgy0x+RkDKB69WOEGbc L/3+rsKC4yecHA zOkMtRsObaC+eEIlst09LlVphGK6Enbq1o9ri5Y1gKe0Gr6PXN EieRQB87U9H0r/ etLnTboth+9Rx549K3HvcZmZoF8fUN3i9XnGFZ/C4SO5YzSZS86pltEsPAQDTbJH 4zo/Je5JMA4PHVUoGle5iRF/VqoGww== =Pxc6 -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 |
Ads |
#32
|
|||
|
|||
X86 vs X64
"Dan Purgert" wrote
| 32-bit, PAE - Program asks kernel to access memory address 0x1800BEAD. | Kernel performs a lookup "PID 1237, memory 0x1800BEAD ... OK, bank 12". | Kernel then asks hardware to give it bank 12, address 0x1800BEAD. | Process reads from / writes to physical memory location 0x*C*1800BEAD. | Bank 12? What I'm trying to grasp is how can an OS operating with 32-bit manage 36-bit? So much is pointers. If I do something as simple as calling the kernel to get the Windows version, I get a pointer to the data. A 32-bit pointer. There's no "bank" involved. I can sort of understand that my pointer may be a virtual pointer, only valid in my process, referring to a physical address that's actually managed by the hardware, but I don't understand how that happens. More critically, I don't understand how the kernel can surpass 32-bit. Something has to have an overview of all physical addresses. I can see how a swap file could fill in, but I don't see how actual RAM can be used. If 4 programs and Windows all have multi-GB memory space, then I see how each could have a virtual range that the processor converts to physical addresses. (And by implication, the OS can't directly access the RAM but must do it through the CPU?) But then how can the kernel give me a pointer, and give all the other programs pointers in a 36-bit range, if it only knows 32-bit? Is it that the kernel itself never actually sees physical addresses, but only asks some kind of controller chip to provide it? So I guess the analogy of what I'm picturing would be that the kernel is a dumb intermediary, going to the supply house for memory allotments, and employing an additional system of labels to keep those straight. I don't see any other possibility. The 32-bit kernel can't count beyond 4B physical addresses. You seem to be implying that it's using process IDs for a label. Is that basically the deal? But then the CPU has to keep an overview record of where it put the data at 0x1800BEAD for program #3? And that's done in some kind of RAM area allotted to the CPU itself? This is beginning to sound like government bureaucracy. I had no idea it was so complicated. I'm afraid this is the trouble coming from VB. I have to learn backward and have never had an education in the actual nuts and bolts below OS API. |
#33
|
|||
|
|||
X86 vs X64
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 Mayayana wrote: "Dan Purgert" wrote | 32-bit, PAE - Program asks kernel to access memory address 0x1800BEAD. | Kernel performs a lookup "PID 1237, memory 0x1800BEAD ... OK, bank 12". | Kernel then asks hardware to give it bank 12, address 0x1800BEAD. | Process reads from / writes to physical memory location 0x*C*1800BEAD. | Bank 12? What I'm trying to grasp is how can an OS operating with 32-bit manage 36-bit? So It doesn't. It uses two different numbers -- one for the "bank", and the other for the memory address. The CPU (or rather the memory controller) is capable of working with 36 bit addresses (basically it just has more address pins) though. For a non-PAE system (kernel + hardware), you can think of the RAM as a 1-dimensional array. A kernel API interface (such as might be used by a 32-bit application, say Photoshop) may look something like this: public byte getDataFromRAM (address as int) { return RAM[address]; } Once you hit the limit of "int", you can't address any more RAM. 4G is your limit, end of story. For a PAE-enabled system (kernel + hardware), you can think of the RAM as a 2-dimensional array. A few things need to be added / changed in the kernel programming interfaces. public byte getDataFromRAM (address as int) { dim pae,data as byte; pae=getPAEOffset(getPIDOfCaller()); data=PAE_getDataAtAddress (address,callingPID); return data; } private byte PAE_getDataAtAddress (address as int, pae as byte) { return RAM[pae][address]; } The original calling program doesn't know that the "getDataFromRAM" call has changed -- it still gets the byte it expects. But the kernel is now able to ask the hardware about 1TB of RAM (~4GB per bank * 256 banks). Cut out the rest of your questions, since I *THINK* that I got to the actual meat of them in the above. (or at least I hope I did ) -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl37oZ MACgkQjhHd8xJ5 ooEsaAf/fEoMkauqc+gb68kldnbHrKCdiODHnFIb0cIS+RIZOr02JdHGx+ jKuWKq Z+oWD5UO3GvQ4hR1uGv3R0LawzhQFZrr3y2vNhcMhjrvRqI1QR 4MobElO4Kf31Tp 8RL0HQG3PBeUotskAmMVmdKi38kWIEtoSoV6w4hEsbw/zeJBi1HYfybyVUAWnBNm A6X0nnwy75dEHCAeYxNHLMfLyrbfBwpEjRN8Dw3Q/mFl//5e79QLt75d4HxSCFzs XORAzkpFYFUNxH1BDUYrwN1y0o2rN1B3xtbs/6wYzdJg/dxFG3ZEaSQbC4PhbIhX t2lVhh2GMi6jonLZZ/EYOGN5g9ZgRQ== =mcl4 -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 |
#34
|
|||
|
|||
X86 vs X64
On 12/17/2019 7:04 PM, Lucifer wrote:
On a device with 4 gigs RAM is 64 bit windows better than 32 bit? You cannot be wrong with 64-bit! 32-bit programs can still be run. -- @~@ Remain silent! Drink, Blink, Stretch! Live long and prosper!! / v \ Simplicity is Beauty! /( _ )\ May the Force and farces be with you! ^ ^ (x86_64 Ubuntu 9.10) Linux 2.6.39.3 ¤£*ɶU! ¤£¶BÄF! ¤£½ä¿ú! ¤£´©¥æ! ¤£¥´¥æ! ¤£¥´§T! ¤£¦Û±þ! ¤£¨D¯«! ½Ð¦Ò¼{ºî´© (CSSA): http://www.swd.gov.hk/tc/index/site_...sub_addressesa |
#35
|
|||
|
|||
X86 vs X64
On 17/12/2019 13:16, Wolffan wrote:
At this late date there’s really no reason to not use 64-bit. There is if you want to run a 16 bit legacy application. It will still work fine on 32 bit Windows 10 but not on 64 bit because MS removed the sub system. |
#36
|
|||
|
|||
X86 vs X64
On 19/12/2019 16:22, Mr. Man-wai Chang wrote:
On 12/17/2019 7:04 PM, Lucifer wrote: On a device with 4 gigs RAM is 64 bit windows better than 32 bit? You cannot be wrong with 64-bit! 32-bit programs can still be run. Yes but 16 bit legacy programs cannot. Some of us still use them and need to resort to a VM. |
#37
|
|||
|
|||
X86 vs X64
"Dan Purgert" wrote
| Cut out the rest of your questions, since I *THINK* that I got to the | actual meat of them in the above. (or at least I hope I did ) | I think so. Thanks. I still don't get all the specifics but I can see how it could work if the CPU is running the banks. |
#38
|
|||
|
|||
X86 vs X64
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256 Mayayana wrote: "Dan Purgert" wrote | Cut out the rest of your questions, since I *THINK* that I got to the | actual meat of them in the above. (or at least I hope I did ) | I think so. Thanks. I still don't get all the specifics but I can see how it could work if the CPU is running the banks. Good I was kinda worried I'd only muddy the waters after I sent it. Unfortunately the "specifics" amount to getting into assembly and CPU registers / physical pins (and motherboard traces, etc). We've barely scratched the surface here ... -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEBcqaUD8uEzVNxUrujhHd8xJ5ooEFAl37ry 4ACgkQjhHd8xJ5 ooH9uQf+NSh4mig6/NiZOfws4ugVhzlbKPZvqTVaEtU9Q8r+DeKgz64N9AZOMrmc /V+UGBh3b1xV0OliyinZdQmMnQZKwOSBDz8UvGVY3MvrwoiWNLd lqiY104DC5/WI ue+kyd7vXteIME06QsdvCN+qLkBXVEVnOrb/kmp+PkHBzIpNGksuO0FAOZrS7/Bt WoxSM/gUd1yJr08RwKLx4kASzQREyVvIKHwwfvamE8ChNa1K5BakBLVN SWIADPla nl+zj2fV+VhoA/uRHdjSs4wkSckfehRzZQTQPhsD9xQUDUMehoBRl7gjaI5V1AUA Byk+ipRmEwr2kWVeC8cJuRoSC4q1/A== =qxQT -----END PGP SIGNATURE----- -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5 4AEE 8E11 DDF3 1279 A281 |
#39
|
|||
|
|||
X86 vs X64
Mayayana wrote:
"Dan Purgert" wrote | Cut out the rest of your questions, since I *THINK* that I got to the | actual meat of them in the above. (or at least I hope I did ) | I think so. Thanks. I still don't get all the specifics but I can see how it could work if the CPU is running the banks. An individual CPU core, only gets to run one process at a time ("Notepad"), and the "context" of a run of that process is set up for the process before it gets to run. If there is some notion of a "bank 0xC", the kernel/scheduler can set that up before the process runs for one time slice. That should be sufficient to set up the TLB so it's pointing at the context that a particular copy of Notepad would want. If three copies of Notepad are running, they can share the same code segment (which is read only, self-modifying code no longer being allowed). Virt Phys Notepad C ---| T | Notepad D ---| L |--- one copy of code segment Notepad E ---| B | Notepad can then access a 4GB space (out of potentially 64GB handled by early PAE), and this space could be anywhere in the 64GB area (if only Microsoft would let it work that way). The Memory License on x86 OS installations, is ostensibly there to prevent the need for "bounce buffers" for PCI cards with 64 bit address capability (data the PCI card needs is located above 4GB, and the PCI bus does two address cycles to transfer a 64 bit address). But Mark Russinovich, before he became a Microsoft employee, debunked this notion, saying as far as he was concerned, there was no hardware out there which would "suffer" if a PAE OS accessed memory above 4GB and allowed larger spaces (64GB) to be used. The experiment by Geoff Chappelle, to bypass the Memory License, there was no problem with his x86 copy of Vista, using memory anywhere in the 8GB he had installed. No I/O broke. There was no sign of an immediate catastrophe. Paul |
#40
|
|||
|
|||
X86 vs X64
Ken Blake wrote:
On 12/17/2019 6:16 AM, Wolffan wrote: On 17 Dec 2019, Lucifer wrote (in ): On a device with 4 gigs RAM is 64 bit windows better than 32 bit? using 64-bit introduces extra overhead, and 32-bit would work fine. But... 1 Microsoft, Apple, and many Linux distros are currently phasing out 32-bit. After a while a 32-bit system will no longer be supported. Yes. None of us knows when, but it probably won't be a whole lot longer. MacOS and iOS are already 64bit only. |
#41
|
|||
|
|||
X86 vs X64
On 19 Dec 2019, Chris wrote
(in article ): Ken Blake wrote: On 12/17/2019 6:16 AM, Wolffan wrote: On 17 Dec 2019, Lucifer wrote (in ): On a device with 4 gigs RAM is 64 bit windows better than 32 bit? using 64-bit introduces extra overhead, and 32-bit would work fine. But... 1 Microsoft, Apple, and many Linux distros are currently phasing out 32-bit. After a while a 32-bit system will no longer be supported. Yes. None of us knows when, but it probably won't be a whole lot longer. MacOS and iOS are already 64bit only. MacOS is 64-bit only as of Catalina, out in Sept/Oct this year. Earlier versions still do 32-bit. Several of the Macs I run don’t run Catalina. Several of those _can’t_ run Catalina. My beige G3, for example, can’t run anything beyond Jaguar. (Yes, I tried to install Panther. Yes, it wasn’t a good idea. Yes I restored Jag from backup. Yes, the beige still works. It’s slow, but it works.) |
#42
|
|||
|
|||
X86 vs X64
On 19/12/2019 22:41, Wolffan *STALKING*????
On 19 Dec 2019, Chris wrote (in article ): Ken Blake wrote: On 12/17/2019 6:16 AM, Wolffan wrote: On 17 Dec 2019, Lucifer wrote (in ): On a device with 4 gigs RAM is 64 bit windows better than 32 bit? using 64-bit introduces extra overhead, and 32-bit would work fine. But... 1 Microsoft, Apple, and many Linux distros are currently phasing out 32-bit. After a while a 32-bit system will no longer be supported. Yes. None of us knows when, but it probably won't be a whole lot longer. MacOS and iOS are already 64bit only. MacOS is 64-bit only as of Catalina, out in Sept/Oct this year. Earlier versions still do 32-bit. Several of the Macs I run don’t run Catalina. Several of those _can’t_ run Catalina. My beige G3, for example, can’t run anything beyond Jaguar. (Yes, I tried to install Panther. Yes, it wasn’t a good idea. Yes I restored Jag from backup. Yes, the beige still works. It’s slow, but it works.) Why are you Trolling on a Windows 10 group? |
#43
|
|||
|
|||
X86 vs X64
On Tue, 17 Dec 2019 11:10:30 -0000 (UTC), Dan Purgert
wrote: Lucifer wrote: On a device with 4 gigs RAM is 64 bit windows better than 32 bit? Yes, if for nothing more than "you can enumerate all 4G". In the BIOS setup of my Panasonic Toughpad it shows how much RAM will be available for 32 and 64 bit OS. |
#44
|
|||
|
|||
X86 vs X64
On Tue, 17 Dec 2019 08:16:40 -0500, Wolffan
wrote: On 17 Dec 2019, Lucifer wrote (in ): On a device with 4 gigs RAM is 64 bit windows better than 32 bit? using 64-bit introduces extra overhead, and 32-bit would work fine. But... 1 Microsoft, Apple, and many Linux distros are currently phasing out 32-bit. After a while a 32-bit system will no longer be supported. 2 if you ever put more RAM onto the system, you would need to go to 64-bit. 3 Microsoft makes moving from 32-bit to 64-bit painful. Apple and Linux do a much better job. Id install 64-bit and live with the extra overhead, or just install more RAM and make the overhead moot. Frankly, Ive installed 64-bit on Windows 4 GB systems starting with Vista. (Do NOT install 64-bit XP. You have been warned.) On Apple and Linux systems Ive been going with 64-bit since it was an option. At this late date theres really no reason to not use 64-bit. That makes sense. I don't think I can upgrade the RAM in my Toughpad. |
#45
|
|||
|
|||
X86 vs X64
On Tue, 17 Dec 2019 14:43:12 -0000 (UTC), Dan Purgert
wrote: Wolffan wrote: On 17 Dec 2019, Lucifer wrote (in ): On a device with 4 gigs RAM is 64 bit windows better than 32 bit? using 64-bit introduces extra overhead, and 32-bit would work fine. This statement depends on a few other questions though. Does the 32-bit OS support PAE? What about the processor? I had a server with eight Pentium 3 900 Mhz CPUs and 8 GB RAM. That's when I discovered PAE. It also had 4 x 15,000 RPM SCSI hard drives. |
Thread Tools | |
Display Modes | Rate This Thread |
|
|