How to reliably detect USER or SUPERVISOR mode across CPUs

[martyn_hill]

Hi everyone

I am trying to design a routine that when called might be in ether of USER or SUPERVISOR privilege modes and, at some point will need to protect a heap memory allocation by temporarily switching to SUPERVISOR mode if not already there.

Before returning, the routine should be back in the privilege mode it was called-in.

Reading the 68k Programmers manual, I note that on a 68000/68008, I could safely use the MOVE SR, <ea> instruction (and then test the appropriate U/S bit in the destination) regardless of the current privilege mode, but that on the 68010 etc, this instruction is itself privileged and would cause an exception if executed in USER mode.

Ideally, I'd like the resultant code to be agnostic to processor generation (real or emulated)...

Has anyone already thought a neat and reliable approach to this?

Happy Easter Monday

[pjw]

Does section 10:12 in the Qdos/SMSQ Reference manual do anything for you?

[martyn_hill]

Darn it - I thought I had researched thoroughly

Thanks Per.

So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'

Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?

[janbredenbeek]

Darn it - I thought I had researched thoroughly
So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'
Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?

Yes.
Another way, which doesn't require a test of the S flag, would be to define your own TRAP (#5 to #15) for it and activate your own exception table. This ensures that your code executes in supervisor mode. Of course it should end with a RTE which will restore the SR on return.

Jan.

[pjw]

So, what does it mean I wonder when the Guide states 'Therefore, all reads of the status register are emulated.'

Im not very well acquainted with this area of the OS as I have had little need for it. You may find the answer to this by looking at dev8_smsq_smsq_privv_asm, which deals with "privilege violation recovery".

Does this mean that MOVE SR, <ea> can be used and, if it does cause an exception due to running on a later processor, that SMSQE will handle the exception in software and effectively action the instruction before returning from the exception handler?

If in doubt try it out!

[pjw]

Another way, which doesn't require a test of the S flag, would be to define your own TRAP (#5 to #15) for it and activate your own exception table. This ensures that your code executes in supervisor mode. Of course it should end with a RTE which will restore the SR on return.

Defining your own traps is fine for jobs, but would that be a good idea for a global device driver?

[martyn_hill]

Thanks Jan and Per - I have enough now to make the next step

[janbredenbeek]

Defining your own traps is fine for jobs, but would that be a good idea for a global device driver?

Probably not, but that wasn't mentioned in the original post.
Speaking of which, I recently discovered such a thing in the SD card driver for the Q68 supplied with Minerva. It was a TRAP #14 in the read sector code, probably a leftover from debugging as it does nothing if you haven't activated your own trap vectors. But it was quite embarassing to see the monitor screen popping up when doing a DIR!

Jan.

[Dave]

How might detecting this tie in with detecting and enabling caches on the 68000, 68020, 68030 and 68060?

[Nasta]

How might detecting this tie in with detecting and enabling caches on the 68000, 68020, 68030 and 68060?

Enabling cache on a 68000 is REALLY hard.