From owner-freebsd-arm@freebsd.org Sat Sep 9 20:10:54 2017 Return-Path: Delivered-To: freebsd-arm@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 300ADE072F4; Sat, 9 Sep 2017 20:10:54 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::241]) (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 F051877688; Sat, 9 Sep 2017 20:10:53 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x241.google.com with SMTP id f84so3102678pfj.3; Sat, 09 Sep 2017 13:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=rrb3oyTOx+EhSQqV0092UgjHyYHAWg7/IOAGpJ35YJA=; b=kJuFb0/alBgBIH0x7a3n2iN6zUA94e1mNOUIpyUEp4DGZBE8OuLRMlauWFZQkbvQTl +2aHeuTFoc1Q+AcFzHeIsYN4RlR9WTlpJnmwHqym385efv+rN6NnjenDEMLVafOfT5yd 0Ulp7pK9gVTd6Xf9mBEBupvhHZHO5dvtJqxPlyCcXv4tQMI7mvcKRofGPnsz6bY86nUH cKWMaDQwzs1Twt8Cq12RTf5Tj2y2l0HDmNz9k5ep+V++K9i/MwdAWxmaPRJRGaAx54OH fuMi+7s7aYO98o4SJ3ztjHT56tzS4JXWscnb7NF3EWEkXm5geCXexGTxPM/nhy1nPqLK VZ+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=rrb3oyTOx+EhSQqV0092UgjHyYHAWg7/IOAGpJ35YJA=; b=MYY3koLeAKSgfdMl8Gh84SWeiRyi/0QLhDBhMtJBafnuHG22URplpzbKRCcq24HBfa v2gJ9GsxRE47Njx1nyHqvDRVUEIsI2nRkO88rgz+JXs8cQ0UjaNwZvsTgyqWrTZtyB5d mdnDIAzasXc22qqtgA/41IragqSePkI6NqlqAlxKcygJmumHLBDoDGY/Ee8uYPMBLjtY jFDtXT/CpdsX9KLjE+OgkFMV/neVY9NB3o3dnNpITIU2HDtB2KIJssa1W8/34mcwhSGA l0jliauJFz91qYUYl2soEuy4o7fTYkJGrDkMH7wXwZx3OK+OzJgX/l7KV6QBI/UnHAuG BcPg== X-Gm-Message-State: AHPjjUi+FTdduOqQRnnlImGMHf2afqT/lETQw23kctiCcJGn0bkdxnmP Qa9LDw4OlWqI9gPgqoIeBA== X-Google-Smtp-Source: ADKCNb5HiTdrMqzmCwvKIX62fsVmjxwPg3+cgp82MJlO+Mcuq3VYr1K7ZB3qdAvWRExQZ+GoUUXzDg== X-Received: by 10.84.210.45 with SMTP id z42mr7951078plh.132.1504987853521; Sat, 09 Sep 2017 13:10:53 -0700 (PDT) Received: from [127.0.0.1] ([204.174.94.196]) by smtp.gmail.com with ESMTPSA id q12sm8096058pgs.47.2017.09.09.13.10.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 09 Sep 2017 13:10:52 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20170909201051.6545490.68027.31617@gmail.com> Date: Sat, 09 Sep 2017 13:10:51 -0700 Subject: Re: FCP-100: armv7 plan From: Russell Haley In-Reply-To: References: To: Warner Losh , Jan Beich Cc: freebsd-arm@freebsd.org, "freebsd-toolchain@FreeBSD.org" , Jan Beich X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Sep 2017 20:10:54 -0000 Warner,=A0 So you are saying NEON support is a compile time option that has no relevan= ce to the Application Binary Interface, which is what the FCP-0100 was abou= t? Thanks for clarification, Russ Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Virgin=A0Mobil= e=A0network. =A0 Original Message =A0 From: Warner Losh Sent: Saturday, September 9, 2017 12:37 PM To: Jan Beich Cc: freebsd-arm@freebsd.org; freebsd-toolchain@FreeBSD.org; Jan Beich Subject: Re: FCP-100: armv7 plan On Sat, Sep 9, 2017 at 1:25 PM, Jan Beich wrote: > Warner Losh writes: > > > On Sat, Sep 9, 2017 at 1:05 PM, Jan Beich wrote: > > > >> Warner Losh writes: > >> > >> > Greetings, > >> > > >> > This will serve as 'Last Call' for any objections to the plan to > create > >> an > >> > armv7 MACHINE_ARCH in FreeBSD, as documented in FCP-0100. > >> [...] > >> > >> Some ports want NEON support but FCP-0100 is vague about > FreeBSD-specific > >> differences between armv6 and armv7. Clang appears to enable NEON for > all > >> *-gnueabi* targets but I have no clue about GCC. Apparently, Android a= nd > >> Debian don't assume NEON on armv7. > >> > >> related: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221898 > >> > > > > Yes. We are vague about it on purpose. Just like we're vague about MMX, > > MMX2, etc on x86 because different processors can/want use different > > things. > > Do you mean similar to how FreeBSD i386 is vague about not supporting > real i386, only i486 or later? I mean we don't enumerate the list of all the processor supported things. We default to compiling for a fairly middle of the road processor, but you can strip that back all the way to i486, or hyper optimize for the latest core-2 duo. However, armv6 vs armv7 can affect the ABI in subtle ways that's it's best to avoid by declaring the two different. One may be able to run armv6 binaries on an armv7 CPUs still, but we're not specifically guaranteeing it. > The goal, if it doesn't work already, is for NEON to work if used, > > but not be required, just like all the other optional features of a CPU. > > FreeBSD doesn't support detecting NEON at runtime unlike Linux. No, I don't mean that at all. I mean we don't care if it is enabled or not. It doesn't affect the ABI. The kernel knows about the extensions and saves the context when it's in use, just like the x86 kernel saves MMX, etc context when it's in use. Do you > mean at compile time? If so then the following probably needs to change > > $ cc -target armv7-unknown-freebsd12.0-gnueabihf -dM -E - fgrep -i neon > #define __ARM_NEON 1 > #define __ARM_NEON_FP 0x4 > #define __ARM_NEON__ 1 > Right. that's based on the default target. gcc/clang can enable or disable it (and a dozen other things) depending on what options you give. We don't care. We'll run all binaries. It's up to the system integrator to mix/match the options so they get optimal performance for their platform. Just like on x86. If you compile for MMX and run it on 486 w/o run-time detection, you'll get a reserved instruction fault. Same philosophy here. We don't dictate policy for the binaries, just like on x86. However, most of them have run-time detection to be nicer to the users than a core dump, and most do the best thing for that CPU if they really care about performance, but those applications that don't can just do whatever and be fine. Warner _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"