How to reliably detect USER or SUPERVISOR mode across CPUs

Anything QL Software or Programming Related.
martyn_hill
Super Gold Card
Posts: 516
Joined: Sat Oct 25, 2014 9:53 am

How to reliably detect USER or SUPERVISOR mode across CPUs

Postby martyn_hill » Mon Apr 22, 2019 11:17 am

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
Super Gold Card
Posts: 530
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

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

Postby pjw » Mon Apr 22, 2019 6:55 pm

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


Per
Be wary of large West-Coast corporations bearing gifts!
- Ancient Trojan proverb
martyn_hill
Super Gold Card
Posts: 516
Joined: Sat Oct 25, 2014 9:53 am

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

Postby martyn_hill » Mon Apr 22, 2019 7:19 pm

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
Gold Card
Posts: 332
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

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

Postby janbredenbeek » Mon Apr 22, 2019 11:44 pm

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
Super Gold Card
Posts: 530
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

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

Postby pjw » Mon Apr 22, 2019 11:46 pm

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
Be wary of large West-Coast corporations bearing gifts!
- Ancient Trojan proverb
User avatar
pjw
Super Gold Card
Posts: 530
Joined: Fri Jul 11, 2014 8:44 am
Location: Norway
Contact:

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

Postby pjw » Mon Apr 22, 2019 11:56 pm

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
Be wary of large West-Coast corporations bearing gifts!
- Ancient Trojan proverb
martyn_hill
Super Gold Card
Posts: 516
Joined: Sat Oct 25, 2014 9:53 am

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

Postby martyn_hill » Tue Apr 23, 2019 12:11 am

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


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

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

Postby janbredenbeek » Tue Apr 23, 2019 11:45 am

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: 2412
Joined: Sat Jan 22, 2011 6:52 am
Location: Austin, TX
Contact:

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

Postby Dave » Tue Apr 23, 2019 5:50 pm

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


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

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

Postby Nasta » Sat Apr 27, 2019 11:19 am

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.



Who is online

Users browsing this forum: No registered users and 3 guests