flat assembler
Message board for the users of flat assembler.

Index > DOS > Question about real mode addressing

Goto page Previous  1, 2, 3, 4
Author
Thread Post new topic Reply to topic
DJ Mauretto



Joined: 14 Mar 2007
Posts: 464
Location: Rome,Italy
DJ Mauretto
Anyway What is the subject of debate Embarassed

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


Joined: 24 Aug 2004
Posts: 17715
Location: In your JS exploiting you and your system
revolution
Okay, I save you some time. Even the IA32 arch manual has a brief summary:
Table 2-3. Key Features of Previous Generations of IA-32 Processors wrote:
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
Post 23 Jan 2009, 20:48
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
Well it does say 64GB max ext address space = 36-bit addr bus for sure, but I wonder how many motherboards with PPros would support even 4GB let alone 64GB ?

_________________
FAMOS - the first memory operating system
Post 23 Jan 2009, 22:30
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: 17715
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!
Alright, lets, for the moment, assume they are in fixed locations. I disagree that it leaves a "large contiguous block in between" because that assumes a small amount of SDRAM (<4GB).
neville wrote:
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.
Fixed: yes (based upon the above assumption). Never in the way: No.
neville wrote:
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.
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.

Now, let's address the assumption above that all device addresses are in fixed location:
neville wrote:
In my expereience the VESA LFB is always "automatically" mapped to the top of installed physical RAM, ...
So it would seem they are not in fixed locations? You can't have your cake and eat it too. Things do move abound in the address space. And the question still stands unanswered: what happens to the LFB in a system with 4GB (or more) of SDRAM? Is it still at "the top of installed physical RAM"?
Post 24 Jan 2009, 06:09
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
revolution, I have to say your arguments can be a bit circular (haha, circular, revolution Laughing ). 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?

Sorry, but when it comes to misrepresentation, perhaps we are both guilty. I specifically separated the VESA LFB from my statement about device addresses being in fixed locations. Of course the Top of RAM is not "fixed". That was exactly what I was saying...

Actually, maybe its only you who is guilty Wink 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. Surprised

_________________
FAMOS - the first memory operating system
Post 24 Jan 2009, 20:50
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
neville,

From CPU's point of view, they're all like slow, non-persistent clay tables. Wink
Post 24 Jan 2009, 21:39
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17715
Location: In your JS exploiting you and your system
revolution
neville wrote:
revolution, I have to say your arguments can be a bit circular (haha, circular, revolution Laughing ).
Yes, probably, it is one of my many failings. But I think I do have a valid question that you seem not to want to answer.
neville wrote:
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?
You still have not answered the question. But never mind I will now stop asking it, I don't want to be too circular, It would probably just annoying everyone here. Long mode flat addressing also suffers the "SDRAM not being contiguous" problem. The LFB is in an unknown position in the address space (other peripherals also of course, LFB is just an example). The SDRAM get "broken" into different sections by these foreign device memories.
neville wrote:
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 read previous your response as saying that physical ram gets fragmented (your words, not mine). What else is one to think it meant after reading the statement you made?
neville wrote:
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"??
Then what were you suggesting gets fragmented? Here are your words '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' Question

BTW: I started using the term SDRAM because I thought that if I kept just using the term "memory" it might be easy to get confused with cache memories and other device memories.
neville wrote:
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"?
Please don't bring cache into the discussion, it is a red herring.
neville wrote:
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??
CPU page size is the 4kB pages (or 2MB and 4MB also in later CPUs) evident when paging is enabled.
neville wrote:
Sorry for all these questions but I think we need to clarify some things here. Surprised
No need to apologise, I enjoy the occasional debate. As long as it remains civil (which so far we have managed with great effect) then I will be happy to debate this further.
Post 25 Jan 2009, 04:29
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
My dear revolution (how civil is that Wink ), 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 Laughing . But then we've discussed that subject before too!

_________________
FAMOS - the first memory operating system
Post 25 Jan 2009, 09:13
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: 17715
Location: In your JS exploiting you and your system
revolution
neville wrote:
My dear revolution (how civil is that Wink ),
Indeed, very civil.
neville wrote:
... you do contradict yourself:
Probably, but I don't think so in this instance.
neville wrote:
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.
I'm a little confused because I don't see the contradiction. Perhaps it is a misunderstanding. SDRAM has an internal page size (hardware dependent based upon the SDRAM chips chosen). The CPU has a different sort of paging, either 4KB, 2MB or 4MB IIRC. In windows it is of course 4KB. I think in Linux that also uses the 4KB mode.
neville wrote:
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...
Okay, I may have missed your Q. I hope it is not important, or that I answer it below.
neville wrote:
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 Laughing . But then we've discussed that subject before too!
I'm not actually trying to convince you (or anyone) to use paging. It doesn't affect me, I just like the debate. And I can see that some points have been lost in the mire.

