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

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

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

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

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.

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.

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

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

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

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.

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

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?

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.

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.

I’d install 64-bit and live with the extra overhead, or just install more
RAM and make the overhead moot. Frankly, I’ve 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 I’ve been going with 64-bit since it
was an option. At this late date there’s really no reason to not use
64-bit.

That makes sense. I don't think I can upgrade the RAM in my Toughpad.

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.