MorphZone

Timer IRQs

Jolo

# 1

Just looking around

Posts: 12 from 2006/10/7

While I was trying to port m68k code (a software interrupt) I got the
response of a tester that the code in question was not executed,
although a noticeable slow down on the part of the OS could be
noticed. Before I grope in the dark and confront him with different
approaches, I decided first to exclude my private speculation.

I post here the relevant code snippet and the question.

Code:


static const struct EmulLibEntry irqgate =
{
	TRAP_LIB, 0, (void (*)()) code_entry_morphos
};

INTERRUPT long code_entry_morphos( void)
{
	struct mydata *md = (APTR) REG_A1;
#else
ASM SAVEDS INTERRUPT long code_entry(
			 REG(a1, struct mydata *md) )
{
#endif
	struct timerequest *tr;

	if ( (tr = (struct timerequest *)
		 RemHead( &md->irqport->mp_MsgList)) )
	{
		tr->tr_node.io_Command = TR_ADDREQUEST;
		tr->tr_time.tv_micro = md->timeout;
		BeginIO( &tr->tr_node);
		...normal work is done here...
	}

#if defined(__MORPHOS__)
	REG_SR |= 4;			/* Set virual Z flag */
#endif

	return 0;
}

A part of the initialisation looks like this,

Code:


#if defined(__MORPHOS__)
	md->timer_irq->is_Code = (void (*)()) &irqgate;
#else
	md->timer_irq->is_Code = (void (*)()) code_entry;
#endif
	md->irqport->mp_Flags = PA_SOFTINT;

Now my questions, what to put in mp_Sigtask?

Code:


a) md->irqport->mp_SigTask = (struct Task *) md->timer_irq;

as used for m68k, or

Code:


b) md->irqport->mp_SigTask = (struct Task *) &irqgate;

The interrupt is started as followed,
Code:


	/* Start one time, rest managed by interrupt code */
	md->request->tr_node.io_Command = TR_ADDREQUEST;
	md->request->tr_time.tv_micro = md->timeout;
	BeginIO( &md->request->tr_node);

Can someone enlighten me?

Thanks in advance.

»13.01.11 - 19:52

jacadcaps

# 2
MorphOS Developer

Posts: 3108 from 2003/3/5

From: Canada

As far as I remember, MorphOS does not really support PA_SOFTINT.
»13.01.11 - 20:34

Piru

# 3
MorphOS Developer

Posts: 587 from 2003/2/24

From: finland, the l...
Quote:
Now my questions, what to put in mp_Sigtask?

Code:
```
a) md->irqport->mp_SigTask = (struct Task *) md->timer_irq;
```
as used for m68k, or
Code:
```
b) md->irqport->mp_SigTask = (struct Task *) &irqgate;
```
a

PA_SOFTINT is implemented but softint themselves don't work exactly the same as in 68k. Namely there's no real interrupt involved but rather the is_Code is executed directly in Forbid(). This can lead to somewhat different behavior. Note that you should not perform lengthy and/or complex operations in the softint, and certainly not anything that might result in Wait().

[ Edited by Piru on 2011/1/14 0:17 ]
»13.01.11 - 21:13

Jolo

# 4
Just looking around

Posts: 12 from 2006/10/7

First, thank you jacadcaps and Piru.

With the information provided I can exclude my private speculation! :)
On the other hand it means that somewhere my code is broken, at least
for MorphOS, while it runs fine on classic machines.

Quote:

Note that you should not perform lengthy and/or complex operations in
the softint, and certainly not anything that might result in Wait()

I am aware of (almost) all the pitfalls and limitation that come
along with interrupt code which is (usually) executed in supervisor
mode (m68k). In the past I used one of the four CIA timers to enact
interrupts whenever needed and outsourced medium length code in a
software interrupt code enforced with Cause() within the hardware
interrupt code.
Now I am fiddling around with dynamically adjustable interrupt
periods and I thought that by the timer device caused request would
be a good solution, because the 'time-out' can be applied on the fly
(tr->tr_time.tv_micro = md->timeout).

