How crazy a machine can GCC usefully target?

[Alan Lehotsky <apl at alum dot mit dot edu>]

I'm looking at a port to a VLIW microsequencer which basically has the following characteristics:

- completely exposed pipeline latencies.  (values have to be loaded into latches on the ALU, the ALU op is
	"asserted" and the result is available at the next instruction.)

- No memory.  "Data" comes in via a port, can be moved into one of about 16 registers, processed and then
	goes out via a port. 	(It's basically a comm chip...)

- No stack.

- No HW support for function calls (all jumps are absolute (except for a case-dispatch), so implementing RETURN
   	requires a case dispatch indexed by the "call number" to get back to the return address.  [Going to take linker
	support to make THIS work...])

The customer would like to program in "C", because there's a lot of decision-code that would be much
more maintainable in a HLL (plus, it's really a very hard machine to program due to the latencies and
register behavior).

As far as function-calls go, in reality, I believe that the programmers will make EVERY function inline
(both for performance reasons AND because there's very little code that could be extracted into a common
subroutine) - functions are just for abstraction and information-hiding....

Anybody done something like this before?  I've got a pretty good handle on the  effort for a normal port (I've done
a 32-bit RISC ASIC, an 8-bit "Internet Toaster", and worked on a couple of other ports (RS6000, ADI SHARC, etc)
but this one could be exceedingly messy.... 

-- 
------------------------------------------------------------------------

		    Quality Software Management
		http://home.earthlink.net/~qsmgmt
			apl@alum.mit.edu
			(978)287-0435 Voice
			(978)808-6836 Cell
			(978)287-0436 Fax

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation