flat assembler
Message board for the users of flat assembler.

Index > DOS > Question about real mode addressing

Goto page Previous  1, 2, 3, 4  Next
Author
Thread Post new topic Reply to topic
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
neville wrote:
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?
But it is not laid out in contiguous blocks is it. It is broken up by LFB's and I/O buffers (I mentioned them above). 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.
Post 23 Jan 2009, 03:59
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
neville wrote:
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)
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.
Post 23 Jan 2009, 04:03
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
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 Smile
So there goes your two major advantages of paging.
Hmm, I think we've had this discussion before... Wink

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 06:22
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Quote:
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.
revolution, I assure you from my experience that is not the case. So-called "Unreal" mode is still Real Mode (that's why I prefer to call it Flat Real Mode). It has no affect on BIOS code whatsoever. And with DOS in flat real mode, who needs DPMI?

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 06:27
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
So you must be running unreal mode code in a 16bit mode selector? Assuming 32bit code then I would have thought that each interrupt needed to transition back to 16bit code selectors if one needs to run BIOS code. And if you are running 16bit code in unreal mode then it seems to me it kind of defeats the purpose of unreal mode.
neville wrote:
who needs DPMI?
Hehe, people with non-performing unreal mode CPUs. Plus the two main advantages I listed above.
Post 23 Jan 2009, 06:45
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
neville wrote:
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 Smile
So there goes your two major advantages of paging.
Hmm, I think we've had this discussion before... Wink
Smoke and mirrors maybe but the software doesn't care, it looks like contiguous blocks and that is all that matters. 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. And moving it out of the way can be very convenient.

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.
Post 23 Jan 2009, 06:50
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Quote:
And if you are running 16bit code in unreal mode then it seems to me it kind of defeats the purpose of unreal mode.
Not at all, it just means a few operand and address size prefixes for the 32-bit stuff. Because I make extensive use of BIOS routines I reckon that's a small price to pay.
Quote:
Hehe, people with non-performing unreal mode CPUs.
Exactly, I rest my case. DPMI is only for people who can't do Flat Real mode
Quote:
Plus the two main advantages I listed above.
that I discredited Wink
Quote:
Smoke and mirrors maybe
you forgot the page-tables Smile
Quote:
It makes some software easier to write.
and a lot of software much harder to write Sad
Quote:
Also what happens if you have 8GB memory
not much use without 33-bit addressing which requires long mode. There's a hole in my bucket...
Quote:
the LFB's and things do get in the way
examples please?
Quote:
Perhaps I can mention a third advantage of paging
you mean first (see above) Wink
Quote:
Being able to access more than 4GB in 32bit code.
32-bit code maybe, but you still need more than 32bits of addressing
Quote:
The OS can allocate up to 4GB per process, not possible with flat addressing.
You might be able to convince a C+ programmer of this but not an A++ programmer. A++ is the name I just invented for the Assembly Language implemented in the fasm-based FAMOS IDE. (C) 2009 Neville Watkin. I also reserve A+ and A#. Very Happy

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 09:19
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
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?

Just because you call it smoke and mirrors does not mean any sort of discredit. If I can move the LFB (and other hardware buffers) to the top of the address space and move the SDRAM back into the hole how does that complicate app programming when the SDRAM now appears contiguous?

Do you really believe that paging creates RAM fragmentation? Is it not more important that the apps see contiguous space? The hardware doesn't care what order you access RAM it just simply gives you that data. The name is Random Access Memory.

[edit]I checked the old docs, the Pentium Pro was the first to introduce a 36bit hardware address bus.
Post 23 Jan 2009, 09:34
View user's profile Send private message Visit poster's website Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
Quote:
neville: Since the Pentium Pro the x86 CPUs have had 36 bit address capability. Impossible to address it all without paging.
Hmm, do I smell smoke again? And was that the glint of a mirror in the corner of my eye? Does the PPro have 36 physical address lines (A0 to A35)? I suspect not, but correct me if I'm wrong. I suspect this is virtual stuff again i.e. the PPro can address 64GB of virtual memory, but can not have 64GB of real physical dynamic RAM! I hope not anyway, because if it can I just prematurely bought an X86-64 machine, when 64GB of RAM on my old PC would have kept me going for a while yet Wink
Quote:
Where is the LFB usually? Will it never get into the midst of the SDRAM space?
In my expereience the VESA LFB is always "automatically" mapped to the top of installed physical RAM, so my answer in "no".
Quote:
...how does that complicate app programming...
it doesn't, I'm talking about system programming Smile
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?)
Quote:
the Pentium Pro was the first to introduce a 36bit hardware address bus.
Hardware i.e. A0 to A35 external address lines? Again I very much doubt this, but if its true I'll be very p@#$sed off, and pleeze show me how to access it Mad

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 19:36
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
Yes, 36 real physical hardware address lines. Pure and simple. So how to address it all? With paging.

