OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Mar 29, 2024 8:12 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Question mmap implementation for shared memory
PostPosted: Wed Oct 06, 2010 8:50 pm 
Offline

Joined: Wed Oct 06, 2010 8:27 pm
Posts: 1
Hi all, :D

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.

Thanks in advance.

Regards,
Sri.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Thu Oct 07, 2010 3:30 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
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

_________________
"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 ]


Last edited by Combuster on Fri Oct 08, 2010 3:54 am, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Thu Oct 07, 2010 10:39 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Thu Oct 07, 2010 10:46 pm 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 3:48 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
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 ]


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 5:39 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 6:03 am 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3882
Location: Eindhoven
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 6:28 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
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 ]


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 10:58 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
Candy wrote:
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 11:01 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Fri Oct 08, 2010 1:53 pm 
Offline
Member
Member
User avatar

Joined: Tue Oct 17, 2006 11:33 pm
Posts: 3882
Location: Eindhoven
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.


Top
 Profile  
 
 Post subject: Re: Question mmap implementation for shared memory
PostPosted: Sat Oct 09, 2010 5:38 am 
Offline
Member
Member

Joined: Wed Oct 01, 2008 1:55 pm
Posts: 3192
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 33 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group