Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 23 Apr 2020 22:37:28 -0400
From: Rich Felker <>
To: Tom Storey <>
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.


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.