Re: Adding "shared" to C, need sysv386 .section syntax (Pete Alleman)
Mon, 23 Sep 1991 01:42:03 GMT

          From comp.compilers

Related articles
Adding "shared" to C, need sysv386 .section syntax (1991-09-19)
Re: Adding "shared" to C, need sysv386 .section syntax (1991-09-23)
Re: Adding "shared" to C, need sysv386 .section syntax (1991-09-24)
Re: Adding "shared" to C, need sysv386 .section syntax (1991-09-25)
| List of all articles for this month |

Newsgroups: comp.compilers,comp.unix.sysv386
From: (Pete Alleman)
Keywords: C, 386, assembler
Organization: Consulting
References: 91-09-052
Date: Mon, 23 Sep 1991 01:42:03 GMT

In article 91-09-052 (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.

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

Post a followup to this message

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