h a l f b a k e r yNot just a think tank. An entire army of think.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
On some older machines like the 80286, memory was divided into segments which could be freely located in memory. If a segment was moved from one part of memory to another during an interrupt, the code that was accessing the memory wouldn't particularly mind since it would read a new segment descriptor
when it resumed execution.
There were some good concepts there, but the implementation was lacking in many key regards:
-1- The total number of segments that could be used was limited;
-2- The number of segment descriptors that could be active at any given time was limited to four (one for code, one for stack, and two for data).
-3- Maintaining segment descriptors in registers is not a suitable approach in a multi-processor system.
I would suggest that the increasing popularity of object-oriented designs would suggest that a return to segmented architectures might be useful. There would have to be an address translation cache, and cache-coherency protocols would be required to ensure that multiple processors using the same object would always see the same information, but those issues should be manageable.
If those issues were taken care of, one slight remaining issue would be allowing access to objects that were in the process of being moved from one part of physical memory to another. I would suggest an easy solution: in each object descriptor, allow two addresses. Any reads to the object will be performed using the first; any writes will be performed to both addresses in order.
The process that's copying the memory would need to take certain steps to ensure that the copy didn't interfere with any writes that are being performed, but they should be manageable. Incorporating such features into hardware would help make practical lock-free operating system designs, enhancing system reliability.
[link]
|
| |
I think we may be forgetting the fragmentary effect that this had on the media. Processor time saved by this expedient was often lost when it came time to compile, defrag, or copy. Haven't heard the phrase "boot sector" for a long time so i guess this is somewhat a nostalgia idea. Give an example of the killer app. here. |
|
| |
I'm reasonably certain this is how memory works now - it's allocated as needed with no regard to how contiguous it is. Certain processes may load into the same areas on each boot, but they tend to belong to the OS and have no bearing on applications. Correct me if I'm wrong. |
|
| |
One of the hallmarks of the upcoming Microsoft OS is that it will dynamically allocate memory space even for these core processes in order to make it harder for virii to affect the OS. |
|
| |
Not really as this would cause a HUGE mess unless the relative positions in the media are adequately allocated beforehand. My understanding is vague but i remember how those 80286's would turn media into a swiss cheese of fragments. Not dynamic or efficient bit it gave the IIe a slight software advantage. |
|
| |
This is related to memory, not drive storage. Under all full-fledged operating systems, information stored in RAM can become fragmented; most operating systems provide a means of defragmenting. The problem is that under present systems, a block of memory which is being moved as part of a defragmentation operation cannot be used for any purpose until the move is complete. While completion of the move usually won't take very long, unless the processor performing the move disables interrupts, there's no guarantee that it won't get waylaid. |
|
| |
As for the problems dating to 80286 days, those related to interactions between the amount of memory available, the amount of memory used, and the size of individual objects being manipulated. Trying to deal with objects of roughly 16K each in a system with four megs of RAM, of which various pieces totalling 64K are free is apt to be a difficult. Trying to deal with such objects in a system with a gig of RAM and a dozens of megs free is not. |
|
| |
The proposed architecture would require that any time a block of memory is to be moved there must be a free space capable of handling the whole thing. Overlapping of the old and new memory areas would not be permitted. |
|
| |
I'm not quite clear how the 80286's limitations would have given the Apple //e an advantage, or were you talking about a different machine? |
|
| |
grammar error. The software advantage yielded to the IIe was the ability to run memory intensive programs without immediately over running the limited RAM of the time. This lead to a situation where DOS utilizes large (for the period) swaths of disk space for emulated memory. Programmers loved the ability to make huge memory page files. When booting from small media or a disk this would fragment large files. Just my experience. Forgive any knobishness from this non hacker. |
|
| |
Having different regions of memory for specific allocation sizes is workable in some scenarios, but expensive in others. Actually, what might make the most sense would be to use separate memory pages for each power-of-two submultiple of the page size, and allocate larger chunks of memory in page-size increments. I wonder how that would work out? |
|
| |
// memory was divided into segments which could be freely located in memory // |
|
| |
Tautology; actually, "memory was divided into segments which could be dynamically positioned in the address space, within the limits of the processor architecture." |
|
| |
No, no, no, no, no. No. This is very bad, evil, inadvisable, and wrong. No, absolutely not. Negative. Nyet. No way. Never. |
|
| |
Thank you for illuminating the subject supercat. I do think there is some merit in re-thinking the way cahes/ram/media treat pages/fragments as modern programs are rewarded for taking and holding as much of the resources as they can get. Aggressive apps look great, fast and smooth, and other apps running at the same time look terrible. Any system that can reduce the idling impact of memory intensive processes gets a bun from me. Still unclear if going back to this old system would do that. |
|
| |