Because I know now that there is no genuine interrupt caused by the
timer device based SOFTINT, what possibilities do we have in order to
cause such interrupt requests? That's because I really need constant
periods and I would speculate that task based code executed is more
often interrupted than a genuine low-level interrupt code (?).

Thanks in advance.
»14.01.11 - 09:52

itix

# 5
MorphOS Developer

Posts: 1520 from 2003/2/24

From: Finland

In MorphOS you are not allowed to have true low level interrupts.

Regarding your interrupt code, didnt MorphOS have specific TRAP_LIB#? for interrupts? IIRC TRAP_LIB ignores REG_SR. I would check but I am 16000 kilometers away from home....
1 + 1 = 3 with very large values of 1
»14.01.11 - 10:17

Krashan

# 6
MorphOS Developer

Posts: 1107 from 2003/6/11

From: Białystok...

Because I know now that there is no genuine interrupt caused by the
timer device based SOFTINT, what possibilities do we have in order to
cause such interrupt requests? That's because I really need constant
periods and I would speculate that task based code executed is more
often interrupted than a genuine low-level interrupt code (?).

For regular periods you can use WAITCPUCLOCK unit of the timer.device. Then you will ensure your requests will return in regular periods of time and latency between receiving the returned request and sending a new one is irrelevant. Of course it does not protect you against a case where your process is scheduled out by exec...
RastPort
»14.01.11 - 11:13

Jolo

# 7
Just looking around

Posts: 12 from 2006/10/7

Quote:

itix:
In MorphOS you are not allowed to have true low level interrupts.

Ouch, I didn't know that!

Quote:

Regarding your interrupt code, didnt MorphOS have specific TRAP_LIB#? for interrupts? IIRC TRAP_LIB ignores REG_SR.

I've changed it from TRAP_LIBNR to TRAP_LIB and I cleared the virtual Z-flag just in case. The m68k (classic hardware) tailored code didn't return a value and didn't clear the Z-flag; this was only added for MorphOS, due to the missing knowledge on my part.

Quote:

Krashan:
For regular periods you can use WAITCPUCLOCK unit of the timer.device. Then you will ensure your requests will return in regular periods of time and latency between receiving the returned request and sending a new one is irrelevant. Of course it does not protect you against a case where your process is scheduled out by exec...

Yep, this seem to be the better approach for MorphOS, unfortunately, therewith I break the portability, because currently the caused interrupt code is just the callback routine that gets called from the interrupt server. If I would use a task based WAITCPUCLOCK, I would have to re-design the entire 'server', because it is not a stand-alone program but designed as a shared library, what would mean in this case that I need to add a task for any user of this library.

I guess I keep trying to get the timer device approach working.

Nonetheless, many thanks to clarify things for me.
»14.01.11 - 18:15

Krashan

# 8
MorphOS Developer

Posts: 1107 from 2003/6/11

From: Białystok...

Yep, this seem to be the better approach for MorphOS, unfortunately, therewith I break the portability, because currently the caused interrupt code is just the callback routine that gets called from the interrupt server.

Use WAITECLOCK unit for portability. It works with all systems (not sure about AROS).
RastPort
»16.01.11 - 08:05

Jolo

# 9
Just looking around

Posts: 12 from 2006/10/7

Quote:

Krashan:
Use WAITECLOCK unit for portability. It works with all systems (not sure about AROS).

Okay, I've now modified it once again after I've gotten the report that the last version crashed the entire system.
Well, it didn't used WAITECLOCK in that particular version, perhaps the problem is solved by using it. Don't know yet.
What I can tell: By using WAITECLOCK the test file runs fine (under OS3), under AROS it will crash. The symptoms are the same as stated in the report for MorphOS (using MICROHZ). The output starts, then it doesn't continue, and when pressing CTRL-C the machine says good bye...

I've now uploaded the test files so that anyone interested in this source code and also willing to help me out can have a look at it,

http://amimedic.de/private/Cause.lha

I am risking the friendship if I send him again a file that bombs his system. ;)
So, any help is welcome.
»16.01.11 - 15:45