Date: Thu, 13 Dec 2018 08:21:20 -0700 From: Warner Losh <imp@bsdimp.com> To: Brooks Davis <brooks@freebsd.org> Cc: freebsd-mips@freebsd.org Subject: Re: MIPS future... Message-ID: <CANCZdfqTsf62dcecF3vhg1CBrx1BMuW9v_pASEWvVnmwNGKg0A@mail.gmail.com> In-Reply-To: <20181213103712.GA49957@spindle.one-eyed-alien.net> References: <CANCZdfpK5mPDDgpJ5PVhXF7-MixSouW8mAKkWQcaRnmYW%2Bpy0g@mail.gmail.com> <20181213103712.GA49957@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 13, 2018, 3:37 AM Brooks Davis <brooks@freebsd.org wrote: > On Wed, Dec 12, 2018 at 11:15:06AM -0700, Warner Losh wrote: > > OK. To be a good player in the FreeBSD ecosystem, we need to do a few > > things. > > > > First, we need to implement atomic_swap_64. hps did this for mips64 and > > committed it. He sent me some further patches for it that I need to > commit > > when I get a change, maybe at the airport tonight. > > > > But this brings up a couple of issues I'd like to bring up. > > > > First, to implement atomic_swap_64 on mips-32 is hard. In that it's not > > just the canonical ldd/sdd sequence because those aren't available there. > > We can do the standard trick of reading STATUS0, clearing IE, storing it, > > do the operation and then restoring STATUS0. This is efficient enough for > > the use in the kernel for the supported cores we have. > > I think we have to do this no matter how expensive it is or kill 32-bit > mips. There is no way there are enough 32-bit mips users to justify > even the minor level of developer friction the unr64 caused. > Yes. That's the plan. The question is how. And part of that how is giving up on mips32 ISA (and requiring mips32r2 or newer). So I'll be doing that. We have one SMP platform for 32bit mips that will have to die. It is only 4 years old, but the design never caught on. > That brings me to my next question: SWARM. Can we kill SWARM entirely? > It's > > for the BCM1250 part, released in sometime before 2000. It was super > > popular because it was the reference for a ton of things that followed. I > > think it's run is over and we can remove it. I can find no users of it in > > the nyc dmesg database. Mine has been in a plastic bag since before my > sone > > was born in 2006... So I'm thinking we can remove this platform. It was > on > > the edge last time I did a GC in mips-land. > > It looks like it's a sibyte platform if I read the config files > correctly. If so, I seriously doubt it works reliably under meaningful, > multi-process load. We built at sibyte-like PIC for BERI and there were > quite a few WTF moments as we adapted to code. > That confirms my expectations. It was shakey back in the day, and it can only be worse now... I don't have strong opinions on the other platforms. I know we haven't > used GXEMUL in at least 5 years on our projects. Qemu and the MALTA > config does everything we need. > Ok. I think gxemul users have moved to qemu and the burden of supporting two emulators is too great. Warner >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqTsf62dcecF3vhg1CBrx1BMuW9v_pASEWvVnmwNGKg0A>