Date: Thu, 13 Dec 2018 10:37:12 +0000 From: Brooks Davis <brooks@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: MIPS future... Message-ID: <20181213103712.GA49957@spindle.one-eyed-alien.net> In-Reply-To: <CANCZdfpK5mPDDgpJ5PVhXF7-MixSouW8mAKkWQcaRnmYW%2Bpy0g@mail.gmail.com> References: <CANCZdfpK5mPDDgpJ5PVhXF7-MixSouW8mAKkWQcaRnmYW%2Bpy0g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. >=20 > But this brings up a couple of issues I'd like to bring up. >=20 > 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. > 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 so= ne > 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. 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. -- Brooks --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJcEjZYAAoJEKzQXbSebgfAVo8H/iT6ix1kvvT3vx0mkslVNmze 3ojD72efSze8BJpqNYh0eeSmr2e5dIKupcTDrAAKL97hzK0+6gATexJ4WFHkPokg g/ILwcHETpEkyYLw/TckODzAYo8j/YeOK4NQ8/QS4S417o7oAT3KOHfqJp6dFGKR Hb5qBTqxA1/+l+KG/LwxHgHQjN93BaCylhgyOpjuPMChXhwZTGrg33V7jH0pVz66 +k3j+xBdNTO5xUE/Quj12Cfi/NjSTVDOwINRVGRQYz+xtVUWnEfMQnpNHUoVMd3M B2pq98f09kisi1IkfXJ/+H1TcFRZheYMLuXJq1lCiuG4WibOE1nyvxOUHsDF8oM= =Y8Gn -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20181213103712.GA49957>