From owner-freebsd-mips@freebsd.org Sun Jan 7 21:31:07 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5372EE5EF9A; Sun, 7 Jan 2018 21:31:07 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B21C79ED1; Sun, 7 Jan 2018 21:31:06 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 727475A9F14; Sun, 7 Jan 2018 21:30:59 +0000 (UTC) Date: Sun, 7 Jan 2018 21:30:59 +0000 From: Brooks Davis To: Warner Losh Cc: Alexander Kabaev , "freebsd-embedded@freebsd.org" , Robert Watson , "freebsd-mips@freebsd.org" Subject: Re: Minor MIPS tree pruning Message-ID: <20180107213059.GH95035@spindle.one-eyed-alien.net> References: <20171230114420.3154579c@kan> <20180105225153.GF95035@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QWpDgw58+k1mSFBj" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jan 2018 21:31:07 -0000 --QWpDgw58+k1mSFBj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 05, 2018 at 03:59:09PM -0700, Warner Losh wrote: > On Fri, Jan 5, 2018 at 3:51 PM, Brooks Davis wrote: >=20 > > On Sat, Dec 30, 2017 at 11:44:20AM -0500, Alexander Kabaev wrote: > > > On Sat, 30 Dec 2017 01:10:11 -0700 > > > Warner Losh wrote: > > > > > > > I'd like to propose that we eliminate support for the following > > > > before the FreeBSD 12 branch. > > > > > > > > adm5120 (most boards don't have enough memory, very old) > > > > alchemy (the au1xxxx port never really was finished, and boards lack > > > > memory, very old) > > > > idt (only a few boards worked, most are long obsolete) > > > > rt305x (raylink kit is now out dated, at least I think so) > > > > sibyte (long obsolete, hard to get hardware) > > > > > > > > I thought I'd post a heads up here before I proposed this list to > > > > arch@. > > > > > > > > We have enough exemplars these days we don't need to keep these old= er > > > > ports around as examples anymore, and I have my doubts if we even > > > > work on these boards anymore. > > > > > > > > If I'm wrong about these being old, or that FreeBSD is no longer > > > > running on them, please let me know. Thanks! > > > > > > RMI is another one that should get on chopping block, IMHO. They are > > > impossible to track down in the wild and files were not touched more = or > > > less ever since being committed. They also re-implement too much of t= he > > > code in MI and chances of FreeBSD-current working on the hardware are > > > very, very slim. > > > > Deleting that would clean up a fair number of ifdefs in MIPS MD code. >=20 >=20 > I went ahead and deleted the platform, but was holding off doing ifdef > cleanups from the removed platforms until a suitable period of time had > passed to ensure that I didn't delete one that turns out to be in wide use > leading to a hue and cry for its return. Sounds good. -- Brooks --QWpDgw58+k1mSFBj Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaUpGSAAoJEKzQXbSebgfAfScH/jK2Kj519g3y4GRTfULyXPak RsGCVj3qR7GghnPFNbEgJ7dS6pzZswRbcLGsKTOyXKwDzECuyPdaqhg1oF/J4NNW n2QwiouQE7HXNGbPiGpTVdrE17iDxSOVepmkV3epII9EqQT7PgjSX5BUUGsbYKMH DuCAqnHHK/LjXp1a/UkSOiLX12vh9IzrKSeixXwf2nNAhXn5KSTe6tPqA9Kr/8ro tE5lHlqgBcdo9RJq7HSZUGIweEz06fWuuc74fAOnKr/n2iq6SyeUtJr08vmxcLKy YupcWRYJyks+NYUj+SQLIrs8O2z91dsRIt7Igoe1TXiq8yzZtdHxQDyKFVF+J/4= =4iWV -----END PGP SIGNATURE----- --QWpDgw58+k1mSFBj-- From owner-freebsd-mips@freebsd.org Tue Jan 9 11:53:43 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EA70E78ABF for ; Tue, 9 Jan 2018 11:53:43 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F059278C64; Tue, 9 Jan 2018 11:53:42 +0000 (UTC) (envelope-from mizhka@gmail.com) Received: by mail-qk0-x231.google.com with SMTP id l12so17786016qke.13; Tue, 09 Jan 2018 03:53:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=RzPnYXk6GxiuXe3oSnZP4LpOsI/4PBnDVIRjNf61qqY=; b=VrfbvDcIXS7QNxq45wnVp85yT5E5sa6oFfL9y/3j5J0fna4KS523I/pQgc28/zwHh3 zakTvGO8mjX/6en3VbZ8GGRySW6qTpiA//Ktw1BfYSkc7+vGnrEeOQJBrkfzeTMOwIJN vAI95PyF7EnzfO0cJLP+ERFjoXEB0DqVKiSVDj5SSXaogQkbONqHSjOM05MB6Y5EklJ2 /kSCAaQgHJ7eXpDNpJ25jz7bwxPst5vvn3IRtV8gmtQVfQE+yFhLt9H+XWaaNPNTFL7e BFW2lfemvAiaTgQE5Sr5SGA+3xoOVjVNsJWghBij6NnfHaMSTG5HAG/pbOvbCTqF6Ie1 dhbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=RzPnYXk6GxiuXe3oSnZP4LpOsI/4PBnDVIRjNf61qqY=; b=HKYjqDM1YuPpQ0UU1DyhN97SMaAwkKraIi791Ng7QNc1f+JK/qEaW2m73f3IaUbxdD X/S/HKxIAIYOqwJxVkRJ4lBUU8yWNguHaF7CyV8+DoaPcMtNIj6StAgZmSxcX0ws5GwM +rzCoOdirfhOvp2t3LPY2/9b/uiXMdboXwiVpqPR5qA2JX73U8pdrMplTYTborztoI32 j2PZ8P+NBCcny9miTUN3Slidl/MX1iDRDxYVrwm6NrK++/JBoHCypHs9oi1+bMQT/Ly4 FS8YdW/9mPpm9YMciVALBqiIV9mBEWu8eTbGfQaV92oGNy4Kt7IG4v1pOnjyJJ+j+9ZM H6SQ== X-Gm-Message-State: AKwxytelDLoPFUWc14PakWaLnlYDjaH5HLf6fOetyo7McW/O9Bava59L B/IqvPgit81Ms3yvXY7BYWB9yMFIwhjIp9Zlq/b3qfJQ X-Google-Smtp-Source: ACJfBou0MV5wqYuR/v8yjg0pHNlVUix9sIl3xZdZbCHfb5EcoUJ09RaZsBhxvTOQkN39Gh8OESf20Iqxe+AWhoGA4OE= X-Received: by 10.55.162.140 with SMTP id l134mr21208526qke.124.1515498821812; Tue, 09 Jan 2018 03:53:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.89.244 with HTTP; Tue, 9 Jan 2018 03:53:40 -0800 (PST) In-Reply-To: References: <201801090328.w093SOVW053959@repo.freebsd.org> From: Michael Zhilin Date: Tue, 9 Jan 2018 14:53:40 +0300 Message-ID: Subject: Re: svn commit: r327715 - head/sys/conf To: Conrad Meyer , freebsd-mips@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 11:53:43 -0000 Thank you, Conrad! Under GCC6 it complains to: undefined reference to `__bswapsi2' Full build log is attached. bswapsi2 is easy to implement for mips32. I'll try it this week. + freebsd-mips in loop Thanks! On Tue, Jan 9, 2018 at 9:13 AM, Conrad Meyer wrote: > Either add a diff to the vendor code (undesirable) or implement ctzdi2 on > those platforms. > > On Mon, Jan 8, 2018 at 9:12 PM Michael Zhilin wrote: > >> Hi, >> >> Could you please tell what is plan to back MIPS works? >> >> Thanks! >> >> On Tue, Jan 9, 2018 at 6:28 AM, Conrad Meyer wrote: >> >>> Author: cem >>> Date: Tue Jan 9 03:28:24 2018 >>> New Revision: 327715 >>> URL: https://svnweb.freebsd.org/changeset/base/327715 >>> >>> Log: >>> Fix Zstd kernel build with GCC 4.2 >>> >>> By disabling the -Winline warning. Fixes the powerpc and sparc64 build >>> after r327706. >>> >>> Note: MIPS and RISCV builds still broken due to absense of __ctzdi2 >>> (aka >>> __builtin_ctzll) in their libgcc or libcompiler-rt libraries. >>> >>> Reported by: markj >>> Sponsored by: Dell EMC Isilon >>> >>> Modified: >>> head/sys/conf/kern.pre.mk >>> >>> Modified: head/sys/conf/kern.pre.mk >>> ============================================================ >>> ================== >>> --- head/sys/conf/kern.pre.mk Tue Jan 9 01:41:55 2018 >>> (r327714) >>> +++ head/sys/conf/kern.pre.mk Tue Jan 9 03:28:24 2018 >>> (r327715) >>> @@ -133,7 +133,7 @@ NORMAL_FWO= ${LD} -b binary --no-warn-mismatch -d >>> -war >>> -m ${LD_EMULATION} -o ${.TARGET} ${.ALLSRC:M*.fw} >>> >>> # for ZSTD in the kernel (include zstd/lib/freebsd before other CFLAGS) >>> -ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd >>> ${CFLAGS} -I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR} >>> -Wno-missing-prototypes ${PROF} ${.IMPSRC} >>> +ZSTD_C= ${CC} -c -DZSTD_HEAPMODE=1 -I$S/contrib/zstd/lib/freebsd >>> ${CFLAGS} -I$S/contrib/zstd/lib -I$S/contrib/zstd/lib/common ${WERROR} >>> -Wno-inline -Wno-missing-prototypes ${PROF} ${.IMPSRC} >>> >>> # Common for dtrace / zfs >>> CDDL_CFLAGS= -DFREEBSD_NAMECACHE -nostdinc >>> -I$S/cddl/compat/opensolaris -I$S/cddl/contrib/opensolaris/uts/common >>> -I$S -I$S/cddl/contrib/opensolaris/common ${CFLAGS} >>> -Wno-unknown-pragmas -Wno-missing-prototypes -Wno-undef >>> -Wno-strict-prototypes -Wno-cast-qual -Wno-parentheses -Wno-redundant-decls >>> -Wno-missing-braces -Wno-uninitialized -Wno-unused -Wno-inline -Wno-switch >>> -Wno-pointer-arith -Wno-unknown-pragmas >>> >>> >> From owner-freebsd-mips@freebsd.org Wed Jan 10 19:54:37 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AA8EE730FA for ; Wed, 10 Jan 2018 19:54:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 2814C68B55 for ; Wed, 10 Jan 2018 19:54:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 24523E730F9; Wed, 10 Jan 2018 19:54:37 +0000 (UTC) Delivered-To: mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23F51E730F7 for ; Wed, 10 Jan 2018 19:54:37 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 04A1D68B54 for ; Wed, 10 Jan 2018 19:54:36 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (astound-66-234-199-215.ca.astound.net [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id E124D10A8BC for ; Wed, 10 Jan 2018 14:54:34 -0500 (EST) From: John Baldwin To: mips@freebsd.org Subject: Switch to hard-float by default? Date: Wed, 10 Jan 2018 11:54:26 -0800 Message-ID: <2059726.KWgedH7NrU@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Wed, 10 Jan 2018 14:54:35 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 19:54:37 -0000 I have been working on LLVM libunwind patches for MIPS and the last round has been to teach the unwinder to handle hard-float. As part of this I just fixed a bug which had broken HF support for N32 (in review now), and I have a working 'mipsn32hf' world that boots under qemu. However, if I add 'mipsn32hf' to the list of known targets that is yet another world to add to make universe. I wonder if instead we should consider switching MIPS to assume hard-float by default? We made that change for 32-bit arm recently. The simplest approach would be to add 'mipsn32hf' and then remove all the non '*hf' targets from Makefile.inc1 (if we only wanted to support HF). A more drastic approach would be to change the existing 'mips*' targets to assume hard-float, remove all the '*hf' targets (which are only in 12 anyway I think?) and add in explicit '*sf' targets if anyone has a need for them. Given that none of the *hf targets have been MFC'd are only present in 12 anyway, maybe the more drastic route is actually better? If we do go that route, does anyone have a use case for a '*sf' target? That is, is anyone running FreeBSD/mips on a processor that does not include an FPA? -- John Baldwin From owner-freebsd-mips@freebsd.org Wed Jan 10 20:29:34 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BFF48E74D4F for ; Wed, 10 Jan 2018 20:29:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3896A7B8 for ; Wed, 10 Jan 2018 20:29:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 95487E74D4E; Wed, 10 Jan 2018 20:29:34 +0000 (UTC) Delivered-To: mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94C8AE74D4D for ; Wed, 10 Jan 2018 20:29:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B6156A7B7 for ; Wed, 10 Jan 2018 20:29:34 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id t63so834772iod.0 for ; Wed, 10 Jan 2018 12:29:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BcpHIAAsgSmsBQfYuJMDfrEyMxSQ/h0o5FY4KgGGxb4=; b=OiVygFWgtken/YRgfYNaw4CkhCrUp5qjz3xVJogLct3rWtNpTBpIgR6wRUd+XyO4E8 NEAVnmFFpaXHWbZmMWjcRQLnZyE+tluTc1LJHOc4T1F7meNPd92mGfezg11EzQorGcPL z0SKV0uWEyg3BKsxuaAMQwEBwmXYc6au+1LciV/SC5ybv3JJNHVtH0+ejZw3KpyBeTvr 5MTIDzaFPaHrrOajN0X4T1BtWsR2PFd2G3hrKHpDYwanYigbrUYl8ztKzlU7IbZ+J0d3 tfVgNYeCWMbFxcoBqOQ/pisIp2UfN2Xjg8wUefRdfAE/LvYMKPP4Of4b32jwR1MRxuNC fCYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BcpHIAAsgSmsBQfYuJMDfrEyMxSQ/h0o5FY4KgGGxb4=; b=Ud5/ZhFSaYA+z/ka3AasfhywlvfbfKmxDHiu7DISLfSgjNjxKq2Q4mLGyRAo+YFiy/ s3n2K47ChCAZsCRSgOIP5aOK0bkUV+iA5/EMIZEPISGAiyG0e0I+2aXJPNiIt0MBfpTP xAApHsYt5o0nZAn3z8f1bweK/KG+YuWGmrLrWsdWTjhatci8SBIeVW4sKWi4N+MM5tXx OLrWdf6O+LB8FHwED3LEhbuXfjnEKW3AWgyC2wQxIoOEzvOy+ePEeYehKSZ4MNVY3++n FeyjgSiYqKRIFUh/LAu6HtRAqyE1Q4F8hFTpVfSN6ihZzFI0bqPAAZ5sadAx/huPim92 3qGQ== X-Gm-Message-State: AKGB3mJrRATVO/9RTvrXAjlG6y9LFuD8EMS4THiYHKGeMnCHnnOykZbz fZHnMdVVwi/qK88AZI8Ma8F27eQzbE5tSoviwHcVoA== X-Google-Smtp-Source: ACJfBov5vBtryYRHtS0rh3KQfUQacgZ/R11LTeZB+OZJ4UE7tr9VG+y18mh3B/CLlR/ZP98Bd8cGB/KlYarOqDnaffM= X-Received: by 10.107.142.143 with SMTP id q137mr19828450iod.301.1515616173667; Wed, 10 Jan 2018 12:29:33 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.160.217 with HTTP; Wed, 10 Jan 2018 12:29:33 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <2059726.KWgedH7NrU@ralph.baldwin.cx> References: <2059726.KWgedH7NrU@ralph.baldwin.cx> From: Warner Losh Date: Wed, 10 Jan 2018 13:29:33 -0700 X-Google-Sender-Auth: 616I5QeAnX6W4oqrKassUwpp7eU Message-ID: Subject: Re: Switch to hard-float by default? To: John Baldwin Cc: "freebsd-mips@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 20:29:34 -0000 On Wed, Jan 10, 2018 at 12:54 PM, John Baldwin wrote: > I have been working on LLVM libunwind patches for MIPS and the last round > has > been to teach the unwinder to handle hard-float. As part of this I just > fixed > a bug which had broken HF support for N32 (in review now), and I have a > working 'mipsn32hf' world that boots under qemu. However, if I add > 'mipsn32hf' to the list of known targets that is yet another world to add > to make universe. I wonder if instead we should consider switching MIPS to > assume hard-float by default? We made that change for 32-bit arm recently. > > The simplest approach would be to add 'mipsn32hf' and then remove all the > non '*hf' targets from Makefile.inc1 (if we only wanted to support HF). A > more drastic approach would be to change the existing 'mips*' targets to > assume hard-float, remove all the '*hf' targets (which are only in 12 > anyway > I think?) and add in explicit '*sf' targets if anyone has a need for them. > Given that none of the *hf targets have been MFC'd are only present in 12 > anyway, maybe the more drastic route is actually better? If we do go that > route, does anyone have a use case for a '*sf' target? That is, is anyone > running FreeBSD/mips on a processor that does not include an FPA? > I think that I retired the last set of SoCs that only had soft float. I think this is a good idea. The only use case I can think of is if I'm wrong and some of the early Atheros SoCs can do soft float. But then we'd just have one supported soft-float platform to worry about rather than the full generality we have now. Warner From owner-freebsd-mips@freebsd.org Thu Jan 11 00:57:05 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 038CBEA4F79 for ; Thu, 11 Jan 2018 00:57:05 +0000 (UTC) (envelope-from mips@inferiorhumanorgans.com) Received: from gaz.inferiorhumanorgans.com (198-27-242-154.fiber.dynamic.sonic.net [198.27.242.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gaz.inferiorhumanorgans.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E184B760BC for ; Thu, 11 Jan 2018 00:57:04 +0000 (UTC) (envelope-from mips@inferiorhumanorgans.com) Received: from gaz.inferiorhumanorgans.com (localhost [127.0.0.1]) by gaz.inferiorhumanorgans.com (Postfix) with ESMTP id EA7AF656E8 for ; Wed, 10 Jan 2018 16:49:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=inferiorhumanorgans.com; h=date:from:to:subject:message-id:mime-version:content-type :in-reply-to; s=mail; bh=GSnGcgcyG+mBVDeyQ6UVsEGFm2bitUaiCvZkIvs NRXI=; b=rm8qVymn4L5Pzh3lKZh1vQGUaLRR7Ct5fsR/57AJf/d1O8bsmhWRT8S QvY4PIfg3n+S9X3iPZ3grmjluphQLJhk6nCGQhSWNqcZr2UbVK1Q9BUAE/qWFuAh qncWxrPqrPWARljJqnThJtQIZpx8rP5LUEMJ6drIvUJoJLZN+s+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=inferiorhumanorgans.com; h= date:from:to:subject:message-id:mime-version:content-type :in-reply-to; q=dns; s=mail; b=t9Y6sqTDwl5Y7NXhS3MA0zFoMvuuJd3+y 1Vp+yVjsdpDVV3JlQurWNJjAl312+z+8WPVjlRcXxXEaokJUb5taKf72K0KaAPa3 t/JjK8yZRWFEC+xIjnGfPUwIF7Z/HXccg2Eh4xSg2x1JC0+/+LBJOYhv1TC7nWRN 1F2jBuYAK4= Received: by gaz.inferiorhumanorgans.com (Postfix, from userid 1001) id DEDC2656E7; Wed, 10 Jan 2018 16:49:29 -0800 (PST) Authentication-Results: gaz.inferiorhumanorgans.com; dkim=none Date: Wed, 10 Jan 2018 16:49:29 -0800 From: Alex Zepeda To: freebsd-mips@freebsd.org Subject: Re: Switch to hard-float by default? Message-ID: <20180111004929.GA17499@bloaty> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 00:57:05 -0000 > On Wed, Jan 10, 2018 at 12:54 PM, John Baldwin wrote: > > > I have been working on LLVM libunwind patches for MIPS and the last round > > has > > been to teach the unwinder to handle hard-float. As part of this I just > > fixed > > a bug which had broken HF support for N32 (in review now), and I have a > > working 'mipsn32hf' world that boots under qemu. However, if I add > > 'mipsn32hf' to the list of known targets that is yet another world to add > > to make universe. I wonder if instead we should consider switching MIPS to > > assume hard-float by default? We made that change for 32-bit arm recently. > > > > The simplest approach would be to add 'mipsn32hf' and then remove all the > > non '*hf' targets from Makefile.inc1 (if we only wanted to support HF). A > > more drastic approach would be to change the existing 'mips*' targets to > > assume hard-float, remove all the '*hf' targets (which are only in 12 > > anyway > > I think?) and add in explicit '*sf' targets if anyone has a need for them. > > Given that none of the *hf targets have been MFC'd are only present in 12 > > anyway, maybe the more drastic route is actually better? If we do go that > > route, does anyone have a use case for a '*sf' target? That is, is anyone > > running FreeBSD/mips on a processor that does not include an FPA? > > > > I think that I retired the last set of SoCs that only had soft float. > > I think this is a good idea. > > The only use case I can think of is if I'm wrong and some of the early > Atheros SoCs can do soft float. But then we'd just have one supported > soft-float platform to worry about rather than the full generality we have > now. > > Warner Are you sure? I'm pretty sure a lot of the 32 bit SoCs don't have FPUs standard. I'm currently poking at a MediaTek 7621 board (EdgeRouter X) and it doesn't have an FPU. Looking through the MediaTek documents it looks like FPUs are an optional accessory on many of their SoCs. AZ From owner-freebsd-mips@freebsd.org Thu Jan 11 03:10:27 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F19DFE668D0 for ; Thu, 11 Jan 2018 03:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49B007B436 for ; Thu, 11 Jan 2018 03:10:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-wm0-x22f.google.com with SMTP id x4so736126wmc.0 for ; Wed, 10 Jan 2018 19:10:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1wlH4/Vup2EnfFKVIafHmnSX99suCcj3F6s75hs+tCA=; b=FCrEVn4I/UsC0E/iKONlM9Smj6PtB7VyFVAlvNEu9wLAGp7HPX3w+dNfFNfU+0zIBG 1XgZLWzN4odpO43Ia5fpuvK/fVvBhKM+mBzKJYCJ3hBD7XNNYHh20ruXfJMOOC6NPyVv fOcRFp/6HUsFNmv3boNE6rvW/QX9ZpU3iA/9unVzInXDDD9rkciP9a1U+TZjmSL0Dbk7 zX1WZxLZ/osVoFAVrBZaRtjGkb7uAOaEksm5Dy10QLT8ZTr8LhDygWcvboxx7Vw6OROd Tw23JfORjMF4bF+h4+U5+ZZiJ30QLQq9IZbrFD317VKo5sPM/ASuLC8ug91oQbvp43g1 a/dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1wlH4/Vup2EnfFKVIafHmnSX99suCcj3F6s75hs+tCA=; b=XDVcRkKUvoNuiiO+Mzq7FKUssaUwCZENTrNl3SF9dKNNY69W+PjaKJkyUhjUGD8f3H T6k175/tZU+mi/iDNuqxn+fDZhUXqjpEEHjyNQgRwqiS796+mJYJmTTzRFWI4aFOP9lD Wn3iyMNVAYMl0PJpQgjNIZC0wbyx6x59TsxjoeIWsq1dzOvkKHGr9KAK0feiVnUnlg6t uvyo716hfzZ/3GOC3h6bQVz/dyNhXPqyYmtOqaBn4IdZhHrQvnr1XpAin2WTFJ/EEwGU nkOsI4PpmF5HF5vaiBep3+4tz8mkscg8E+CVOo9ksTp+1J3pcjVcQyb62h3y1Z8XrVuC 8iyg== X-Gm-Message-State: AKGB3mJ87UXdOOf5HtqHlTAXCab9Mk/hEKkEnFkjW8GynXD+GPuDT7z+ o++n/jjIh18x7xrN+bmXCmPMpr2D4F7Q9B2fnRg0Tg== X-Google-Smtp-Source: ACJfBotWFMyojQ3m763ilrZzssXiMPjcPeWKscJTFLfIfJfNBt3KvMzsOa8b2hfzH2IQk7y6Y9b42+8gVqHTFMwOLk0= X-Received: by 10.80.186.161 with SMTP id x30mr28801844ede.138.1515640224528; Wed, 10 Jan 2018 19:10:24 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.80.195.88 with HTTP; Wed, 10 Jan 2018 19:10:23 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <20180111004929.GA17499@bloaty> References: <20180111004929.GA17499@bloaty> From: Warner Losh Date: Wed, 10 Jan 2018 20:10:23 -0700 X-Google-Sender-Auth: BK2XegaVx-1y--bTcunHOgG5WLI Message-ID: Subject: Re: Switch to hard-float by default? To: Alex Zepeda Cc: "freebsd-mips@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 03:10:27 -0000 On Wed, Jan 10, 2018 at 5:49 PM, Alex Zepeda wrote: > > On Wed, Jan 10, 2018 at 12:54 PM, John Baldwin wrote: > > > > > I have been working on LLVM libunwind patches for MIPS and the last > round > > > has > > > been to teach the unwinder to handle hard-float. As part of this I > just > > > fixed > > > a bug which had broken HF support for N32 (in review now), and I have a > > > working 'mipsn32hf' world that boots under qemu. However, if I add > > > 'mipsn32hf' to the list of known targets that is yet another world to > add > > > to make universe. I wonder if instead we should consider switching > MIPS to > > > assume hard-float by default? We made that change for 32-bit arm > recently. > > > > > > The simplest approach would be to add 'mipsn32hf' and then remove all > the > > > non '*hf' targets from Makefile.inc1 (if we only wanted to support > HF). A > > > more drastic approach would be to change the existing 'mips*' targets > to > > > assume hard-float, remove all the '*hf' targets (which are only in 12 > > > anyway > > > I think?) and add in explicit '*sf' targets if anyone has a need for > them. > > > Given that none of the *hf targets have been MFC'd are only present in > 12 > > > anyway, maybe the more drastic route is actually better? If we do go > that > > > route, does anyone have a use case for a '*sf' target? That is, is > anyone > > > running FreeBSD/mips on a processor that does not include an FPA? > > > > > > > I think that I retired the last set of SoCs that only had soft float. > > > > I think this is a good idea. > > > > The only use case I can think of is if I'm wrong and some of the early > > Atheros SoCs can do soft float. But then we'd just have one supported > > soft-float platform to worry about rather than the full generality we > have > > now. > > > > Warner > > Are you sure? I'm pretty sure a lot of the 32 bit SoCs don't have FPUs > standard. I'm currently poking at a MediaTek 7621 board (EdgeRouter X) > and it doesn't have an FPU. Looking through the MediaTek documents it > looks > like FPUs are an optional accessory on many of their SoCs. > You may be right about that... I think there's a good case to be made for going the sf route here for those that need it. I can think of other alternatives, but this is the least bad one. Warner From owner-freebsd-mips@freebsd.org Thu Jan 11 23:26:50 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96BEEEA6987 for ; Thu, 11 Jan 2018 23:26:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72CBC6AF91 for ; Thu, 11 Jan 2018 23:26:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (astound-66-234-199-215.ca.astound.net [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id CFDB710A8BA; Thu, 11 Jan 2018 18:26:48 -0500 (EST) From: John Baldwin To: freebsd-mips@freebsd.org Cc: Warner Losh , Alex Zepeda Subject: Re: Switch to hard-float by default? Date: Thu, 11 Jan 2018 15:26:23 -0800 Message-ID: <18788446.orHcog1a1k@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: References: <20180111004929.GA17499@bloaty> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Thu, 11 Jan 2018 18:26:48 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 23:26:50 -0000 On Wednesday, January 10, 2018 08:10:23 PM Warner Losh wrote: > On Wed, Jan 10, 2018 at 5:49 PM, Alex Zepeda > wrote: > > > > On Wed, Jan 10, 2018 at 12:54 PM, John Baldwin wrote: > > > > > > > I have been working on LLVM libunwind patches for MIPS and the last > > round > > > > has > > > > been to teach the unwinder to handle hard-float. As part of this I > > just > > > > fixed > > > > a bug which had broken HF support for N32 (in review now), and I have a > > > > working 'mipsn32hf' world that boots under qemu. However, if I add > > > > 'mipsn32hf' to the list of known targets that is yet another world to > > add > > > > to make universe. I wonder if instead we should consider switching > > MIPS to > > > > assume hard-float by default? We made that change for 32-bit arm > > recently. > > > > > > > > The simplest approach would be to add 'mipsn32hf' and then remove all > > the > > > > non '*hf' targets from Makefile.inc1 (if we only wanted to support > > HF). A > > > > more drastic approach would be to change the existing 'mips*' targets > > to > > > > assume hard-float, remove all the '*hf' targets (which are only in 12 > > > > anyway > > > > I think?) and add in explicit '*sf' targets if anyone has a need for > > them. > > > > Given that none of the *hf targets have been MFC'd are only present in > > 12 > > > > anyway, maybe the more drastic route is actually better? If we do go > > that > > > > route, does anyone have a use case for a '*sf' target? That is, is > > anyone > > > > running FreeBSD/mips on a processor that does not include an FPA? > > > > > > > > > > I think that I retired the last set of SoCs that only had soft float. > > > > > > I think this is a good idea. > > > > > > The only use case I can think of is if I'm wrong and some of the early > > > Atheros SoCs can do soft float. But then we'd just have one supported > > > soft-float platform to worry about rather than the full generality we > > have > > > now. > > > > > > Warner > > > > Are you sure? I'm pretty sure a lot of the 32 bit SoCs don't have FPUs > > standard. I'm currently poking at a MediaTek 7621 board (EdgeRouter X) > > and it doesn't have an FPU. Looking through the MediaTek documents it > > looks > > like FPUs are an optional accessory on many of their SoCs. > > > > You may be right about that... > > I think there's a good case to be made for going the sf route here for > those that need it. I can think of other alternatives, but this is the > least bad one. If it is only 32-bit CPUs that need soft-float as an option then we could perhaps have mips64 and mipsn32 assume hard-float with 'mipshf' for 32-bit hard-float and leave 'mips' as-is. It would perhaps be less confusing in the long run (and consistent with other FreeBSD platforms) to go the *sf route though and have 'mipssf'. If we don't need mipsn32sf and mips64sf then supporting both hard and soft for 32-bit mips is not quite as onerous in terms of exploding the worlds built for 'make tinderbox', etc. If there are boards people are still using that don't support hard-float we should keep soft-float around though. I think it's mostly a matter of figuring out which combinations of ABI x big/little x hard/soft that are worth supporting. -- John Baldwin From owner-freebsd-mips@freebsd.org Fri Jan 12 23:19:57 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 916FCEA7C53 for ; Fri, 12 Jan 2018 23:19:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2485A25CA; Fri, 12 Jan 2018 23:19:57 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id s13so6604445wra.10; Fri, 12 Jan 2018 15:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W2WQWG4Q7/Gg4kSvSosHx1WmD+MEhMT3N6cdbQJMaZ8=; b=SjjJdpLJw+nqJ1vXIGtncFi+jtVGTsGNa6utqU7betXXIIxZrJBQTBHjGPEOBGxwwJ RmbTKlA2g6bx6IxnaEOzlHyGkjCN8jKhdqq/bgOTOtj4SqpF4MYG5stR0MFNGoOu4waa qLKwVCgE/SqQRFPY1R4JuS9wC+swncRsKnl9+JXuodeVjstOASLWv98UxFKHaO38IoLu yYDMiQ0Sx1+aTOamDBhYZkse3ykR192euakoYJ8jPvqJykPNKpeKGL8VS79FKDLtCb05 0ZD8zqqu1SKAQyRKXIGvdwQRYdhUcbrXNFzawUhdqmUGcXy7WVbgs/H0x8t9C1RtGPZo 75KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W2WQWG4Q7/Gg4kSvSosHx1WmD+MEhMT3N6cdbQJMaZ8=; b=lWUrVpps0jMigKe/brH08EDpemXmLb3yxWuz/PVEBRzqOi0TKmwyc7ubTJvPIjF3se YBDt8QyO2WWzxIFb4nxcuqRiyHEciK02OL9KSyPeX950Lf4CBSm4+Xz/5xRMCu8q7GsH xe6H5ncAJyfF/t96d9ZlQqjU1RgAaZFxbYlBW2hvcAoE/T4FG+r0gJT9v+7Rz8l0G5sn BUfoDFNIAAWixSclFV88vTUZqY1Lx+7pVrUwpug1Pr46vCpcLa6f6K3cNJeoZ2VVewVB zjlFAaMh2p7UG/Pob0NvMI7kHSNux4YLdHjN9bqeN7EAn07eIjaLXXG8fH0mfVt/NsCa 5Rpw== X-Gm-Message-State: AKwxytcLoYIKtoDJ673DacUb7i9pla5Aal2LdscQgRUAzLAt5UnaWpfH aTp2V9d6uQEbTPL8YNYvaaGn9GTYJ1CEEJvn5Dpqgg== X-Google-Smtp-Source: ACJfBovQOj7EOUQFw0ccHPOkmsa14h+1kpWJk96dwclJK8D8RD8syX+QPlAdwq2OjeUnBzNVuum9FXV1UWkvkOckpVs= X-Received: by 10.223.172.14 with SMTP id v14mr11105965wrc.249.1515799194873; Fri, 12 Jan 2018 15:19:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.213.11 with HTTP; Fri, 12 Jan 2018 15:19:53 -0800 (PST) In-Reply-To: <18788446.orHcog1a1k@ralph.baldwin.cx> References: <20180111004929.GA17499@bloaty> <18788446.orHcog1a1k@ralph.baldwin.cx> From: Adrian Chadd Date: Fri, 12 Jan 2018 15:19:53 -0800 Message-ID: Subject: Re: Switch to hard-float by default? To: John Baldwin Cc: "freebsd-mips@freebsd.org. Robert Pera" , Alex Zepeda Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jan 2018 23:19:57 -0000 hi, On 11 January 2018 at 15:26, John Baldwin wrote: > > If it is only 32-bit CPUs that need soft-float as an option then we could > perhaps have mips64 and mipsn32 assume hard-float with 'mipshf' for 32-bit > hard-float and leave 'mips' as-is. It would perhaps be less confusing in > the long run (and consistent with other FreeBSD platforms) to go the *sf > route though and have 'mipssf'. If we don't need mipsn32sf and mips64sf > then supporting both hard and soft for 32-bit mips is not quite as onerous > in terms of exploding the worlds built for 'make tinderbox', etc. If there > are boards people are still using that don't support hard-float we should > keep soft-float around though. I think it's mostly a matter of figuring > out which combinations of ABI x big/little x hard/soft that are worth > supporting. hi, Yeah - almost all of the 32 bit router platforms aren't including the FPU in the RTL generation. Hm, is the ci20 32 bit or 64 bit? I know it has an FPU.. -adrian