Date: Fri, 16 Mar 2012 20:44:27 -0700 From: Juli Mallett <juli@clockworksquid.com> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: Unbreaking ports with n64 MIPS. Message-ID: <CACVs6=_FXqM2vjx1B4C819kuapaCXek-RfVwo0YPsk74r4%2BgkA@mail.gmail.com> In-Reply-To: <E580AB5B-AD2A-4E04-A040-8E9E5D667040@bsdimp.com> References: <CACVs6=8z4BYcpQ=jVKLLb7v2LmSD-MRxXQdYRrOj-hG1j572Cg@mail.gmail.com> <E580AB5B-AD2A-4E04-A040-8E9E5D667040@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hey Warner & others, Here's the patch I intend to commit in the near future, and then I'll add an UPDATING entry and send out an E-Mail blast to the list: http://people.freebsd.org/~jmallett/noeb.diff I've decided not to make mips64eb (and mipseb and mipsn32eb) aliases, but I'm willing to be convinced to do so. It's a simple matter then to have a single regex in the few things that report the TARGET_ARCH or MACHINE_ARCH (e.g. GCC) that converts those aliases to the canonical values, and to otherwise just expand the regexes in this patch a little bit. We wouldn't report things with eb in them anywhere, and self-hosted builds would work, but it seems like we have a small enough community of MIPS users that this actually won't be a big deal. I'm willing to do the work on aliases, but only if there's strong requests. Two other things have come up on this thread: 1) n32 is an ABI not a sensible TARGET_ARCH. We need TARGET_ABI. We need GCC to report something like mips64-freebsdelf or freebsdelfn32 or freebsdn32 or whichever. We need things to be able to detect that. Anyone who cares about n32 should really work on making it easy to use n32 worlds on n64 kernels. I'm happy to help with this as I have a pretty good idea where the pitfalls are, but it's non-trivial work, and involves putting conditionals all through the 32-bit compat code. For worlds, n32 should not be a TARGET_ARCH. Kernels should not be n32. And so on. 2) Soft- vs. hard-float. How should a user select? We used to have some way, I know, for x86 systems which needed soft float, so they didn't use the slower fp emulation in the kernel. Another conversation I want to have is about pmap, and since I don't want to write out enough to start a whole thread about it, and I hope everyone's reading this, and I've already covered some far afield stuff, here: We need to be thinking about superpages. This is non-trivial even though MIPS is just about ideal for superpages. For one thing, it'd be really nice if we did not split TLB entries as we currently do, so the default PAGE_SIZE would be 8K, and then we wouldn't have to deal with TLB behavior where superpages are involved. Does the TLB always use the nearest match? How does it impact performance to have two TLB entries covering the same range of addresses? It depends on how the hardware implements TLB lookups, yes? Wouldn't it be nice to not have to split the TLB? Wouldn't it? I know I bring this up a lot, but it seems like it really would make superpages just slightly less ugly. I mean, you do tlbp and you find that your VA is covered by the TLB, but the entry it's in is split, and your VA isn't covered by a superpage, but the one in the TLB is, so you have to add a more specific entry, and suddenly all of your functions using the TLB have gotten non-trivially complex. Have I missed a trick? Thanks, Juli. On Thu, Mar 15, 2012 at 09:17, Warner Losh <imp@bsdimp.com> wrote: > Hi Juli, > > I'd be fine with mips64 and mips64eb being the same, and moving from the = former to the latter as the uname reported value. I almost did it when I wa= s doing the stuff, but the pedants were against me and I didn't have any go= od amo to push back at them. =C2=A0This would be a good reason. =C2=A0The c= ode was a little simpler when I always specified the eb on the end for all = mips ports, so there's some tricks in the tree to keep expressions from get= ting too gross you'll have to watch out for. > > As for IRIX, n32 binaries were run on it, but there never was a n32 kerne= l that I recall. =C2=A0It was just a funky ABI that you could compile your = programs to if they had problems with the n64 ABI. =C2=A0So the OS didn't r= eport anything special there. =C2=A0Our notion of an n32 kernel is historic= ally a bit funkadelic. > > Warner > > > On Mar 15, 2012, at 1:46 AM, Juli Mallett wrote: > >> All, >> >> Does anyone object to changing the target name of mips64eb to be >> rendered as mips64? =C2=A0It's difficult to build ports because although >> the redundant "mipseb" as widely-recognized as synonymous as "mips", >> our quirky use of "mips64eb" instead of "mips64" just plain breaks >> stuff. =C2=A0"mips64el" is, of course, recognized, but it's generally >> assumed that MIPS is big-endian by default. =C2=A0I understand this >> assumption wasn't made in FreeBSD because the port that was committed >> focused early on a number of little-endian MIPS systems, but it seems >> worthwhile to switch. =C2=A0I'm happy to make the relevant changes. >> >> Thanks, >> Juli. >> >> PS: This may only need to be changed in how we name things in our GCC >> and binutils to fix ports, but I'd rather change everything else to >> match for the sake of consistency. >> >> PPS: What to do for n32? =C2=A0I think mips64{,el} is right for GCC and >> binutils, with something like "n32" in the OS name, but I haven't >> booted IRIX in almost a decade, so I can't remember what the >> convention is. =C2=A0I don't even know if there's software in ports that >> would care. >> _______________________________________________ >> freebsd-mips@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-mips >> To unsubscribe, send any mail to "freebsd-mips-unsubscribe@freebsd.org" >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACVs6=_FXqM2vjx1B4C819kuapaCXek-RfVwo0YPsk74r4%2BgkA>