Re: Thinking of adding to egcs

[Alan Lehotsky <lehotsky at tiac dot net>]

At 12:23 AM -0400 5/27/99, DeRobertis wrote:
>I'd like to add cross-compilation support for another chip and embedded "OS"
>to egcs. Any tips? Any good docs around?
>

	Maybe we need a N+1-th mailing list for people to share questions
	(and answers) about new ports.  Or maybe it's worth the whole
	group seeing these to help understand what things aren't clear
	despite the level of documentation in the porting guide.

	I've got 16+ years of compiler experience and have been working
	on gcc for 4 years on the ADI SHARC and PowerPC. The port I'm
	working on now has some interesting challenges.  I've hesitated
	to waste bandwidth on some of my questions - but there are
	a lot of things I've learned the hard way.

	The best advice I can give you is to misquote Obi-Wan...

		Use the source, Luke.

	Many of the problems I've had to figure out were already
	solved by one of the ports.  Of course, the logic behind
	why certain things were done is obscured - and since my
	architecture is significantly different from any of the
	contributed ports, I end up shopping thru several different
	config/target directories to get to the mother-lodes.

	Also, the machines with the weirdest architectural features
	(and therefore likely to have solved my weird problems) are
	also machines that I don't know - so it's difficult to know
	WHERE to look for solutions, so 'grep' is your best friend.

		And emacs tags-search is your second best friend!
		Set up a tags file for the compiler and you can see
		how the various macros and functions are used in
		context. Use both META-. and META-x tags-search.

	It would be very useful if the egcs web site had pointers to
	online HW documentation for the ports, with URLs to
	PDF hardware manuals.

	For example (and this is a really mixed bag of macroscopic
	and microscopic detail off the top of my head...):

	- You have to provide an "ashrl3" pattern, even if you don't
	  have an arithmetic right shift instruction.  This axiom
	  holds for a lot of other patterns besides the obvious
	  "mov<mode>"

	- when working with a word only machine, you should do all your
	  patterns as QI.  Because of the way that machmode.def is
	  written, it's going to make tables like mode_size[] have
	  entries for SI that say SI is 4.  This has additional
	  repercussions. (See next item)

	- If you don't have a pattern for pretty much everything that
	  the compiler wants to construct RTL for, the optab code
	  will widen the operands and try to generate a HI or SI
	  form.  At the SI level, it will usually call a library
	  routine, and generate really wacko code where it loads
	  4 registers with the "four" pieces of the operand widened
	  to SI.

	- The way to use SCRATCH and match_scratch isn't quite as
	  obvious as the documentation would have you believe.

	- There are a lot of hidden limitations on using
	  PARALLEL.  For one thing, a PARALLEL with a jump in it
	  is invisible to much of the jump optimization.

		This is probably a bug in my case, because the
		only other thing in the parallel was a clobber.


	I've got lots of ideas for work that other people can
	do :-)  You can tell I used to be a manager, I'll bet.....

Good luck,

-- Al

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

		    Quality Software Management
		http://www.tiac.net/users/lehotsky
			lehotsky@tiac.net
			(978)287-0435 Voice
			(978)287-0436 Fax/Data

	Software Process Improvement and Management Consulting
	     Language Design and Compiler Implementation