Re: Adding "shared" to C, need sysv386 .section syntax

In article 91-09-059 pja@ralph.lafayette.la.us (Pete Alleman) writes:
>The way I implement it: Allocate all your shared data structures in one C
..
>Now perform an incremental link on that file, supplying a link control
>file which allocates the memory at a hardwired absolute virtual address.


Hmmm... yes, I see! The incremental link step fixes the addresses,
then the "real" link step resolves to them, even with different images.


I want a single image so that I can pass function pointers, pointers
to constants, things like that around, but the idea should work.


Thanks, that is simpler, at least on the back end. It does not allow
me to control the scope of the objects created nor to allocate objects
with private data types though.


>multi-processor systems. It is simple, but effective. Of course it does
>leave the documentation up to the programmer.


This whole thing would be a lot easier if I had either documentation
or source. Having to make do with the *ahem* manuals AT+T and Interactive
put out is costing my client a lot of money. I know I should refrain
from flamage on a moderated technical list, but good grief! Now that
I have the syntax for the .section (thanks all) I am having a lot
of grief getting the linker and the loader (ie, the exec system call)
to agree on what the a.out file should look like. Of course the
documentation tells me everything I could ever want to know about the
*syntax* of COFF files, but nothing whatsoever about the semantics.


I think I can solve this one by the trial and error method. We'll see.


>>Why am I using sysV for an embedded system?
>little work on the OIS. I wouldn't recommend Unix for sub-millisecond
>real-time applications though.


I haven't yet measured the sampling jitter, but our maximum sampling
rate is 100/sec and outputs are slower than that. So jitter it the
only thing I'm really worried about. That and the fact that we have
neither source not adequate support for major chunks of the system. Sigh.


>[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]


This isn't about performance, it is about things like type checking
and information hiding. As I indicated in the first note, there are
plenty of ways to skin this cat. I suppose when you get right down
to it this is a science project, but the code I inherited on this
project was suffering so badly from preprocessor abuse, type puns
run amok, and general obfuscation that the effort seems justified.
--
Steve Nuchia South Coast Computing Services (713) 880-0099
--

Return to the comp.compilers page.
Search the comp.compilers archives again.