Microtec and/or VxWorks

Hi,


I have a problem that hopefully somebody out there can help with. We have
VxWorks running on a MVME147 board which we download from a Sun 3/60. IT
WORKS SLICK, a VERY nice network interface that I am growing to like quickly.
Part of my assignment however is to create a VxWorks Driver to talk to custom
code in a MVME332rt board via a Shared Memory interface. I am having some
structure alignment problems in the Shared Memory since the VxWorks driver
uses Sun's "cc" command on the 3/60 while the MVME332rt board uses a Microtec
Compiler and Atron Probe emulator.


I am in control of the software in BOTH boards, but I still have a problem in
that ideally BOTH peices of software should be compiled by the same compiler
which would fix my alignment problems I am sure. I have tried to following:


1. using the "cc" command on the Sun 3/60 on both sides. Unfortunately the
Unix linker is just NOT robust enough for firmware concerns. (You NEVER have
to tell Unix the address of your text or data partitions, but in firmware you
do. There are some switches to support this, but it is VERY limited.)


2. Using the Microtec compiler on both sides. This looks promissing, but I
just can not get the Microtec compiler to generate *.o files that VxWorks
will accept. Microtec uses IEEE-695 (with extensions the stinkers) COFF
records and even though VxWorks provides several xxxToBsd conversion programs
I can not find any combination that seems to give me a "VxWorks Loadable"
solution. This seems like it might be the best approach though if anyone out
there happens to have a IEEE-695 to System V Coff or BSD program in their
pocket PLEASE LET ME KNOW.


3. I have thought about using either compiler, but having it generate assembly
source. This seems promising and may turn out to be the best solution yet,
but neither compiler generates assembly that the assember on the other system
understands. At best I am up for a substantial (but relatively simple) awk
script to make the conversion.


4. Doing the whole shared memory structure totally with type "char" thus
avoiding all alignment problems in the first place. This is also a strong
possibilty, but I would like to have arrays of structures and such in the
shared memory - this cause alignment problems again even if the individual
structures are totally type "char".


5. ???? Any other suggestions and/or comments????


Frank Merrow


uunet!odetics!frank
[I would be interested to hear what the alignment problems are, most 68K
compilers I've seen are pretty conservative. For that matter, what's the
processor on the network card? -John]
--

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