schultz@mmm.UUCP (John C Schultz) (07/28/89)
As followup to my previous note on the OS9 Ethernet support package, I
thought I would discuss in a little more detail the OS9
cross-development environment and how well that works (or doesn't as
the case may be).
Combined with the Ethernet support package, the cross-development
compilers makes my life a lot easier. I develop and debug code on the
SUN and then download executable code to the OS9 system. Debugging on
the OS9 system is negligible if any. In fact I have not used or
needed to use the OS9 Ethernet debugger which we purchased with the
cross-compiler and ESP package (altogether called Unibridge).
{ASIDE
Not having to debug on the OS9 system is perhaps however related to my
ability to debug hardware on the OS9 VME system from the SUN. We have
a couple Bit 3 VME-VME bus repeaters so I have memory mapped (via
SunOS mmap() calls) to the hardware on the OS9 system. When compiling
for OS9, I simply directly map rather than calling the mmap() routine
- works like a charm. Also since the Bit 3 does not necessarily pass
interrupts, I can even use the system with interrupt processes
running on the OS9 box (though we have to short out OS9).
}
Anyway, the only real complaint I have about the OS9 cross-development
is MAKE. OS9 make is not compatible with SunOS make. When
cross-compiling on the Sun, you must use Sun make which means that
"little" things like the object code extension under UNIX is .o while
OS9 uses .r can screw you up. Thus, I have to keep three makefiles around.
One for Sun with cc (or gcc), one for the Sun as cross compilation
(file extension problem and cc68 rather than cc) and one more for the
OS9 system which apparently doesn't understand Sun makefiles.
Anyway, I like cross-compiling, basically because the disk
performance, UNIX tools, and windowed human interface on any
workstations beats the #$%@% out of an OS9 system (though for a tad
more money).
--
john c. schultz schultz@3M.Com ..!uiucuxc!mmm!schultz (612) 733-4047
3M Center, Bldg 518-1-1, St. Paul, MN 55144-1000
The opinions expressed herein are, as always, my own and not 3M's.