This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Target deprecation list


Hi Joel,

> >         I just figured out sparclet-aout in your
deprecation
> >         list. I missed your first mail, probably
it bounced
> >         from my mail box.       I and "there are
1000 of us using this
> >         sparclet-aout port of GCC heavily all day
long and we were
> >         planning to upgrade to GCC 3.4" :)
> > 
> >         I'm currently upgrading it to GCC 3.2
which I'm almost through.
> >         I and our development team here have been
eagerly waiting for
> >         GCC 3.3 release, with which I'm planning
to do 
> regression testing,
> >         performance benchmarking of GCC for
various implementation of
> >         sparclet n/w processors after enabling
various new optimizations
> >         that come with GCC 3.3; DFA scheduler
contributed by 
> Vladimir being
> >         the first in pipeline.
> > 
> >         If required, I'm willing to volunteer to
maintain this
> >         port to keep it alive and evolve with
mighty GCC.
> 
> Is there any reason, you couldn't transition to the
sparc-elf target?
> Other than the obvious goal of eliminating targets
which don't have
> users, there is a simplification issue.  In this
case, sparc a.out
> systems are slowing disappearing and eventually gcc
may be able to
> remove all sparc/a.out support.   This also applies
to binutils 
> and gdb with respect to sparc/a.out.
> 
> ELF has been debug information and at this point in
time has a lot
> more activity.  You will have better support for C++
and other 
> languages on an ELF base target.

I'm looking forward to migrate to "sparclet-elf" and
willing to volunteer for the changes to be done.

However if the spaclet-aout is removed from the GCC 
3.3 release itself, the spaclet users would be 
deprived of the new optimizations that are planned 
for GCC 3.3. Please consider deprecating sparclet-aout
in 3.3 and removing in 3.4. By that time I may work on

and test "sparlet-elf" port.

> 
> If you have some download issue, you can always
configure the binutils
> to support conversion from ELF to a.out just to
create a download image.

Besides downloading, there are dependencies on aout 
stabs debug format in genereation of bin itself. So to

support ELF we need to make quite a lot of changes in 
our development framework too. I have just finished 
migrating our development environment from veteran 
egcs to GCC 3.2 and I had to make a few changes in our

framework due to the new stabs constructs being 
generated by GCC. To keep sync with lattest GCC 
releases we are willing to make further changes too, 
however it won't be feasible at such a short notice. 
If the community defers its plans  to 'remove' 
sparclet-aout till GCC 3.4 sparclet users
too would be able to keep pace with the GCC releases.

Thanks and Regards,
Nitin

________________________________________________________________________
Missed your favourite TV serial last night? Try the new, Yahoo! TV.
       visit http://in.tv.yahoo.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]