Why is the size of a segment 64K at most?
What does limit segments to 64K?
Posted on 2004-06-08 12:55:52 by bloggs
The fact that the registers are only 16 bit.
16 bit means you have 2^16 = 65536 = 64k possible values.
So it is physically impossible to address more than 64k with 16 bit registers.
That's why the segments were invented. They allow you to set a base address, and the register's address is added to that. Effectively you get a 20 bit address space then, and 2^20 = 1 mb.
Posted on 2004-06-08 13:19:42 by Scali
Thank you, I see.
Posted on 2004-06-08 22:56:37 by bloggs
Just for pedantic completeness, you still have segments in Protected Mode, which can be up to 4GB large - fortunately, all sane 32bit OS run in 'flat mode', which means you effectively don't have to worry about segmentation anymore.
Posted on 2004-06-09 01:12:51 by f0dder
The so called flat model still references segments though they are now refered to as pages. Either 4Meg pages in the Page directory or 4K pages in the Page table. The segment registers are loaded with the entry offset that pertains to the segment you wish to read or write.
Posted on 2004-06-09 17:14:29 by mrgone
mrgone: Segments and paging are not the same thing ...

The so called "flat memory model" is indeed flat :P aka the segment registers are loaded with selectors that have a limit setup at 4G and a base of zero... (almost)

In flat memory model protection and memory management is mainly done with paging and not with selectors although they still play a role.
Posted on 2004-06-09 20:50:19 by BogdanOntanu
paging comes on top of everything else , if i m not mistaken it has no relation with segmentation and you could have no paging at all everything would work... it is just a "final stage" big system thal allow every address the processor uses , to be redirected to a different adress on the bus... not every address, but blocks of 4k i think.

your segment doesnt even knows on which pages he lies, i think you could declare a descriptor for a 2 bytes segment sitting on 2 mem pages...
and your pages dont know to which seg they belong...

thats why i m quite surprised that modern OSes dont use segment paging, but the paging system of the processor... so the "present" bit in the descriptor is never used? but i suppose it must be more flexible with small independant pages and only one data seg per process... (with segment paging you couldnt swap just a part of the seg on disk...)

btw a techer of mine said under unix the pagetable might change at each ask switch, to allow each process to use the same LOGICAL adress and it ends up in two diffrent physicals... the example was a fork(), where a copy of the currrent process is launched, but it shared the same code and data, UNTIL the new process attempted to write in its data, and at this moment a new page is allocated at a different physical, and thats where the writes go for this process but the original process writes in the original phys addresses, thoug the 2 reference the same logical..

dunno if i m clear.. that made me think a lot . i doubt a little too, but it must have some truth;
would ve been much simpler to allow a whole new seg for data, so the linear addresses the 2 processes use for writing are not the same, but i was told the point was to avoid wasting memory for the second process, until he writes somewhere.

but then you ve got to change your pagetable at each task switch... ough.
anyone got info on this please?
Posted on 2004-06-10 12:59:55 by HeLLoWorld
what i mean by logical is LINEAR on intel.
Posted on 2004-06-10 13:00:47 by HeLLoWorld
what you describe (fork shit) is Copy-On-Write, used in windows too. Problem with *u*x is that some of them have been yelling "oh, our fork() is SO efficient we don't need threads!"... :rolleyes:
Posted on 2004-06-10 14:16:14 by f0dder
we ve got some solaris unixes here and they have what is called "lightweight processes" i think, and mybe other subtilities...

btw i m not very fond of the fork() way of creating a new process...

and i dont really think having two levels of process creation (process and thread) is that useful...
after all you could just have a creat_a_new_process and all processes would be equal, with no distinction to which running application they belong..

but threads must be useful since they ve been implemented.
Posted on 2004-06-11 10:55:03 by HeLLoWorld
In Windows it's pretty much the other way around. Everything is a thread, and a bunch of threads together have their own address space, and together they form a process. But there is very little difference between threads and processes in Windows.
And then there are the fibers. I have not seen those on any other OS yet.
Posted on 2004-06-11 11:49:44 by Scali
fork is rather stupid, IMO - for spawning a new process (exec), you end up duplicating a lot of things (pagetables, handles, ...), just to throw them away when you use exec to load the new memory image (well, I certainly hope they're thrown away, otherwise you're wasting a lot of memory).

A thing to keep in mind is that fork actually creates a new process - so parent and child can't communicate directly, you'll have to use pipes or some other means. Threads are more efficient, since they all run in the same process - the kernel structures to describe a thread are smaller than those required to describe a process.

In win32, a "process" should be though of as a placeholder. It contains kernel mode objects like file handles, it defines the memory ranges for the process, the modules (main exe file, DLLs) and the threads. All processes have at least one thread. The thread defines execution context, and stores things like a copy of the x86 registers, FP stack, ...

I wonder how useful fibers are... never seen them used, and can't see where you would use them. If you need them on some other OS, you can just implement them yourself anyway, they're 100% usermode handled afaik.
Posted on 2004-06-11 12:48:45 by f0dder
afaik, fibers are non-scheduled threads, and you schedule them manually. Therefore it is impossible to implement them in usermode. All you can do is sleep and awaken your thread, which obviously has more overhead than the fiber-approach, and is therefore useless.
Posted on 2004-06-11 14:29:49 by Scali
No, it's trivial to implement this in user mode, and like f0dder said, NT does (anything else would be really stupid)

You could implement them yourself on other systems like this:

mov eax,[CurrentFiber]
mov [eax],esp
mov eax,[esp+36]
lea eax,[FiberTable+eax*4]
mov [CurrentFiber],eax
mov esp,[eax]
ret 4

NT does a little more than this, it also saves/loads the current SEH frame and the stack lower and upper bounds.
Posted on 2004-06-11 16:37:08 by Sephiroth3
Nice of you to again post code without any explanation whatsoever.
And it's not correct. There are also things like Fiber Local Storage, that you haven't considered here.
But yea, I suppose you can implement it in usermode like this. I was thinking of something else (not hacking up the entire implementation of fibers manually, but using threads, as I said)... I've seen OSes implement even threads in usermode. Needless to say that is retarded.
Posted on 2004-06-11 17:04:05 by Scali
I was saying "on other systems". Of course, you could save/restore whatever other data you'd like. But fibers in NT do not have separate thread local storage. Only the SEH pointer and stack location is stored in a fiber.
Posted on 2004-06-11 18:03:42 by Sephiroth3
They have "fiber local storage" though :) - but that wouldn't be hard to implement in usermode either. One point of using fibers, actually, might be to avoid the sorta costly user<>kernel mode switches - again, assuming fibers are usermode implemented (which I think they are).
Posted on 2004-06-11 18:14:22 by f0dder
According to MSDN:

A fiber is a unit of execution that must be manually scheduled by the application. Fibers run in the context of the threads that schedule them. Each thread can schedule multiple fibers. In general, fibers do not provide advantages over a well-designed multithreaded application. However, using fibers can make it easier to port applications that were designed to schedule their own threads.
Posted on 2004-06-11 18:48:11 by stormix
They do have the speed advantage of not requiring a privilege level switch, though. And sometimes, your application design may favor the use of fibers rather than threads.
Posted on 2004-06-11 19:05:52 by Sephiroth3