Re: MMIX newlib port

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 12 Nov 2001, J. Johnston wrote:
> Hans-Peter Nilsson wrote:
> > BTW, I considered
> > using libgloss and -lnosys, but thought it was a worse solution
> > than including the stubs here.)
> >
>
> Actually, no, it is much better to put them in libgloss.

This is one point where I've made my mind up: no.  No it isn't;
by not having anything in libgloss means GCC just has to link in
crt0.o and libc.a to get a C library.  Simple. Otherwise, I have
to add at least a -lnosys in gcc library specs.  Unneeded,
unwanted.

>  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.

> A special libgloss library can be linked in for
> either
> situation.

For another mmix-*-* triple perhaps, but not for this one.
(Anyone, mmix-*-nnix?)  This isn't the typical system expected
to be run on e.g. a developer board or simulator, to be decided
with a compiler option.  This is simulator-only target, with the
interface if not carved in stone, then at least in print.  For
clarity, the interface to libraries should be kept simple, so
educators using it won't have to explain unnecessary details.
Other mmix-*-* triples shouldn't use the sys/mmixware files.

>  If the code is already in newlib, then a user cannot simply link in
> the
> appropriate library because the stub/etc. code in the sys directory always gets
> in the
> way.

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.)

> 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?

>  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?

brgds, H-P