Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
I am working on implementing shared memory between two tasks in my OS. My MMU was implemented till segmentation. So, I only provide segmentation. So, GDT descriptors are used to find corresponding segments for each task. If I want to map a process address space to shared memory region so that other tasks can map and communicate each other, in what procedure I can implement this. Do I need to implement intermediary LDT, so that one of entry for certain address range is pointing to shared segment.
Can anyone help and explain what is the best way to implement shared memory in segmentation. Any help would be appreciated.
I assume you write everything in assembly - you cant get decent modern compilers to work with segmentation.
As for the "best way", there is no universally best way to manage shared memory, let alone when using segments since there is almost no prior art in that area.
EDIT: fixed the "I built a compiler last summer" loophole as pointed out by rdos
Last edited by Combuster on Fri Oct 08, 2010 3:54 am, edited 1 time in total.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Sri wrote:
Can anyone help and explain what is the best way to implement shared memory in segmentation. Any help would be appreciated.
Generally, virtual memory is best implemented with paging, regardless if segmentation is used or not. Paging would then give processes separate address spaces, and sharing could be implemented by sharing page table entries.
Sharing of segments is smiple (provided the linear addresses are similar). Either use the same GDT selector, or map the same linear address to the local LDT.
Combuster wrote:I assume you write everything in assembly - you cant get modern compilers to work with segmentation.
Wrong. Open Watcom has support for all kinds of x86-based memory models. Everything from small, large and compact real & 16-bit protected mode memory models to flat, small and large 32-bit memory models.
And nobody sane uses it. Heck, given the amount of basic code generation errors fixed in the latest release I wouldn't want to begin relying on it.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
Combuster wrote:And nobody sane uses it. Heck, given the amount of basic code generation errors fixed in the latest release I wouldn't want to begin relying on it.
Most of these issues were not code generation errors. The most serious error was probably with long double formatting that was broken. There is still no native 80-bit double type, which is a short-comming, but anybody could add it.
Given that it produces many types of codes that GCC cannot produce (for example segmented code in various memory models) and support far pointers in both 16 and 32 bit mode, it vastly out-classes GCC which can only produce flat memory model code. The #aux pragma which defines which registers are used to pass parameters is another feature that beats GCC easily.
Also, I've ported a large project from BCC 5.4 to OpenWatcom, and there were basically no problems with code generation errors in this project. I think there were more bugs in Borlands product (which I've learned to avoid) than in OpenWatcom's. And of course nobody could fix Borland's as they have not released the source for it.
rdos wrote:Given that it produces many types of codes that GCC cannot produce (for example segmented code in various memory models) and support far pointers in both 16 and 32 bit mode, it vastly out-classes GCC which can only produce flat memory model code. The #aux pragma which defines which registers are used to pass parameters is another feature that beats GCC easily.
I wouldn't use any of those features - for me they're useless. GCC far out-classes OpenWatcom in terms of C++0x support, which I do use.
Just to remind you not everybody values the same things you do.
With basic things, I meant things like the default implementation of NULL being not standards-compliant, and that constant folding in things like my_func(1.0f+1.0f) not working as expected. Even the low-feature compilers like TCC/PCC, well-tested GCC, and even the infamous MSVC know how to do those properly.
Features are worthless if the basics are broken.
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
rdos wrote:Given that it produces many types of codes that GCC cannot produce (for example segmented code in various memory models) and support far pointers in both 16 and 32 bit mode, it vastly out-classes GCC which can only produce flat memory model code. The #aux pragma which defines which registers are used to pass parameters is another feature that beats GCC easily.
I wouldn't use any of those features - for me they're useless. GCC far out-classes OpenWatcom in terms of C++0x support, which I do use.
Just to remind you not everybody values the same things you do.
I code everything in C++, so that is not an issue with OpenWatcom. It supports C++ alright.
Combuster wrote:With basic things, I meant things like the default implementation of NULL being not standards-compliant, and that constant folding in things like my_func(1.0f+1.0f) not working as expected. Even the low-feature compilers like TCC/PCC, well-tested GCC, and even the infamous MSVC know how to do those properly.
Features are worthless if the basics are broken.
I wouldn't rely on how any such things are implemented. I'm certainly not writing code that could be broken on different platforms, even if it is standard-compliant.
rdos wrote:I wouldn't rely on how any such things are implemented. I'm certainly not writing code that could be broken on different platforms, even if it is standard-compliant.
If it's not standards-compliant (or even approaching it!) how can it work on different platforms? Not conforming to the standard is a certain way to break on platforms that do.
I don't see platform portability as a feature I want to support, especially not endian issues. In my world, processors with big endian byte order are out of scope. Therefore, when I write software for embedded systems, I will not clutter it with endian issues. That is because we decide for ourselves which hardware we will use for our terminals, and hardware with big endian processors will never get selected because the software will probably not run on them without major revision.
When it comes to my OS, it has a smaller scope than that. It will never run on anything else than an IA32 compatible processor. It will also (forever) have a segmented design in kernel, while applications can use any type of memory model. Therefore, GCC is still a possible compiler for user applications, and if I get the time (or somebody else wants to do it), it is very possible to finish the elf-loader, and the newlib port so GCC can be used for writing applications for RDOS. The primary advantage of OpenWatcom is that it can be used both for kernel and user, and thus it becomes possible to debug an application and it's kernel calls all in the same debugger. This is the primary reason for moving the device-drivers from TASM to WASM. It produces symbolic files for device-drivers that OpenWatcom's debugger can understand.
Also, since we decide which hardware platform to use, we have chosen PPCL61 from Advantec, and we have a full set of device-drivers for it for RDOS. Thus, the device-driver availability issue is not an issue for this project as Advantec will have this platform in stock for a while.
