Exec Interrupts - Revision history

Costel Mincea: Text replacement - "" to ""

2025-01-26T19:30:08Z

Text replacement - "<syntaxhighlight>" to "<syntaxhighlight lang="C" line>"

← Older revision		Revision as of 19:30, 26 January 2025
Line 61:		Line 61:
	Interrupt handlers and servers are defined by the Exec Interrupt structure. This structure specifies an interrupt routine entry point and data pointer. The C definition of this structure is as follows:		Interrupt handlers and servers are defined by the Exec Interrupt structure. This structure specifies an interrupt routine entry point and data pointer. The C definition of this structure is as follows:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	struct Interrupt		struct Interrupt
	{		{
Line 164:		Line 164:
	Interrupt handlers are established by passing the Exec function SetIntVector(), your initialized Interrupt structure, and the ''4703'' interrupt bit number of interest. The parameters for this function are as follows:		Interrupt handlers are established by passing the Exec function SetIntVector(), your initialized Interrupt structure, and the ''4703'' interrupt bit number of interest. The parameters for this function are as follows:

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	SetIntVector(ULONG intNumber, struct Interrupt *interrupt)		SetIntVector(ULONG intNumber, struct Interrupt *interrupt)
	</syntaxhighlight>		</syntaxhighlight>
Line 532:		Line 532:
	Software interrupts can also be generated by message arrival at a PA_SOFTINT message port. The applications of this technique are limited since it is not permissible, with most devices, to send IO requests from within interrupt code. However, the timer.device does allow such interactions, so a self-perpetuating PA_SOFTINT timer port can provide an application with quite consistent timing under varying multitasking loads. The following example demonstrates use of a software interrupt and a PA_SOFTINT port. See the [[Exec_Messages_and_Ports\|Exec Messages and Ports]] for more information about messages and ports.		Software interrupts can also be generated by message arrival at a PA_SOFTINT message port. The applications of this technique are limited since it is not permissible, with most devices, to send IO requests from within interrupt code. However, the timer.device does allow such interactions, so a self-perpetuating PA_SOFTINT timer port can provide an application with quite consistent timing under varying multitasking loads. The following example demonstrates use of a software interrupt and a PA_SOFTINT port. See the [[Exec_Messages_and_Ports\|Exec Messages and Ports]] for more information about messages and ports.

	<syntaxhighlight>		<syntaxhighlight lang="C" line>
	/* timersoftint.c - Timer device software interrupt message port example. */		/* timersoftint.c - Timer device software interrupt message port example. */

Janne Peräaho: Added code review request

2018-09-20T13:56:39Z

Added code review request

← Older revision		Revision as of 13:56, 20 September 2018
Line 1:		Line 1:
	{{NeedUpdate}}		{{NeedUpdate}}{{CodeReview}}
	== Exec Interrupts ==		== Exec Interrupts ==

Costel Mincea: /* Software Interrupts */

2017-01-19T10:28:43Z

Software Interrupts

← Older revision		Revision as of 10:28, 19 January 2017
Line 588:		Line 588:

	/* Allocate timerequest */		/* Allocate timerequest */
	struct ~~timerequest~~ *tr = IExec->AllocSysObjectTags(ASOT_IOREQUEST,		struct TimeRequest *tr = IExec->AllocSysObjectTags(ASOT_IOREQUEST,
	ASOIOR_Size, sizeof(struct TimeRequest),		ASOIOR_Size, sizeof(struct TimeRequest),
	ASOIOR_ReplyPort, port,		ASOIOR_ReplyPort, port,
Line 640:		Line 640:
	{		{
	/* Remove the message from the port. */		/* Remove the message from the port. */
	struct TimeRequest tr = (struct ~~timerequest~~ )IExec->GetMsg(tsidata->tsi_Port);		struct TimeRequest tr = (struct TimeRequest )IExec->GetMsg(tsidata->tsi_Port);

	/* Keep on going if main() hasn't set flag to OFF. */		/* Keep on going if main() hasn't set flag to OFF. */

Steven Solie: /* Interrupts */

2015-11-03T23:09:37Z

Interrupts

← Older revision		Revision as of 23:09, 3 November 2015
Line 4:		Line 4:
	== Interrupts ==		== Interrupts ==

	Exec manages the decoding, dispatching, and sharing of all system interrupts. This includes control of hardware interrupts, software interrupts, task-relative interrupts (see the discussion of exceptions in ~~the "~~Exec Tasks~~" chapter~~), and interrupt disabling and enabling. In addition, Exec supports a more extended prioritization of interrupts than that provided in the CPU.		Exec manages the decoding, dispatching, and sharing of all system interrupts. This includes control of hardware interrupts, software interrupts, task-relative interrupts (see the discussion of exceptions in [[Exec_Tasks\|Exec Tasks]]), and interrupt disabling and enabling. In addition, Exec supports a more extended prioritization of interrupts than that provided in the CPU.

	The proper operation of multitasking depends heavily on the consistent management of the interrupt system. Task activities are often driven by inter-system communication that is originated by various interrupts.		The proper operation of multitasking depends heavily on the consistent management of the interrupt system. Task activities are often driven by inter-system communication that is originated by various interrupts.
Line 168:		Line 168:
	</syntaxhighlight>		</syntaxhighlight>

	The first argument is the bit number for which this interrupt server is to respond (example INTB_VERTB). The possible bits for interrupts are defined in <hardware/intbits.h>. The second argument is the address of an interrupt server node as described earlier in this ~~chapter~~. Keep in mind that certain interrupts are established as server chains and should not be accessed as handlers.		The first argument is the bit number for which this interrupt server is to respond (example INTB_VERTB). The possible bits for interrupts are defined in <hardware/intbits.h>. The second argument is the address of an interrupt server node as described earlier in this article. Keep in mind that certain interrupts are established as server chains and should not be accessed as handlers.

	The following example demonstrates initialization and installation of an assembler interrupt handler. See the [[Resources\|Resources]] for more information on allocating resources, and [[Serial_Device\|Serial Device]] for the more common method of serial communications.		The following example demonstrates initialization and installation of an assembler interrupt handler. See the [[Resources\|Resources]] for more information on allocating resources, and [[Serial_Device\|Serial Device]] for the more common method of serial communications.

Steven Solie: /* Sequence of Events During an Interrupt */

2013-05-08T19:27:41Z

Sequence of Events During an Interrupt

← Older revision		Revision as of 19:27, 8 May 2013
Line 37:		Line 37:
	Task multiplexing usually occurs as the result of an interrupt. When an interrupt has finished and the processor is about to return to user mode, Exec determines whether task-scheduling attention is required. If a task was signaled during interrupt processing, the task scheduler will be invoked. Because Exec uses preemptive task scheduling, it can be said that the interrupt subsystem is the heart of task multiplexing. If, for some reason, interrupts do not occur, a task might execute forever because it cannot be forced to relinquish the CPU.		Task multiplexing usually occurs as the result of an interrupt. When an interrupt has finished and the processor is about to return to user mode, Exec determines whether task-scheduling attention is required. If a task was signaled during interrupt processing, the task scheduler will be invoked. Because Exec uses preemptive task scheduling, it can be said that the interrupt subsystem is the heart of task multiplexing. If, for some reason, interrupts do not occur, a task might execute forever because it cannot be forced to relinquish the CPU.

	[[File:LibTable26-1.png]]		[[File:LibTable26-1.png\|frame\|center\|Interrupts by Priority]]

	Figure 26-1: Interrupts by Priority

	=== Interrupt Priorities ===		=== Interrupt Priorities ===

Steven Solie at 18:38, 13 March 2013

2013-03-13T18:38:09Z

← Older revision		Revision as of 18:38, 13 March 2013
Line 667:		Line 667:

	Disable() increments a counter to track how many levels of disable have been issued. Only 126 levels of nesting are permitted. Enable() decrements the counter, and reenables interrupts when the last disable level has been exited.		Disable() increments a counter to track how many levels of disable have been issued. Only 126 levels of nesting are permitted. Enable() decrements the counter, and reenables interrupts when the last disable level has been exited.

			== Quick Interrupts ==

			One of the features of the Zorro III bus is the Quick Interrupt, also known as the vectored interrupt. This feature allows Zorro III
			hardware to supply a vector number to the system when an interrupt occurs. The system uses this vector number to go directly to an
			interrupt routine.

			=== Conventional Amiga Interrupts ===

			The Amiga handles normal interrupts from Zorro II cards using an interrupt server chain. There are two interrupts available from the
			Zorro II bus, the PORTS and EXTER interrupt server chains. If a driver for a Zorro II card needs to use an interrupt, it adds an interrupt routine to the appropriate chain. When the interrupt occurs, Exec calls each routine in the interrupt chain, which are sorted in priority order. Exec continues until it finds the routine that corresponds to the device that triggered the interrupt.

			The server chain allows several routines to share a single interrupt. This means that several devices trigger the same interrupt, so each interrupt routine must do some processing to determine if its card triggered the interrupt or if some other source caused the interrupt. For example, an interrupt routine might examine a register on its card to determine that the card triggered the interrupt.

			Although this scheme allows unrelated pieces of software to easily share an interrupt, it can make the interrupt overhead rather high.
			These two interrupt server chains also handle interrupts from the CIA chips, which are used to trigger a variety of events. As a result, these server chains can contain a multitude of interrupt routines.

			Consider what happens when a Zorro II card generates a PORTS interrupt. Exec has to perform some set up and then step through the PORTS server chain. Exec calls each interrupt routine in priority order looking for the routine that services this interrupt. If there are 20 interrupt routines of higher priority than the card's interrupt routine in the server chain, Exec has to call 20 other routines before it gets to the correct routine.

			=== Zorro III Quick Interrupts ===

			Quick interrupts avoid the overhead involved in Exec's interrupt server chains. Exec only helps set up the quick interrupt, which it does via the exec.library function ObtainQuickVector(). Once Exec has set up the quick interrupt routine, it does not intervene. Unlike conventional Amiga interrupt routines, which are called as subroutines from Exec's main interrupt code, the Amiga jumps directly to the quick interrupt routine using a private vector. This behavior requires quick interrupt routines to take some special precautions.

			There are two important differences between a conventional Amiga interrupt routine and a quick quick interrupt routine. A quick
			interrupt routine must save and restore all of the registers it changes, including D0, D1, A0, and A1. It must do this because, unlike
			regular interrupt routines, Exec doesn't do it for you. Also, a quick interrupt routine ends with a RTE (return from exception) instruction.

			If your quick interrupt routine is 100% self-contained and does not access any operating system structures or routines, then the work is rather simple. Just save the registers you use, perform your interrupt processing, restore the registers, and end with an RTE. If, however, the routine needs to call the OS or use an OS structure, it must check if the interrupt has been delayed. This is necessary in case the interrupt hit the CPU just after the CPU had told the hardware to hold off interrupts (see the Autodoc for ObtainQuickVector() to find out how to perform this test).

			As the Amiga OS is a dynamic operating system, quick interrupts are allocated by the OS. If your hardware/software wants to use a quick
			interrupt, it must allocate a vector with ObtainQuickVector(). This routine accepts a pointer to the quick interrupt code (not a pointer to an Interrupt structure). If Exec installed the vector, ObtainQuickVector() returns the vector number. When the quick
			interrupt occurs, the Zorro III card sends this vector number to the CPU, which tells the CPU where the interrupt code is.

			ObtainQuickVector() returns 0 if there are no more vectors. Since the number of vectors is limited, any Zorro III device that uses quick interrupts must be able to fall back to the Amiga's conventional interrupt scheme.

	== Function Reference ==		== Function Reference ==

Steven Solie: /* Software Interrupts */

2012-09-18T21:17:55Z

Software Interrupts

← Older revision		Revision as of 21:17, 18 September 2012
Line 648:		Line 648:
	{		{
	/* increment counter and re-send timerequest--IMPORTANT: This */		/* increment counter and re-send timerequest--IMPORTANT: This */
	/* self-perpetuating technique of calling ~~SendIO~~() during a software */		/* self-perpetuating technique of calling BeginIO() during a software */
	/* interrupt may only be used with the audio and timer device. */		/* interrupt may only be used with the audio and timer device. */
	tsidata->tsi_Counter++;		tsidata->tsi_Counter++;
	tr->Request.io_Command = TR_ADDREQUEST;		tr->Request.io_Command = TR_ADDREQUEST;
	tr->Time.Microseconds = MICRO_DELAY;		tr->Time.Microseconds = MICRO_DELAY;
	IExec->~~SendIO~~((struct IORequest *)tr);		IExec->BeginIO((struct IORequest *)tr);
	}		}
	/* Tell main() we're out of here. */		/* Tell main() we're out of here. */

Steven Solie: /* Software Interrupts */

2012-09-18T18:25:03Z

Software Interrupts

← Older revision		Revision as of 18:25, 18 September 2012
Line 648:		Line 648:
	{		{
	/* increment counter and re-send timerequest--IMPORTANT: This */		/* increment counter and re-send timerequest--IMPORTANT: This */
	/* self-perpetuating technique of calling ~~BeginIO~~() during a software */		/* self-perpetuating technique of calling SendIO() during a software */
	/* interrupt may only be used with the audio and timer device. */		/* interrupt may only be used with the audio and timer device. */
	tsidata->tsi_Counter++;		tsidata->tsi_Counter++;

Steven Solie: /* Software Interrupts */

2012-09-18T18:24:28Z

Software Interrupts

← Older revision		Revision as of 18:24, 18 September 2012
Line 573:		Line 573:
	/* +32. Also note that the correct node type for a software interrupt is */		/* +32. Also note that the correct node type for a software interrupt is */
	/* NT_INTERRUPT. (NT_SOFTINT is an internal Exec flag). This is the same */		/* NT_INTERRUPT. (NT_SOFTINT is an internal Exec flag). This is the same */
	/* setup as that for a software interrupt which you Cause().		/* setup as that for a software interrupt which you Cause(). */
	struct Interrupt *softint = IExec->AllocSysObjectTags(ASOT_INTERRUPT,		struct Interrupt *softint = IExec->AllocSysObjectTags(ASOT_INTERRUPT,
	ASOINTR_Code, tsoftcode,		ASOINTR_Code, tsoftcode,
Line 653:		Line 653:
	tr->Request.io_Command = TR_ADDREQUEST;		tr->Request.io_Command = TR_ADDREQUEST;
	tr->Time.Microseconds = MICRO_DELAY;		tr->Time.Microseconds = MICRO_DELAY;
	IExec->~~BeginIO~~((struct IORequest *)tr);		IExec->SendIO((struct IORequest *)tr);
	}		}
	/* Tell main() we're out of here. */		/* Tell main() we're out of here. */

Steven Solie: /* Disabling Interrupts */

2012-09-17T20:12:35Z

Disabling Interrupts

← Older revision		Revision as of 20:12, 17 September 2012
Line 662:		Line 662:
	== Disabling Interrupts ==		== Disabling Interrupts ==

	As mentioned in [[Exec_Tasks\|Exec Tasks]], it is sometimes necessary to disable interrupts when examining or modifying certain shared system data structures. However, for proper system operation, interrupts should never be disabled unless absolutely necessary, and ''never for more than 250 microseconds''. Interrupt disabling is controlled with the Disable() and Enable() functions~~. Although assembler DISABLE and ENABLE macros are provided, we strongly suggest that you use the system functions rather than the macros for upwards compatibility and smaller code size~~.		As mentioned in [[Exec_Tasks\|Exec Tasks]], it is sometimes necessary to disable interrupts when examining or modifying certain shared system data structures. However, for proper system operation, interrupts should never be disabled unless absolutely necessary, and ''never for more than 250 microseconds''. Interrupt disabling is controlled with the Disable() and Enable() functions.

	In some system code, there are nested disabled sections. Such code requires that interrupts be disabled with the first Disable() and not re-enabled until the ''last'' Enable(). The system Enable() and Disable() functions are designed to permit this sort of nesting.		In some system code, there are nested disabled sections. Such code requires that interrupts be disabled with the first Disable() and not re-enabled until the ''last'' Enable(). The system Enable() and Disable() functions are designed to permit this sort of nesting.