[edit]
Although, of course, being a 64bit data bus, A0-A2 are not made external, but let's not get too picky, it is still 64GB physical address capability.
Post 23 Jan 2009, 19:45
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
neville wrote:
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?)
Sorry, I meant to say SDRAM fragmentation. While logically the data is not contiguous in a non 1-1 paged system it will have no effect upon access times, SDRAM takes the same time to retrieve data regardless of which address you give it*.

* At least at the 4kB page level, smaller random access will suffer from a SDRAM page switch latency. However since both (CPU and SDRAM) page sizes are usually matched 4kB this has no effect upon performance. Both paged and non-paged systems will have to endure the SDRAM page change latency.
Post 23 Jan 2009, 19:56
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
neville wrote:
In my expereience the VESA LFB is always "automatically" mapped to the top of installed physical RAM, so my answer in "no".
Is this still true for systems with 8GB SDRAM?

Think about it. If it is put above all the SDRAM then how to access it without some type of paging. And if it is put somewhere in the first 4GB then it is putting a hole in the SDRAM continuity. Hmm ...

[edit]
Replace 8GB with 4GB and the argument still holds.
Post 23 Jan 2009, 20:03
View user's profile Send private message Visit poster's website Reply with quote
DJ Mauretto



Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy
DJ Mauretto
Usually from p2 p3 Ppro ( p6 family) untyl today
northbridge chipset use the following line to interface with CPU
A [31:3] for address bus (28bit)
D [63:0] for data bus (64bit)

Check Intel chipset spec for this.
Note that Address [3:0] are used by northbridge to select memory chip

_________________
Nil Volentibus Arduum Razz
Post 23 Jan 2009, 20:06
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
DJ Mauretto: Yes, not all the older motherboards could support all the CPU features. Things like dual CPUs and >4GB RAM were often only available on server machines.
Post 23 Jan 2009, 20:10
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
DJ Mauretto wrote:
Note that Address [3:0] are used by northbridge to select memory chip
I presume you mean A[2:0]. But actually those lines don't exist. Instead there are 8 byte enables that allow byte selects on the data bus. These are normally only needed for write cycles to allow updates on a byte sized granularity.
Post 23 Jan 2009, 20:14
View user's profile Send private message Visit poster's website Reply with quote
DJ Mauretto



Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy
DJ Mauretto
For server machine intel chipset use
A [39:3]
D [63:0]
Note that i have in front to me Intel chipset documents and i am reporting data from chipset Smile

_________________
Nil Volentibus Arduum Razz
Post 23 Jan 2009, 20:20
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
A[39:3]? I presume this is for the 64bit Xeon CPUs with the 40bit address bus?
Post 23 Jan 2009, 20:28
View user's profile Send private message Visit poster's website Reply with quote
DJ Mauretto



Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy
DJ Mauretto
Seem also for Dual Core or Quad Core,
in fact some year ago i wanted to buy a Server chipset for
my desktop pc because more faster

I understand because i don't bought anymore ,beacause it's for
Xeon 64 bit CPU Razz

_________________
Nil Volentibus Arduum Razz


Last edited by DJ Mauretto on 23 Jan 2009, 20:38; edited 3 times in total
Post 23 Jan 2009, 20:32
View user's profile Send private message Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
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?

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 20:34
View user's profile Send private message Visit poster's website Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17717
Location: In your JS exploiting you and your system
revolution
neville wrote:
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...
I encourage you check out the docs for yourself. No need to have a belief system about it. Wink
neville wrote:
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?
I never mentioned cache. That is an entirely different thing completely. 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. You can't avoid the SDRAM page, it is built into the SDRAM and cannot be disabled. And I only mentioned for the sake of completeness *regret* Sad
Post 23 Jan 2009, 20:41
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2, 3, 4  Next

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.