|Adding "shared" to C, need sysv386 .section syntax firstname.lastname@example.org (1991-09-19)|
|Re: Adding "shared" to C, need sysv386 .section syntax email@example.com (1991-09-23)|
|Re: Adding "shared" to C, need sysv386 .section syntax firstname.lastname@example.org (1991-09-24)|
|Re: Adding "shared" to C, need sysv386 .section syntax email@example.com (1991-09-25)|
|From:||firstname.lastname@example.org (Pete Alleman)|
|Keywords:||C, 386, assembler|
|Date:||Mon, 23 Sep 1991 01:42:03 GMT|
In article 91-09-052 email@example.com (Steve Nuchia) writes:
>I am trying to add a "shared" storage class to gcc for an embedded
>application I am working on.
>I know that it is easy enough to use some combination of preprocessor
>hackery and code extraction/generation -> sed -> as tricks to get the job
>done, but I would really like to be able to have what little help C gives
>me with type checking and scope control apply to these buggers, and adding
>the keyword seems to me to be a good way to do it.
It sounds like you're making it a lot more difficult than it should be. I
have several real-time applications which run as several tasks executing
with shared memory.
The way I implement it: Allocate all your shared data structures in one C
source file. Put nothing but the shared data allocation in that file.
Now perform an incremental link on that file, supplying a link control
file which allocates the memory at a hardwired absolute virtual address.
Now link that shared memory object file with all tasks which are to share
memory. You can reference those structures just like any other structure,
they just happen to be in shared memory (after the appropriate system
I use this procedure for multiple task on the same processor and for
multi-processor systems. It is simple, but effective. Of course it does
leave the documentation up to the programmer.
>Why am I using sysV for an embedded system?
Hey, it works. I've been using various Unix systems for real-time
applications since V6 was released to universities. Sometimes I have to
make some small changes to the OS to minimize delays, but it has always
done the job.
It depends on your timing requirements. I had a real-time training
simulator which had to execute at a solid, reliable 30Hz to keep up with
the visual system. No problem with a reasonable power workstation after a
little work on the OIS. I wouldn't recommend Unix for sub-millisecond
real-time applications though.
[Are any of these hacks appreciably faster than putting all the shared
stuff in a big structure, keeping a pointer to the structure that is set
from the result of shmat(), and maybe using preprocessor defines to make
it look prettier? -John]
Return to the
Search the comp.compilers archives again.