From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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.2 Received: (qmail 26175 invoked from network); 24 Apr 2020 02:37:44 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 24 Apr 2020 02:37:44 -0000 Received: (qmail 8047 invoked by uid 550); 24 Apr 2020 02:37:41 -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 8027 invoked from network); 24 Apr 2020 02:37:40 -0000 Date: Thu, 23 Apr 2020 22:37:28 -0400 From: Rich Felker To: Tom Storey Cc: musl@lists.openwall.com Message-ID: <20200424023728.GD11469@brightrain.aerifal.cx> References: <20200423023255.GO11469@brightrain.aerifal.cx> <20200423163016.GW11469@brightrain.aerifal.cx> <20200424005101.GA11469@brightrain.aerifal.cx> <20200424012043.GB11469@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Building for m68k On Fri, Apr 24, 2020 at 12:29:51PM +1000, Tom Storey wrote: > Ah yeah. Cool. > > I did something similar in a recent Z80 based project, shouldn't be too > difficult to do that on m68k. > > Only trouble I can see arising from this is enabling and disabling > interrupts is privileged, and from the 68010 onwards you can't even see the > status register to know if interrupts are on/off outside of supervisor > mode, so you wouldn't be able to execute this code from any application > running in user mode. Yes, the cli/sti approach only works without separate privilege domains, which normally corresponds to having an MMU (without MMU privilege domains are pretty much "cooperative" anyway). > I suppose that is why it's better trapped as an invalid instruction and > emulated lower down? Trap-and-emulate is the easy/clean way to do atomic cas when you do have a separate kernel privilege domain and can't mask interrupts, but it's also very inefficient. The efficient way is by having a contract with the kernel where the kernel can detect interruption of the critical section and restart it at the beginning if a context switch interrupted it. Lookup ARM (pre-v6) kuser_helper to see how this worked. It's a really elegant design (aside from the hard-coded addresses) and not hard to implement. SH3/4 also had a similar mechanism but with a different contract where userspace was responsible for more of it, and that was incompatible with large address spaces because it assigned special meaning to "negative" stack pointer values. I wouldn't recommend copying it but it's possibly worth taking a look and comparing it to the ARM kuser_helper approach. Rich