Re: MMIX newlib port

["J. Johnston" <jjohnstn at cygnus dot com>]

Hans-Peter Nilsson wrote:
> 
> 
> >  Keeping them separate
> > from
> > newlib allows much more flexibility in the future.  Say, for example, a
> > simulator
> > is added or a new chip variant.
> 
> Not applicable.  Knuth's "mmix" simulator *is* the definition of
> the system in the mmix-knuth-mmixware "system".  So there will
> not be anything added for *that* triple.
> 

Fair enough.

> 
> A more applicable point (for the contrary view) is that by
> *needing* -lbsp -lnosys or similar, say, other peoples
> experimental-replacement C libraries would not simply have to
> replace crt0.o and libc.a, but would have to have extra parts
> for flexibility in areas where no changes will happen.
> 
> The stubs are located with the other mmixware "system" functions
> in sys/mmixware because those functions *can't* be implemented
> (AFAICS) on mmix-knuth-mmixware.  Keeping them in an extra
> possibly-overridable library can't improve things for the
> future, just clutter up the library specs.  If any of the system
> functions was to be be overridable, I shouldn't have added a
> sys/mmixware at all.  IIUC, sys/* and libgloss are expected to
> be mutually exclusive.
> 
> (I see other sys/* have everything in a single file, stubs and
> all.  That makes it kind of hard to override a subset of those
> functions.)
> 

Actually, some of those sys implementations have been a thorn in our
side, especially the sys/arm which is what I was alluding to.  Early
newlib implementors were treating platforms as systems which wasn't 
correct.

> > I was also wondering why you are creating a libfoo.a?
> 
> For no reason than the Makefile.am being copied from tic80 (same
> in cygwin), to get a compile rule for crt0.o.  Makefile.am says,
> alluding to compiling crt0.c, I guess:
>  # This is a hack to force automake to include a definition for
>  # COMPILE.
> Is it not needed?
> 

No.  You can see an example in the sys/arm directory.  I can do
this for you.

> >  In general, most
> > compilers
> > link in crt0.o plus a default libgloss library or leave it up to a linker
> > script.
> 
> That'd be an extra linker script, where one isn't needed.
> IIUC, most compilers using newlib aren't targetting a specific
> system, but a target board with an monitor interface defined in
> libgloss, expected to be overrided for the application run-time
> system or by a simulator.
> 
> > You could simply add a linker script in the libgloss directory or else you could
> > arrange
> > something with gcc.
> 
> No thanks, things work fine right now as they are, as submitted,
> without no non-default linker scripts.  No changes to add linker
> scripts or linking in other libraries.  Again, the "mmix"
> simulator *is* the mmixware "system", limited as it is.
> (Complaints to Knuth; winners collect $2.56 and a T-shirt. :-)
> 
> > BTW: I will do the regeneration of the configuration files so don't worry.
> 
> Thanks.
> 
> So, do you accept the port as is after this ehm, explanation?
>

Yes.
 
-- Jeff J.