From owner-freebsd-arch@freebsd.org Mon Nov 16 19:14:45 2015 Return-Path: Delivered-To: freebsd-arch@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 AE06CA30DA5; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: from mail-yk0-x242.google.com (mail-yk0-x242.google.com [IPv6:2607:f8b0:4002:c07::242]) (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 692A11973; Mon, 16 Nov 2015 19:14:45 +0000 (UTC) (envelope-from superbisquit@gmail.com) Received: by ykba77 with SMTP id a77so25406440ykb.2; Mon, 16 Nov 2015 11:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1UwCbrVJfGphtXYocT1kovcrc89WcjfgXHWyTK3+64s=; b=Il5HZXXLgm35vQ67uzLOqnxTaBO2WQxxh6kVKfC9M99RyUkvT8HhBocnCJb8KZzp9b LTJNtKldE7YXbR2pCx5/QV3xrqLVZTUDw47CoBsZzNN1j2guUFMp2tdz2fe306BA9slZ GKTUQVbZHZj4Tn2gwxw9w9d7uNnDe5pc8S9Q3lBp3pDWjwnYAS42UQV8L4DB5SVGOHSG sj8+nMzUqYSpLjgKNQo0vXT/SrQlA8LRckSc77eNTJfikYxSqMJL8jdtyMu9tHoVz2bE d2sFNZMTLNV1nMcqVoqD7pLXSj7inTEzsYzxGBHB5IFOAQhf+gQvU2XH5uhX+fWw6nuX V7CQ== MIME-Version: 1.0 X-Received: by 10.129.135.7 with SMTP id x7mr36501575ywf.95.1447701284682; Mon, 16 Nov 2015 11:14:44 -0800 (PST) Received: by 10.103.9.195 with HTTP; Mon, 16 Nov 2015 11:14:44 -0800 (PST) In-Reply-To: <56492EB4.1080307@freebsd.org> References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <56492EB4.1080307@freebsd.org> Date: Mon, 16 Nov 2015 14:14:44 -0500 Message-ID: Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 From: Joe Nosay To: Nathan Whitehorn Cc: Justin Hibbits , Marius Strobl , Sean Bruno , sparc64@freebsd.org, freebsd-arch Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 19:14:45 -0000 Will there be a project using Z-RAM and other technologies as such? SPARC64 processors should be capable of holding a database for fourth, fifth, and sixth dimensional graphs based on time. (Fourth is the single point in time, fifth is the path of least resistance, sixth would be variations known as experiential. NASA already released a virtual program "4S" for this. Performance of RISC over CISC has always been for the former. SPARC64 is practical in audio applications which call for access to such a database. Each architecture has a specific purpose. Think about it. ARM32/64 non-mmu temporary memory, sampling, data input. POWER32/64- cache for instructions and not trash, AI, repetitive instructions, graphics, audio. SPARC32/64 - scalability, complex databases AMD64/i386 complex compression, algorithms. Performance on each differs with kernel hertz, OS choice, etc. You use them together such as parts of a biological brain. Seeing that memory is now becoming three dimensional in form, we probably should be looking towards working these together. NFS and 9p - if still around - would create two types of accessible bootstrapping methods - applications/binaries and data. On Sun, Nov 15, 2015 at 8:17 PM, Nathan Whitehorn wrote: > > > On 11/08/15 12:46, Justin Hibbits wrote: > >> On 11/8/15, Marius Strobl wrote: >> >> >>> As for getting forward, the FreeBSD Software License Policy >>> (https://www.freebsd.org/internal/software-license.html) >>> specifically allows for existing GPLv2 licensed software in >>> the FreeBSD source tree to be updated to GPLv3 licensed one. >>> The initial, longer draft of this policy posted by brooks@ to >>> developers@ even explicitly mentioned key technologies such >>> as toolchains of other licenses being allowed when no mature >>> BSD-licensed alternative exists. So I propose just that: >>> Let's upgrade binutils and GCC in base to recent versions. >>> Seriously. That way we 1) don't need to get external toolchain >>> support into shape, 2) don't need to solve the chicken-and-egg >>> problem of getting a toolchain onto a machine installed from >>> a distribution built with an external toolchain and 3) once >>> clang becomes mature on additional architectures, we have an >>> upgrade path. Don't get me wrong, I'm only proposing that >>> for !arm and !x86. >>> As a side note: A while back I talked to grehan@ and marcel@ >>> regarding the immaturities of clang and - as expected -, a >>> GPL'ed toolchain just is no problem for either NetApp or >>> Juniper as the binaries they ship don't include the toolchain >>> itself. With the possible exception of the current incarnation >>> of SCO which apparently sells a FreeBSD-based OS likely having >>> a system compiler, for the same reason I can't think of why a >>> GPLv3 licensed toolchain would matter for any of the commercial >>> downstream consumers of FreeBSD. Thus, I really can't understand >>> all that aggression regarding making FreeBSD 11 clang-only. >>> >>> >> >> I 100% agree with you on this. If we can update binutils to the >> latest and greatest, I believe powerpc64 would be able to work with >> clang. I've backported several patches, with IBM's permission, to >> binutils for handling new relocations, etc. However, not all patches >> are straight forward, and currently we're missing something, which is >> causing odd segfaults in ld(1), when linking as(1). No other binary, >> only as(1). I've tried looking through it, but the binutils code is a >> mess. I'm sure the bug that's getting hit was fixed with newer >> binutils, but have had a very hard time trying to test with it. >> >> TL;DR, let's update binutils at the very least, and gcc if it makes >> sense. We shouldn't be relying on external toolchain for some archs, >> and internal for others. It completely snubs already second class >> citizens. Just look at the various build failures we've had because >> to some people All The World is clang/x86. >> >> > This would be super valuable. It would restore the upgrade path to clang > broken at 3.5, allow us to use modern ABIs, everything. Is this something > that is actually politically/legal doable? > -Nathan > _______________________________________________ > freebsd-sparc64@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-sparc64 > To unsubscribe, send any mail to "freebsd-sparc64-unsubscribe@freebsd.org" >