This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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: Ping/Repost (Updated 20120127): RFA: Add Epiphany newlib & libgloss port


On Friday 02 March 2012 01:22:59 Joern Rennecke wrote:
> Quoting Mike Frysinger <vapier@gentoo.org>:
> > similarly, what's the point of
> > libc/machine/epiphany/machine/stdlib.h ?  seems
> > like that should just get dropped.
> 
> There some tests in the GCC testsuite that require random.
> This header file allows these test to compile.

my point was more that this code is not specific to epiphany at all.  if you 
need to extend common code, then you should be doing it in common locations 
and not adding stuff to machine-specific subdirs.  the point is to unify, not 
diverge.

> > similarly, i think you've copied useless stuff into your
> > Makefile.in.  i'd drop
> > the pattern rules for .c.o, .C.o, .S.o, .s.o, and .c.s.
> 
> That's not such a good idea:

the real problem seems to be you're not using @host_makefile_frag@.  look at 
how the bfin/Makefile.in is written.

> > AR_FLAGS in Makefile.in should probably be "rc" instead of "qc".
> 
> Some ports use q, some r, some both... libnosys uses qc ...
> Whatever.  Where this makes a semantic difference, there are probably other
> issues, but any speed advantage is likely in the noise anyway.

except "q" could give misbehavior for systems that implemented it as an append 
w/out replacement.  libnosys imo should be changed to do "rc".  it isn't a 
speed issue.

then again, once you use @host_makefile_frag@, this is a non-issue.

> > the style in all of the C files could do with cleaning up.  please review
> > the GNU coding style.  i believe `indent` should help with that.
> 
> Is newlib/libgloss now supposed to follow the GNU coding style?
> I thought the general policy was to keep the coding style of each file as
> chosen by the first author ... well, at least if they have used any,
> and unless you do a complete rewrite.
> I've looked throigh some in-source and web documentation, but there
> doesn't seem to be any statement on that point.

Jeff would have to answer.  imo, it should be:
 - code written for newlib/libgloss should be GNU style
 - code imported from other sources (with compatible license) does not need 
style changing

since much of this code falls into the first category, it should use that style

> > i don't think you should be adding access.c in the epiphany-specific
> > subdir. this would be better implemented in common code.
> 
> A number of existing ports already have their own copy.
> I agree that adding it to the common code makes sense, but this is really
> a separate issue from adding a new port using the existing infrastructure.

so post patches to fix that instead of continuing to diverge.  existing bad 
behavior doesn't really justify adding more bad behavior.  this is a community 
project, so expecting "someone else" to always do the work isn't how things 
grow.

> > why do you implement _execve() and _fork() and _getpid() and _times() and
> > _wait() ?  libnosys already provides those stubs.
> 
> The errno handling in libnosys is somewhat dicy.

so post patches to fix that

> Also, having separate copies in the epiphany subdir allows to add section
> attributes to keep I/O stuff out of the limited on-chip RAM space.
> Note that getpid also different, it succeeds returning 1.

i don't buy the section argument.  you can easily do this with a linker script 
as the GNU linker allows selection based on symbol names, objects, etc...  
i've done this plenty of times.

> > also, does your gcc port not support naming of specific registers in
> > inputs/outputs ?  it's much better to write:
> >       asm volatile ("trap %[trapnr]"
> >       
> >               : "=r0"(result), "=r3"(error)
> >               : [trapnr] "i"(TRAP_write), "r0"(CHAN), "r1"(ADDR),
> >               : "r2"(LEN));
> 
> Huh?  You can name registers in clobber lists, but not for inputs / outputs
> the way you show above.

what is valid in constraints depends entirely on the gcc port.  there are 
common ones, and then each machine port defines all their own.  hence i asked 
"does your gcc port ...".
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.


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