rando@skipper.dfrf.nasa.gov (Randy Brumbaugh) (11/03/90)
Help! I find myself being drawn more deeply into the transputer / C
quagmire
_BACKGROUND_
I am working with a transputer board designed for embedded applications
where it may be physically difficult to get to the board (to change
EPROMS, for example). The board has two memory areas. One, for program
storage, is write protected, battery backed-up, SRAM. In normal
operation, the transputer will be set to boot-from-ROM, using this
memory. The second area is RAM for workspace, etc. Each area is
256kbytes.
To update the program, remote signals tell the board to un-write
protect the program area and boot-from-link. The new code is copied
to the ROM space.
_PROBLEM_
The 3L C Compiler generates HUGE code. A simple C program I wrote
has compiled to about 100 bytes. Linking in the runtime libs
brings it to maybe 500 bytes. But, the code produced for the
simplest case (standalone libraries, simple taskharness) is
almost 4k!
After spending many hours with disassemblers and ASCII charts, I
have found that the linker includes many functions which seem
to do mysterious setup things. The symbols LATICE___ENTRY_POINT,
_init, _boot, and RTL$START are called as functions. Several
strings and i/o routines are included, apparently for debugging.
The details are too messy (and long) to describe fully here.
_QUESTIONS_
1) The C compiler + runtime libs seems to produce code which
would be fine for running as a process. What is all the other
garbage included, and why is it needed? Is it needed?
2) The basic transputer ROM image would seem to require
only bootstrap code, and then instructions to set up entries
for process queues and do a STARTP instruction for each process
to be started in the transputer. Has anybody done this?
(channels would have to be allocated for inter-process
communication)
3) In all the searching, I have not seen a single STARTP
instruction. Why? Does it work? Do most systems manipulate
the process queues directly? If so why?
4) To load the board as described above, I need to produce
a binary, ROM image file which can be sent to the destination
T800 as an array. Does anybody know of anything to do this?
5) Is the huge code output a problem unique to the 3L compilers?
Any answers would be helpful. I have called CSA and they have
not returned my call.
Randy Brumbaugh
rando@skipper.dfrf.nasa.gov