Quote:

With just a small amount of programming to set up the page tables I think it is worth it to get into a memory environment where things are laid out more logically

. This sounds kind of ironic because what could be a more logical layout than a single flat linear memory space - aka unreal mode?

Unreal mode or Flat Real mode has several advantages for me. It provides a convenient no-hassle easily set-up environment for processing bulk data held in a linear 32-bit address space, up to 4 gigabytes. For example, it gives me direct access to all BIOS interrupts which saves a lot of time if you don't have to first write, then test and then debug your own I/O routines, for example. (16-bit code is not a problem - it works with 32-bit addresses just fine)

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

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.

DPMI does is nicely by using protected mode the way it was designed for. Even with unreal mode you still have to switch back to RM to run BIOS 16bit code.

who needs DPMI?

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.
Hmm, I think we've had this discussion before...

And if you are running 16bit code in unreal mode then it seems to me it kind of defeats the purpose of unreal mode.

Hehe, people with non-performing unreal mode CPUs.

Plus the two main advantages I listed above.

Smoke and mirrors maybe

It makes some software easier to write.

Also what happens if you have 8GB memory

the LFB's and things do get in the way

Perhaps I can mention a third advantage of paging

Being able to access more than 4GB in 32bit code.

The OS can allocate up to 4GB per process, not possible with flat addressing.

neville: Since the Pentium Pro the x86 CPUs have had 36 bit address capability. Impossible to address it all without paging.

Where is the LFB usually? Will it never get into the midst of the SDRAM space?

...how does that complicate app programming...

Do you really believe that paging creates RAM fragmentation?

the Pentium Pro was the first to introduce a 36bit hardware address bus.

Quote:

Do you really believe that paging creates RAM fragmentation?

Um, yes! Even more so if you use 4Kb pages e.g. rather than 2MB, but I admit the hardware overhead is probably not significant since page translation is more or less built-in to the memory read/write cycle, albeit multi-level (at least 3 levels in Long Mode?)

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

Note that Address [3:0] are used by northbridge to select memory chip

D J Mauretto, I find your version much easier to believe than revolution's! Starting at A3 just means all memory accesses are 64-bit (8 bytes), so its still really a 32-bit address bus, but not 36-bit...

revolution, if both page size and CPU cache are 4Kb, wouldn't that decrease the probability of cache hits and so increase latency when paging is enabled?