How to reliably detect USER or SUPERVISOR mode across CPUs

Anything QL Software or Programming Related.
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

How to reliably detect USER or SUPERVISOR mode across CPUs

Post by 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 :-)


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by pjw »

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


Per
dont be happy. worry
- ?
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by 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?


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by janbredenbeek »

martyn_hill wrote: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.


User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by pjw »

martyn_hill wrote: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! ;)


Per
dont be happy. worry
- ?
User avatar
pjw
QL Wafer Drive
Posts: 1286
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by pjw »

janbredenbeek wrote: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?


Per
dont be happy. worry
- ?
martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by martyn_hill »

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


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by janbredenbeek »

pjw wrote: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.


User avatar
Dave
SandySuperQDave
Posts: 2765
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by Dave »

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


Nasta
Gold Card
Posts: 443
Joined: Sun Feb 12, 2012 2:02 am
Location: Zapresic, Croatia

Re: How to reliably detect USER or SUPERVISOR mode across CPUs

Post by Nasta »

Dave wrote: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.


Post Reply