From owner-freebsd-mips@freebsd.org Thu Dec 27 01:39:43 2018 Return-Path: Delivered-To: freebsd-mips@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 94129133D77C for ; Thu, 27 Dec 2018 01:39:43 +0000 (UTC) (envelope-from lidl@pix.net) Received: from hydra.pix.net (hydra.pix.net [IPv6:2001:470:e254:10::4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.pix.net", Issuer "Pix.Com Technologies LLC CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 12896779A3 for ; Thu, 27 Dec 2018 01:39:43 +0000 (UTC) (envelope-from lidl@pix.net) Received: from torb.pix.net ([IPv6:2001:470:e254:10:81e0:11e9:2de9:1354]) (authenticated bits=0) by hydra.pix.net (8.15.2/8.15.2) with ESMTPA id wBR1dYbm030574; Wed, 26 Dec 2018 20:39:41 -0500 (EST) (envelope-from lidl@pix.net) X-Authentication-Warning: hydra.pix.net: Host [IPv6:2001:470:e254:10:81e0:11e9:2de9:1354] claimed to be torb.pix.net To: freebsd-mips@freebsd.org References: Subject: Re: Pruning Redux From: Kurt Lidl Message-ID: <64c8f24a-ef14-8eed-5884-4adc7ea6412c@pix.net> Date: Wed, 26 Dec 2018 20:39:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-mips@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to MIPS List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Dec 2018 01:39:43 -0000 Warner Losh writes: > I've removed the SMP versions of the Ingenic JZ4280 config files. This is > the CI20 board(s), but not the ones based on X1000 which are not SMP. > Rather than removing the port as initially discussed, I took this more > limited action. [...] > I've also implemented the atomic_swap_64 in a less optimal, but more > portable, way. I hope to circulate it for testing shortly. At that time, > the old CI20 config files will really break, but I thought it best to > communicate and document this happening in advance of it really happening. > Once *that* is in the tree, I'll go remove all the hacks we have in place > because mips didn't have the proper 64-bit ops. I looked into this a little, mostly just from a curiosity standpoint. I most explicitly don't disagree with any of the actions that were taken. So in my examination of the situation, I see that in the mips32r6 instruction set (which the MZ4280 implements), there are two new instructions: LLWP - load linked word paired LLWPE - load lined word paired EVA These instructions can be used to atomically load two 32 bit quantities into two registers. There are certain caveats about the memory from which they are loaded must be synchronizable between all CPU cores and all I/O devices, but I don't think that this would be a problem for our intended use case. Similarly, the 'SC' (store conditional word) instruction, can, in a loop, be used to atomically store two 32bit quantities into memory. (See example code on page 350 of the 'The MIPS Instruction Set v6.06' pdf file.) Is there some reason these instruction could not be used to implement the missing 64bit atomic functions for mips32? Yes, it would mean that this would raise the minimum MIPS ISA for 32-bit SMP would jump to mips32r6, but that might be better than no support at all. For uniprocessor support, I think whatever the reworked code from Warner is probably the correct forward path to take. -Kurt