Processor:
Pentium Pro Processor

Date
Introduced:
1995

Max. Clock Frequency/Technology at Introduction:
200 MHz

Transistors:
5.5 M

Register Sizes:
32 GP
80 FPU

Ext. Data Bus Size:
64

Max. Extern. Addr. Space:
64 GB

Caches
L1: 16 KB
L2: 256 KB or 512 KB

Quote:

But it is not laid out in contiguous blocks is it. It is broken up by LFB's and I/O buffers.

But these are all in fixed or known locations - all in low conventional memory in the case of 16-bit I/O buffers and at the top of physical memory in the case of the VESA LFB, leaving an easily-managed single large contiguous block in between!

revolution wrote:

I always think of paging as having two major advantages.

• rearrange memory into contiguous blocks and put other devices memories into known locations (out of harms way)
• allow allocation and deallocation of memory dynamically and still allow for virtually addressed contiguous blocks of memory for apps.

All devices memories are already in known locations, and they are never in the way.

Very ironically, your virtually-addressed "contiguous blocks" are not actual contiguous memory at all... In fact after multi-level page translations they are probably even more fragmented small blocks of physical memory, as small as 4kbytes each! Your contiguous memory is an illusion, done with smoke, mirrors and page tables
So there goes your two major advantages of paging.

In my expereience the VESA LFB is always "automatically" mapped to the top of installed physical RAM, ...

You misrepresent my statement. I said "contiguous blocks of memory for apps". You are suggesting that we need contiguous blocks of memory for SDRAM. Apps are what the CPU runs. SDRAM is just there to provide storage. So we should be trying to make things more convenient for the apps.

revolution, I have to say your arguments can be a bit circular (haha, circular, revolution ).

For example, you keep referring to your perceived problem when there is "4GB (or more) of SDRAM". You keep suggesting that the only way to address RAM above 4GB is by means of paging. That is precisely my point. That is the limitation imposed on us by the X86-64 "long-mode" architecture. If a Flat Real 64-bit mode was available this "problem" would not exist. What happens when we get more than 64 address lines?

I don't understand this:

Quote:

You misrepresent my statement. I said "contiguous blocks of memory for apps". You are suggesting that we need contiguous blocks of memory for SDRAM. Apps are what the CPU runs. SDRAM is just there to provide storage. So we should be trying to make things more convenient for the apps.

I am certainly not suggesting "that we need contiguous blocks of memory for SDRAM" because that does not make any sense to me. To me, SDRAM is just RAM - synchronous dynamic RM, just plain old main memory. Why do you refer to SDRAM as though it is somehow different to "memory"??

And yes, the CPU runs apps, but it also runs the OS which controls how apps are run. But why do you also say "SDRAM is just there to provide storage"? Are you implying the CPU essentially runs from its cache, with "SDRAM" acting like "virtual cache"?

And what did you mean earlier when you referred to "CPU page size". Are you saying the CPU uses an internal paging scheme to access its cache??

Sorry for all these questions but I think we need to clarify some things here.

I mentioned SDRAM page size (internal in the SDRAM) and CPU page size (an entirely different type of paging). Actually I wish I hadn't mentioned the SDRAM page thing because it is a red-herring

My dear revolution (how civil is that ),

... you do contradict yourself:

here's what you said before:

Quote:

I mentioned SDRAM page size (internal in the SDRAM) and CPU page size (an entirely different type of paging). Actually I wish I hadn't mentioned the SDRAM page thing because it is a red-herring

.
Now you're saying CPU page size is "the 4kb pages...evident when paging is enabled", and cache is a red-herring too.

And you didn't answer my question about your perceived 4GB "limit"...

And now I don't know what question I didn't answer, that you're not going to ask again...

I guess this debate isn't going anywhere except kinda round and round. But about memory fragmentation I will just say that of course the physical memory always remains contiguous in the physical sense, but the fragmentation arises from the page translations, and dependent on the memory management (allocation/deallocation) algorithms used.
At the end of the day I don't think we're ever going to convince each other of the merits or otherwise of memory paging, but as a final side-swipe I'll also say that another disadvantage of paging is that it has facilitated the implementation of disk-based virtual memory which is an even greater sin than paging itself . But then we've discussed that subject before too!