Date: Sat, 17 Mar 2012 00:05:08 -0600 From: Warner Losh <imp@bsdimp.com> To: Juli Mallett <juli@clockworksquid.com> Cc: "freebsd-mips@FreeBSD.org" <freebsd-mips@freebsd.org> Subject: Re: Unbreaking ports with n64 MIPS. Message-ID: <980330D2-1890-48DC-8D7C-5D831F18E42D@bsdimp.com> In-Reply-To: <CACVs6=_FXqM2vjx1B4C819kuapaCXek-RfVwo0YPsk74r4%2BgkA@mail.gmail.com> References: <CACVs6=8z4BYcpQ=jVKLLb7v2LmSD-MRxXQdYRrOj-hG1j572Cg@mail.gmail.com> <E580AB5B-AD2A-4E04-A040-8E9E5D667040@bsdimp.com> <CACVs6=_FXqM2vjx1B4C819kuapaCXek-RfVwo0YPsk74r4%2BgkA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 16, 2012, at 9:44 PM, Juli Mallett wrote: > Hey Warner & others, >=20 > 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: >=20 > http://people.freebsd.org/~jmallett/noeb.diff >=20 > I've decided not to make mips64eb (and mipseb and mipsn32eb) aliases, > but I'm willing to be convinced to do so. I went with mipseb and mips64eb for two reasons. The former because = NetBSD did it this way, and the latter for symmetry (NetBSD used mips64 = but allowed mips64eb as an alias). The n32eb ABI stuff I didn't do, and = agree with you: they aren't the architecture, since n32 binaries can = easily co-exist with n64. > 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. The argument for adding the alaises is transition from older release. > Two other things have come up on this thread: >=20 > 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. This is a bigger discussion. Several issues: (1) Multilib. If we had multilib, then we can build one or more of = {o32, n32, n64}. Then the ABI decision would be what to build for the = entire system. SGI used n64 for everything. Other systems have a = default ABI that we build. (2) What's the default ABI that tools produce? Is this tied to = MACHINE_ARCH? We spent a lot of time making sure that we have the right = default tools so we build everything correctly. (3) Do we support building other ABIs as part of the build system. We = had that before, but TARGET_BIG_ENDIAN removal killed that. There's = pros and cons of adding support here. Multiple ABIs does junk up a lot = of places in very machine specific ways. Lots of places need tweaking = if we go back to this. MACHINE_ABI is what we need. But do we really need it? If we want to = support building different ABIs for the same MACHINE_ARCH, then we'll = need some way to persist this so we can be self-hosting. Right now the = 'make this the default ABI' method for gcc/binutils persists this = information and makes things work nicely. sysctl likely is the way to = go here. mips*n32* has always been a hack of convenience. I'm pretty sure we're = the only ones that do it. > 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. I'm sure that this has decayed into dust. I tried to get gcc to = generate -msoft-float on x86, and it just didn't work. Today, I think = we burn this into the default settings of the toolchain we use to = bootstrap the system. We can have a knob for it, but it is purely a = userland concept: there's no floating point in the kernel to speak of. = MACHINE_FLOAT=3D{hard,soft} might not be a bad idea, with the value = exported via sysctl. Not sure if make needs to grow support for this = and MACHINE_ABI, or if it would suffice for the necessary Makefiles = and/or .mk files to query the sysctl value. > 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: >=20 > 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. >=20 > Have I missed a trick? Doesn't cache aliasing occur when you have multiple TLBs pointing to the = same physical page, which is a MIPSy no-no? I haven't thought about this in ages. I believe that it is complex to = design, but relatively simple to implement. I did some preliminary = looking into this a couple of years ago, but never made it out of the = early explorer stage for want of time. Warner > Thanks, > Juli. >=20 > On Thu, Mar 15, 2012 at 09:17, Warner Losh <imp@bsdimp.com> wrote: >> Hi Juli, >>=20 >> 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 was doing the stuff, but the pedants were against me and I didn't = have any good amo to push back at them. This would be a good reason. = The code 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 getting too gross you'll have to watch out for. >>=20 >> As for IRIX, n32 binaries were run on it, but there never was a n32 = kernel that I recall. It was just a funky ABI that you could compile = your programs to if they had problems with the n64 ABI. So the OS = didn't report anything special there. Our notion of an n32 kernel is = historically a bit funkadelic. >>=20 >> Warner >>=20 >>=20 >> On Mar 15, 2012, at 1:46 AM, Juli Mallett wrote: >>=20 >>> All, >>>=20 >>> Does anyone object to changing the target name of mips64eb to be >>> rendered as mips64? It'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. "mips64el" is, of course, recognized, but it's generally >>> assumed that MIPS is big-endian by default. I 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. I'm happy to make the relevant changes. >>>=20 >>> Thanks, >>> Juli. >>>=20 >>> 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. >>>=20 >>> PPS: What to do for n32? I 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. I 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" >>>=20 >>>=20 >>=20 >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?980330D2-1890-48DC-8D7C-5D831F18E42D>