My first basic attempt was to discredit the idea that: SDRAM was always contiguous and so paging was not needed to make it contiguous. So I mentioned that different devices can (and do) poke holes in the SDRAM address space and thus would require the apps/OS to skip these ranges to ensure no aberrant behaviour is made.

Secondly, I was trying to suggest that using paging to move the device memories around and plug the holes with the spare SDRAM could be advantageous for apps (and the OS BTW. If dynamic memory allocation is not needed then it only has to be done once at startup) to "see" a contiguous memory space without any annoying holes to be mindful of.

Phew, I hope that is clear, I'm trying my best to recount my argument in a concise manner.

However, since I am enjoying this debate so much I also want to add some things Razz

neville mentions the "Virtual memory" side swipe: Cool Cool, do you really want to discuss it here? I don't use it myself, but I can see how in some situations it can be useful. Use the HDD as a cheap (and slow) app memory, sure why not. The only alternative may be to buy expensive physical RAM, that might become too expensive in some cases. It becomes a trade-off situation.
Post 25 Jan 2009, 09:50
View user's profile Send private message Visit poster's website Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
Up to a conclusion, eh? Wink

1. Paging is good.
2. Abstractions (like virtual memory) are considerably good.
3. Untimely use of paging is evil.
4. Flat x86-64 is really unreal.
5. To each it's own (should it be he/she?).

Pun is intended. Wink
Post 11 May 2009, 13:47
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17715
Location: In your JS exploiting you and your system
revolution
Wow, only 3.5 months late into the debate Shocked

But your first point is not clear enough. Paging is useful, which is more important than just being good.
Post 11 May 2009, 14:03
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
Paging is [b]evil[/b] and only useful with bloated garbage that takes way more memory then it should!

Disk access should be used only as persistent storage, not as random access memory! Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation Exclamation [img]http://a10.ac-images.myspacecdn.com/images01/49/l_66ec29615ebf1009fc5e6aad9276ad29.gif[/img][img]http://farm1.static.flickr.com/194/489588773_cbb22c0624.jpg[/img][img]http://deepgroup.files.wordpress.com/2009/05/exclamations1.jpg[/img][img]http://www.electricka.com/ETAF/_pseudo_components/alert_components/alert_images/warning_danger/Caution%202.jpg[/img][img]http://images.suite101.com/484764_com_953317_12576736.jpg[/img]






Bloat is bad, see?

[edit by Loco] The user was given the chance to edit the post but decided that Test Area-like content was appropriate here. Post edited...
Post 28 Jul 2009, 12:16
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
MazeGen



Joined: 06 Oct 2003
Posts: 977
Location: Czechoslovakia
MazeGen
Very nice pictures, Azu! You can remove them now.
Post 28 Jul 2009, 16:00
View user's profile Send private message Visit poster's website Reply with quote
Azu



Joined: 16 Dec 2008
Posts: 1159
Azu
No they are integral examples in my argument that useless bloat is bad. Evil or Very Mad
Post 29 Jul 2009, 00:24
View user's profile Send private message Send e-mail AIM Address Yahoo Messenger MSN Messenger ICQ Number Reply with quote
neville



Joined: 13 Jul 2008
Posts: 507
Location: New Zealand
neville
I can't see the pics, but I agree 100% with your sentiments Azu - both incorporated into the design of my OS!

But why does X64 insist on paging in 64-bit mode! Its just plain dumb Evil or Very Mad

_________________
FAMOS - the first memory operating system
Post 29 Jul 2009, 06:55
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4633
Location: Argentina
LocoDelAssembly
If really interested, just press quote button on his post and then preview...
Post 29 Jul 2009, 14:24
View user's profile Send private message Reply with quote
Borsuc



Joined: 29 Dec 2005
Posts: 2466
Location: Bucharest, Romania
Borsuc
I disabled pagefile on my computer Razz
Post 29 Jul 2009, 18:59
View user's profile Send private message Reply with quote
Pirata Derek



Joined: 31 Oct 2008
Posts: 259
Location: Italy
Pirata Derek
I've a driver that can disable PAGING from Protected Mode for few seconds,
but when re-enabling paging sometime it causes error and sometime no.

It's still a proof of concept until i terminate it. Wink
Post 28 Aug 2009, 07:58
View user's profile Send private message Send e-mail Reply with quote
Display posts from previous:
Post new topic Reply to topic

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

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