porting GNU development tools using CGEN

porting GNU development tools using CGEN

[Johan Rydberg]

Hi!

Since I have started porting the GNU development tools using CGEN
I have decided to write a small document describing the steps that
you have to go through to do this.  Could there be any public interest 
is a document of this type?  

-- 
Johan Rydberg, Net Insight AB, Sweden, +46-8-685 04 00

$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
             THEN EXCUSE/OBJECT=ME

Re: porting GNU development tools using CGEN

[Eric Christopher]

> Since I have started porting the GNU development tools using CGEN
> I have decided to write a small document describing the steps that
> you have to go through to do this.  Could there be any public interest
> is a document of this type?
> 

I'd think so. I'd find something like that useful, and worth
contributing to...

-eric

Re: porting GNU development tools using CGEN

[Frank Ch. Eigler]

Hi -

On Mon, Dec 04, 2000 at 04:20:56PM +0100, Johan Rydberg wrote:
: Since I have started porting the GNU development tools using CGEN
: I have decided to write a small document describing the steps that
: you have to go through to do this.  Could there be any public interest 
: is a document of this type?  

Definitely.

One could develop it inside cgen/doc, or on the CGEN Faq-O-Matic page
at < http://sources.redhat.com/fom/cgen/ > which is empty right now.

- FChE
-- 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6K9vPVZbdDOm/ZT0RAtbAAJ9EyRP09KYiSneZeQj1jlnZJUInegCfaxd1
6vXKoVcotwew5SBKuxJm98g=
=kaki
-----END PGP SIGNATURE-----

Re: porting GNU development tools using CGEN

[Johan Rydberg]

"Frank Ch. Eigler" wrote:

> On Mon, Dec 04, 2000 at 04:20:56PM +0100, Johan Rydberg wrote:
> : Since I have started porting the GNU development tools using CGEN
> : I have decided to write a small document describing the steps that
> : you have to go through to do this.  Could there be any public interest
> : is a document of this type?
> 
> Definitely.
> 
> One could develop it inside cgen/doc, or on the CGEN Faq-O-Matic page
> at < http://sources.redhat.com/fom/cgen/ > which is empty right now.

Yes.

Right now, fragments of the document is in the CVS-repository for the
OpenRISC project (at http://openrisc.sourceforge.net/ ).  Maybe we sould
move it to the sourceware repository?

If we should move it to the official repository, maybe it's best if I
removed all references to my port, since I don't see it to be included
in the standard releases of GNU binutils or CGEN in the near future.

-- 
$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
             THEN EXCUSE/OBJECT=ME

porting GNU development tools using CGEN

[Doug Evans]

Johan Rydberg writes:
 > 
 > Hi!
 > 
 > Since I have started porting the GNU development tools using CGEN
 > I have decided to write a small document describing the steps that
 > you have to go through to do this.  Could there be any public interest 
 > is a document of this type?  

This would be great!

I'd suggest merging whatever you come up with with cgen/doc/porting.texi.
[which is certainly in need of more writers]

Re: porting GNU development tools using CGEN

[Johan Rydberg]

Doug Evans wrote:

>  > Since I have started porting the GNU development tools using CGEN
>  > I have decided to write a small document describing the steps that
>  > you have to go through to do this.  Could there be any public interest
>  > is a document of this type?
> 
> This would be great!
> 
> I'd suggest merging whatever you come up with with cgen/doc/porting.texi.
> [which is certainly in need of more writers]

It seems that cgen/doc/porting.texi is more meant as a reference manual
and not a howto.  The document that I started writing on is at a much
more
basic level and is a "this is the easiest and fastest way to get things
going"-document.  I don't see a clean merge here, so maybe it's better
to
keep them as two separate documents (referring to each other).

But maybe it's smarter to choose and example architecture that is
included
in the standard distribution of CGEN and GNU binutils.  The FR30 port
seems
to be very good documented.  Maybe we/I should use that as an example
instead of my own port?

-- 
Johan Rydberg, Net Insight AB, Sweden, +46-8-685 04 00

$ ON F$ERROR("LANGUAGE","ENGLISH","IN_MESSAGE").GT.F$ERROR("NORMAL") -
             THEN EXCUSE/OBJECT=ME

Re: porting GNU development tools using CGEN

[Greg McGary]

Johan Rydberg <johan.rydberg@netinsight.se> writes:

> Since I have started porting the GNU development tools using CGEN
> I have decided to write a small document describing the steps that
> you have to go through to do this.

I have been doing the same thing, so will be happy to review and/or
contribute my bit.  FYI, here's my one-paragraph porting guide:

	Find all instances of the string "fr30" (case insensitive)
	then clone & adapt appropriately.  (I have preferred fr30 over
	m32r because my new CPU matches fr30 for simplicity, whereas
	m32r is more complex as it comprises multiple models.)  When
	you first clone a file or significant bit of code for the sole
	purpose of getting things to compile, immediately attach a
	FIXME comment stating that all you've done so far is clone.
	Revisit all cloned code and either adapt it or remove it if
	it's inapplicable to the new CPU.  You must make all cloned
	code your own, which is to say, you must understand it as
	completely as if you had written it from first principles.
	You do a disservice to those who come after if you leave
	unused or inappropriate cloned junk laying about.

Greg

Re: porting GNU development tools using CGEN

[Doug Evans]

Johan Rydberg writes:
 > It seems that cgen/doc/porting.texi is more meant as a reference manual
 > and not a howto.  The document that I started writing on is at a much
 > more
 > basic level and is a "this is the easiest and fastest way to get things
 > going"-document.  I don't see a clean merge here, so maybe it's better
 > to
 > keep them as two separate documents (referring to each other).

I recognize the issue of reference vs howto.
However, there aren't enough resources to maintain two separate
documents.  Ergo -> I propose just having one.

One can have a "Quick Start" guide inside the bigger one.