Date: Thu, 23 Apr 2020 22:37:28 -0400 From: Rich Felker <dalias@...c.org> To: Tom Storey <tom@...ap.net> Cc: musl@...ts.openwall.com Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.