From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 23904 invoked from network); 20 Sep 2020 17:17:22 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2020 17:17:22 -0000 Received: (qmail 1639 invoked by uid 550); 20 Sep 2020 17:17:21 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1618 invoked from network); 20 Sep 2020 17:17:20 -0000 Date: Sun, 20 Sep 2020 13:17:08 -0400 From: 'Rich Felker' To: sidneym@codeaurora.org Cc: musl@lists.openwall.com Message-ID: <20200920171707.GC3265@brightrain.aerifal.cx> References: <20200619224624.GO6430@brightrain.aerifal.cx> <0a7201d646aa$921b84f0$b6528ed0$@codeaurora.org> <20200620032032.GR6430@brightrain.aerifal.cx> <078f01d65edc$80e892f0$82b9b8d0$@codeaurora.org> <20200723215603.GA755469@port70.net> <110801d68c6a$dfe3f950$9fabebf0$@codeaurora.org> <20200917013236.GV3265@brightrain.aerifal.cx> <073501d68d42$4a8c6080$dfa52180$@codeaurora.org> <20200918010806.GX3265@brightrain.aerifal.cx> <025a01d68f4f$bd211aa0$37634fe0$@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <025a01d68f4f$bd211aa0$37634fe0$@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Hexagon DSP support On Sun, Sep 20, 2020 at 08:12:47AM -0500, sidneym@codeaurora.org wrote: > > > > > [...] > > > > > +#define a_barrier a_barrier > > > > > +static inline void a_barrier() > > > > > +{ > > > > > + __asm__ __volatile__ ("barrier" ::: "memory"); } > > > > > > > > Is the barrier implied in memw_locked? If not, there need to be > > > > explicit barriers in all the atomic functions. > > > > > > Yes, if there is any memory access on the reserved address the > > > reservation is lost and the predicate is false. > > > > That's not what a barrier means. The question is whether it orders all > access > > to *other* memory, not the address with the reservation on it. > > In other words, musl's a_*() atomics need to be full seq_cst model > > operations, not relaxed atomics. > > Per our spec: > "Threads in the Hexagon processor follow a sequentially consistent memory > model at a packet > granularity. Threads interleave their memory operations with one another in > an arbitrary but > fair manner. This results in a consistent program order that is globally > observable by all > threads in the same order." Can you clarify or provide a reference for what 'packet granularity' means? If there's actually a full builtin seq_cst order I don't see what the barrier instruction exists for to begin with. Rich