Subject: RE: mips support changes to libc
To: None <owner-port-pmax@NetBSD.ORG, port-pmax@sun-lamp.cs.berkeley.edu>
From: Adam Glass <adamg@microsoft.com>
List: port-pmax
Date: 08/31/1994 16:05:18
|
| *  From src/lib/libc/stdlib/strtod.c, line 192:
|
| #if defined(IEEE_8087) + defined(IEEE_MC68k) + defined(VAX) + 
defined(IBM) != 1
| Exactly one of IEEE_8087, IEEE_MC68k, VAX, or IBM should be defined.
| #endif
|
|    I think   MIPSEL fp is close enough to an 8087 for #define IEEE_8087
|    to   work, but I'd welcome a second opinion.

JT?

|
| *  The .if/.elif/.elif chains in Makefile.inc in
|    src/lib/libc/{gen,net,string} need to be updated to reflect the
|    contents of mips/arch.  Is there some way these Makefiles can include
|    a Makefile from ../$(MACHINE_ARCH) instead of explicitly coding in
|    the various Makefile.inc, those source modules that have optimized
|    assembler versions, for each and every architecture? Or perhaps
|    some string derived from $(MACHINE_ARCH_ could be added to VPATH?
|
|    Anyway, the patch that I used is appended below.
|
| *  The stabs produced by gcc 2.5.8 and 2.6.0 for __warn_references
|    on a MIPS don't work with a GNU as that has mips support.
|    I don't know how to fix this immediately, so I've temporarily
|    commented uses of __warn_references() out of my own source tree.
|
|    I'd welcome any better ideas.
|

the warn references should be better conditionalized, i agree

| *  I note in passing that PIC code will almost certainly never work on
|    a mips processor  without support for GP-relative addressing,
|    and all that implies.  So dynamically-linked shared libraries won't
|    work on a MIPS with the native NetBSD tools. And not having GP-relative
|    addressing implies a measurable runtime cost, even for statically-
|    linked binaries. I've seen reports that  GP-relative addressing can
|    give a speedup of from 5% to 20%, depending on the code. Personally
|    I don't see any gain, and some cost, in using "native" NetBSD a.out
|    on   mips   processors.
|

Well i think it would absolutely stupid and unmanageable for NetBSD to 
maintain a seperate tool chain for the MIPs.

However, I would like to pull in some of Ralph's work in doing 
GP-relative addressing on a slightly modified a.out.  We'll need it for 
other architectures in the future any way.

|    I understand and will accept arguments that it's better to have a
|    single, uniform object format. Personally, I'm still interested in
|    running ECOFF executables compiled from native NetBSD source and
|    letting them run with p_emul equal to EMUL_NETBSD. I don't expect
|    that that is necessarily the best decision for NetBSD as a whole,
|    though.
|

unfortunately it really isn't.  NetBSD's ultrix compatibility is a nice 
feature to have, but it really isn't the point of the exercise.....

|
| *** lib/libc/string/Makefile.inc.DIST	Thu Jul  7 01:14:05 1994
| --- lib/libc/string/Makefile.inc	Wed Aug 31 03:00:04 1994
| ***************
| *** 1,5 ****
|   #	from: @(#)Makefile.inc	5.6 (Berkeley) 3/5/91
| ! #	$Id: Makefile.inc,v 1.28 1994/07/06 04:07:53 mycroft Exp $
|
|   # string sources
|   .PATH: ${.CURDIR}/arch/${MACHINE_ARCH}/string ${.CURDIR}/string
| --- 1,5 ----
|   #	from: @(#)Makefile.inc	5.6 (Berkeley) 3/5/91
| ! #	$Id: Makefile.inc,v 1.1 1994/07/07 08:14:05 jonathan Exp jonathan $
|
|   # string sources
|   .PATH: ${.CURDIR}/arch/${MACHINE_ARCH}/string ${.CURDIR}/string
| ***************
| *** 41,46 ****
| --- 41,50 ----
|   SRCS+=	bcmp.c bcopy.c bzero.S ffs.S index.c memchr.c memcmp.c memset.c \
|   	rindex.c strcat.c strcmp.c strcpy.c strcspn.c strlen.S \
|   	strncat.c strncmp.c strncpy.c strpbrk.c strsep.c \
| + 	strspn.c strstr.c swab.c
| + .elif (${MACHINE_ARCH} == "mips")
| + SRCS+=	bcmp.S bcopy.S bzero.S ffs.S index.S memchr.c memcmp.c memset.c \
| + 	rindex.S strcat.c strcmp.S strcpy.c strcspn.c strlen.S \
|   	strspn.c strstr.c swab.c
|   .endif
|
|
| 

------------------------------------------------------------------------------