|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|
|Organization:||Home Sweet Home, Lafayette, LA|
|Date:||Wed, 25 Sep 1991 00:55:06 GMT|
>[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]
The speed difference is small enough that it is not much of a factor.
Some advantages of using the linker to resolve the addresses:
* One of my applications involves 18 processors, each with some memory,
communicating and sharing data across all the memories. The
shared data must be split across the 18 data spaces. It
is not easy to have to worry about those addresses at
source level. (This is probably a rather unusual example
of Unix shared memory.)
* Resolving addresses is the linker's job.
* Data hiding. If I have a routine which needs some small data
structure from the shared data segment, I would hate to
have to include the definitions of all the data
structures in shared data just to get my little
structure. Also, with your suggestion, every subroutine
which references shared data must be recompiled if
anything is changed in the shared data structure. This
can be a configuration control problem.
The main disadvantage of using the linker:
* Link control files tend to be rather non-portable.
* The syntax of the link control file tends to be rather poorly
When writing small applications I used your approach. When
the application grew and problems arose I solved them with the
linker. As always, use the simplest approach which solves the
Return to the
Search the comp.compilers archives again.