JP2008305016A - Information processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an information processor for executing exception processing registered at each task with instantaneousness under the management of a kernel. <P>SOLUTION: An information processor 1 is provided with: a TCB 25 as a storage region managed by the kernel for controlling the execution of a plurality of tasks, and for storing attribute information showing whether or not each task has an exception processing route of each task; and the kernel 21. When any exception is generated, the kernel 21 decides whether or not the task when the exception is generated owns an exception processing routine of each task by referring to the attribute information of the TCB 25, and when deciding that the task when the exception is generated does not own the exception processing routine of each task, executes the exception processing managed by the kernel, and when deciding that the task when the exception is generated owns the exception processing routine of each task, executes the exception processing of each task owned by the task when the exception is generated. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an information processing apparatus, and more particularly to an information processing apparatus having an exception handling function.

  Conventionally, so-called exception processing has been performed in computers. Exception handling usually occurs during execution of a program by a central processing unit (hereinafter referred to as a CPU) and involves interruption of the process. There are two types of so-called exception handling. One is to notify the kernel (in this document, the term “kernel” is used in the same meaning as the so-called “operating system” or “OS”) as an event of a process execution request to guarantee continuous execution of an application program. The kernel starts exception processing corresponding to an event that has occurred, that is, an exception factor. By this exception processing, appropriate processing is performed on the generated exception, and after the appropriate processing is performed, the execution of the application program that is the generation source of the exception is continued. The other is the detection of an anomaly, and the kernel determines whether to stop the entire system or only the application program that generated the exception for the event that occurred, ie, the exception factor. Appropriate processing is performed. Both exception processes are important for making the application program and the system itself function or for stable operation.

  In general, in exception handling, a corresponding dedicated exception handling routine is assigned to one possible cause of exception. This exception handling routine is defined by the system, and the application program does not define the contents of exception handling.

  For example, the general flow of exception handling in the MIPS architecture is as follows. First, when an exception occurs during the execution of a task, a hardware processor detects the occurrence of the exception, and the virtual address of the instruction being executed at the time when the exception occurs is recorded in the EPC register. Further, an exception code, which is the type of exception that has occurred, is recorded in a predetermined field of the Cause register. At this time, for example, when the address reference action is the cause of the exception, the address of the reference destination is recorded in the BadVaddr register. The EXLbit indicating the exceptional state is set in the Status register that controls the CPU state, and the CPU execution state transitions to the kernel mode. The above is the basic operation of the coprocessor register in the CPU when an exception occurs.

  On the other hand, the basic operation of the kernel, which is software, is as follows. If an exception occurs during task execution, the address where the exception occurred in the processor is recorded in the EPC register. At this time, the program counter (hereinafter referred to as PC) transitions to a predetermined address called an exception vector. With this address transition, the kernel detects the occurrence of an exception and starts exception processing.

  The kernel saves the context, reads the exception code of the generated exception stored in the Cause register, specifies the type of the generated exception, and executes exception processing corresponding to the exception code of the generated exception. When the execution of exception processing ends, the kernel returns the context and executes return processing from exception processing. As a result, the task is resumed by returning to the task from which the exception occurred.

  The exception processing to be executed is a processing routine registered using a predetermined application program interface (hereinafter referred to as API) when the system is activated. Here, it is assumed that registered exception handling is managed by a table. That is, the registration of exception processing is an act of registering the address of the exception processing routine with respect to this management table, and the exception processing management table is referred to using the exception code as an offset value. This exception handling management table is managed by the kernel, and it is normally not permitted for an application program to directly refer to the exception handling management table.

  The exception handling routine is registered to the kernel by a dedicated means at the system initialization stage. For example, in the μITRON specification kernel, an API “def_exc ()” is defined for exception processing registration. The purpose of this API is to associate one exception processing routine with one exception factor, and this association is common in the system.

  However, in general implementation of exception handling as described above, exception handling may be implemented in the system before an application program operating on the system is determined. Therefore, it is impossible to implement exception handling that satisfies all the characteristics and requirements of application programs that run on the system. In other words, the processing contents of each exception processing provided by the system may not necessarily match the requirements for exception processing required by individual application programs.

  For example, when an overflow occurs in an integer operation, it is assumed that processing for the system overflow is invalidation of an exception and continuation processing of an application program. On the other hand, in an application program, it is assumed that there is a need to treat integer operations in the program as saturation operations. More specifically, when an integer operation overflow occurs in the application program, it is necessary to forcibly terminate the integer operation and to output the operation result as a specific upper limit value. That is, in this case, the needs of the exception processing implemented in the system and the exception processing required by the application program do not match.

  For such problems, for example, a function called task exception handling is defined in the μITRON4.0 specification. This function is realized by a mechanism that is executed on the task context at the time when execution of task exception processing defined for each task being executed is requested, that is, the task itself executes.

  However, exception processing related to execution of an application program is processing that needs to be appropriately processed when an exception occurs, and has both an application-dependent aspect and an architecture-dependent aspect.

  Therefore, individual exception handling can be specified as code that operates on the task context such as stack and heap. However, exception handling should be a privileged routine that operates in kernel mode from the standpoint of immediateness. In addition, exception handling that should be handled by the kernel should not be blocked beyond kernel authority.

  Conventionally, the inconsistency between the exception handling provided by the system and the exception handling required by the application program has been regarded as a problem. For this reason, hardware has been proposed in which identifiers (hereinafter referred to as IDs) are assigned to a plurality of exception processes, and a plurality of exception processes to which IDs are individually assigned are managed (see, for example, Patent Document 1).

  According to this proposal, when the software registers an exception handling ID in the hardware, when the corresponding exception occurs, the ID corresponding to the exception that occurred is referenced, and the exception handling that matches the referenced ID is selected. Loaded into memory. As a result, exception handling required by the software can be executed by the CPU.

  In this case, an ID is statically assigned to exception processing at the time of system design, and the exception processing to which the ID is assigned is shared among a plurality of software. Therefore, there is a problem that the system configuration including software is limited.

  There is also provided a data processing method that can abstract exception processing implemented for each application to an architecture-independent level and easily incorporate a plurality of exception processing environments (see, for example, Patent Document 2).

  According to this proposal, exception handling implemented for each application is abstracted to an architecture-independent level. When an exception occurs, communication for notifying the occurrence of the exception occurs between the kernel object and the exception request message receiving object in the application, and the exception request message receiving object is the entity of the exception processing. The overhead of sending an exception handling request to the object occurs. According to this method, portability is improved, but there is a problem that processing that depends on the architecture that exception handling is originally performed cannot be executed.

  Further, an information processing apparatus is provided that selects an exception process corresponding to a kernel based on the address of a PC in which an exception has occurred (see, for example, Patent Document 3).

However, according to this proposal, it is possible to specify exception processing for each address for one exception factor, but the search for exception processing that matches the address becomes enormous, and the corresponding processing is started when an exception occurs. There is a problem that the time until is not guaranteed.
JP 2003-58381 A Japanese Patent Laid-Open No. 11-53223 JP 7-44398 A

  Accordingly, an object of the present invention is to provide an information processing apparatus that can execute exception processing registered for each task with immediateness under the management of the kernel.

  According to one aspect of the present invention, a storage area managed by a kernel for controlling execution of a plurality of tasks included in a system, provided corresponding to each task, wherein each task is provided for each task. A task attribute information storage unit capable of storing attribute information indicating whether or not to have an exception handling routine, and referring to the attribute information in the task attribute information storage unit when an exception occurs, and when the exception occurs It is determined whether or not the task has an exception handling routine for each task. If the task when the exception occurs does not have the exception handling routine for each task, the exception handling managed by the kernel is executed. If the task when the exception occurs has an exception processing routine for each task, the exception processing for each task included in the task when the exception occurs It is possible to provide an information processing apparatus characterized by having a exception process execution unit for executing routines.

  According to the information processing apparatus of the present invention, exception processing registered for each task can be executed with immediacy under the management of the kernel.

Embodiments of the present invention will be described below with reference to the drawings.
(First embodiment)
First, based on FIG.1 and FIG.2, the structure of the information processing apparatus which concerns on this Embodiment is demonstrated. FIG. 1 is a configuration diagram showing a hardware configuration of the information processing apparatus according to the present embodiment.

  The information processing apparatus 1 according to the present embodiment includes a CPU 11, a RAM 12, a ROM 13, an input interface (hereinafter referred to as an input I / F) 14, an output interface (hereinafter referred to as an output I / F) 15, and a communication interface. (Hereinafter, referred to as a communication I / F) 16 and a bus 17. The CPU 11, RAM 12, ROM 13, input I / F 14, output I / F 15, and communication I / F 16 are connected to each other via a bus 17. A keyboard and mouse as the input unit 18 are connected to the input I / F 14, and a display and a printer as the output unit 19 are connected to the output I / F 15.

  When the user operates the input unit 18, a signal output from the input unit 18 is input to the CPU 11 via the input I / F 14 and the bus 17. The CPU 11 executes a corresponding program on the RAM 12 based on the input signal (the program on the RAM 12 is an expanded version of the program stored in the ROM 13 when the system is started up, or a hard disk drive as necessary. In other words, the program stored in the external storage device is dynamically expanded according to the input). Thereafter, the execution result of the program is output to the output unit 19 via the bus 17 and the output I / F 15. Accordingly, when the user designates an application program to be executed from the input unit 18, the designated application program is executed by the CPU 11, and the execution result is output to the output unit 19.

  FIG. 2 is a block diagram showing a software configuration of the information processing apparatus according to the present embodiment. As illustrated in FIG. 2, the information processing apparatus 1 is an application system including a CPU 11 and a program group executed on the CPU 11. A program group executed in the system includes a kernel 21, an API 22 provided on the kernel 21, a plurality of tasks 24a to 24n provided on the API 22, an exception handling program 26 of the system, and an interrupt service routine ( (Hereinafter referred to as “ISR”) 27.

  The system exception handling program 26 describes a program for executing exception handling of a task having a classic attribute, which will be described later. The ISR 27 is an interrupt processing routine (Interrupt Service Routine) that is executed in response to an interrupt factor detected by the kernel.

  Further, the task 24b has an exception processing program 23 dedicated to the task defined in the task. The exception processing program 23 describes a program for executing exception processing of an enhanced attribute task described later.

  Each of the plurality of tasks 24a to 24n includes task control block (hereinafter referred to as TCB) 25a to 25n having a predetermined data structure for the purpose of the kernel 21 controlling the task.

  The TCBs 25a to 25n are storage areas managed by the kernel, as will be described later. The TCBs 25a to 25n are provided corresponding to each task, attribute information indicating whether each task has an exception handling routine for each task, and correspondence information indicating a correspondence between the generated exception and the exception handling routine, Is memorized. The correspondence information is stored in the exception handling management table as table format information. Therefore, the TCBs 25a to 25n constitute a task attribute storage unit that stores task attribute information.

  Further, the kernel 21 stores an exception processing management table 21t in which correspondence information indicating correspondence between the generated exception and the exception processing routine for executing the exception processing of the entire system, that is, the exception processing routine managed by the kernel is stored. Have.

The API 22 and the kernel itself, which are functions provided to the application by the kernel, store task contexts in the TCBs 25a to 25n, describe task attributes and states, connect to queues for managing specific states, and the like. .
For example, “cre_tsk ()” is defined as an API related to task generation provided by the μITRON specification kernel. The programmer uses “cre_tsk ()” to register the function created by the programmer in the kernel as a task. When this API is executed, context initialization and a stack area are secured in accordance with the task attributes, and the generated task attributes can be described as arguments of the API.

  In the present embodiment, task attributes are expanded, a classic attribute is assigned to a conventional task, and an enhanced attribute is assigned to a task that is a target of the present embodiment. When the enhanced attribute is given at the time of task generation, the TCB is expanded, and a table having the same structure as the exception handling management table 21t of the kernel is copied and added to the TCB. That is, when the context of the enhanced attribute task is initialized, the contents of the exception handling management table 21t of the kernel are copied and registered in the exception handling management table configured on the TCB of the enhanced attribute task. Therefore, there is a constraint that generation of an enhanced attribute task must be performed after the registration of the exception handling program provided by the system in the kernel is completed. This constraint condition assumes that an enhanced attribute task is not a system component but an application program, and is not a substantial constraint.

  As described above, for a task having a task-specific exception handling routine, an exception handling management table having correspondence information for associating the generated exception with the exception handling routine is displayed in the corresponding TCB along with the task attribute information. Remembered.

  The kernel generally has a function of managing a task being executed. This function records the ID assigned to the task being executed in a dedicated management area, and records the ID of the task that has obtained the execution right every time the execution right changes between tasks. Further, the kernel distinguishes whether the program being executed is a task or a task-independent portion such as interrupt processing and exception processing. Management of this running program is a basic kernel function, not a special function.

  FIG. 3 is a diagram for explaining a procedure for registering exception processing in initialization. Here, it is assumed that the classic attribute is given to the task 24a shown in FIG. Hereinafter, the task 24a is referred to as a task A. The attribute of task A can be specified by "cre_tsk ()" of the task generation API. For example, if the task A has the classic attribute, the task A can be designated as the classic attribute in this “cre_tsk (A,...)”. In the process of generating task A, the kernel generates TCB A having a data structure for controlling task A. TCB A stores task control information and context.

  On the other hand, it is assumed that the enhanced attribute is given to the task 24b shown in FIG. Hereinafter, task 24b is referred to as task B. For example, since the task B has the enhanced attribute, the task B can be specified as the enhanced attribute by the task generation API in the “cre_tsk (B,...)”. Further, by the API, in the process of generating task B, the kernel 21 generates a TCB B having a data structure for controlling task B, but extends the TCB assigned to the task with the classic attribute, An exception handling management table 25bt for registering dedicated correspondence information is generated in TCB B.

  Assume that the program being executed is a task having a classic attribute or a task-independent portion such as an initialization handler. When “def_exc ()” that is an API for registering an exception handling program from this program being executed is executed, the kernel 21 registers exception handling in the exception handling management table 21 t managed by the kernel 21.

  On the other hand, it is assumed that the task having the execution right is a task having the enhanced attribute. When a task with the enhanced attribute executes “def_exc ()”, which is an API for registering an exception handling program in the initialization routine, the kernel 21 is prepared exclusively in the TCB B of the task B with the enhanced attribute. The exception processing unique to the task is registered in the exception processing management table 25bt.

  Next, a procedure for executing exception processing will be described. FIG. 4 is a diagram for explaining a flow of execution of exception processing for a task with a classic attribute, and FIG. 5 is a diagram for explaining a flow of execution of exception processing for a task with an enhanced attribute.

  Now, it is assumed that the task that has obtained the execution right is task A having a classic attribute as shown in FIG. If an exception occurs during the execution of task A, the CPU 11 detects the occurrence of the exception, and the virtual address of the instruction being executed at the time when the exception occurred is recorded in the EPC register. Further, an exception code, which is the type of exception that has occurred, is recorded in a predetermined field of the Cause register. At this time, if the address reference action is the cause of the exception, the reference destination address is recorded in the BadVaddr register. The EXLbit indicating the exceptional state is set in the Status register that controls the state of the CPU 11, and the execution state of the CPU 11 transitions to the kernel mode.

  When the address where the exception occurs in the CPU 11 is recorded in the EPC register, the PC transits to a predetermined address called an exception vector. With this address transition, the kernel 21 having the function of the exception processing execution unit detects the occurrence of an exception and starts exception processing.

  The kernel 21 saves the context, reads the exception code of the generated exception stored in the Cause register, and identifies the type of the generated exception. The kernel 21 accesses the TCB A of the task A from the ID of the task A being executed, and recognizes that the task A has the classic attribute. When the kernel 21 recognizes that the task A being executed has the classic attribute, the kernel 21 should refer to and execute the exception processing management table 21t managed by the kernel 21 using the generated exception code as an offset. Read the address of the exception handling routine. The read system-specific exception handling program is executed under the management of the kernel 21.

  When the execution of system-specific exception processing ends, the kernel 21 returns the context of task A and executes return processing from exception processing. As a result, the task A is resumed by returning to the task A from which the exception occurred. This is the normal exception handling flow.

  On the other hand, the task that has obtained the execution right is task B having the enhanced attribute as shown in FIG. If an exception occurs during execution of task B, the CPU 11 executes the same processing as the classic attribute.

  The kernel 21 saves the context, reads the exception code of the generated exception stored in the Cause register, and identifies the type of the generated exception. The kernel 21 accesses the TCB B of the task B from the ID of the task B being executed, and recognizes that the task B has the enhanced attribute. When the kernel 21 recognizes that the task B being executed has the enhanced attribute, the kernel 21 recognizes that the exception handling management table 25bt for the task B exists in the TCB B of the task B, and in the TCB B The exception handling management table 25bt is referenced using the generated exception code as an offset, and the address of the exception handling routine to be executed is read. The read task-specific exception handling program is executed under the management of the kernel 21. The exception handling routine in this case is described in the task B and is read and executed by the kernel 21.

  When the execution of task-specific exception processing ends, the kernel 21 returns the context of task B and executes return processing from exception processing. As a result, the task B returns to the task B from which the exception occurred and the execution of the task B is continued.

  Here, the flow of the above-described exception processing executed by the kernel 21 having the function of the exception processing execution unit will be described. FIG. 6 is a flowchart showing an example of the flow of exception processing executed by the kernel 21. This exception processing is started when an exception occurs.

First, when an exception occurs during execution of a certain program (step S1), the program being executed is interrupted.
Next, the PC address when an exception occurs is recorded in the EPC register, and the PC address transitions to a predetermined address called an exception vector. When the PC address transitions to the exception vector, the exception handler of the kernel 21 is activated via the routine arranged in the exception vector, and exception processing is started by the kernel 21 (step S2).

  When the kernel 21 starts exception processing, the kernel 21 saves the context of the program interrupted by the generated exception, accesses the Cause register of the CPU 11, and determines the cause of the exception (step S3). Subsequently, the kernel 21 determines whether the program that generated the exception is a task (step S4). If the program that generated the exception is not a task, the determination is NO and the process proceeds to step S8. On the other hand, if the program that generated the exception is a task, the determination is YES, and the kernel 21 reads the ID of the task being executed from the management information of the kernel 21 (step S5). Based on this ID, the kernel 21 accesses the TCB of the task pointed to by this ID. The kernel 21 accesses the TCB of the task and reads the task attribute (step S6). The attribute of the task is described in the TCB.

  Next, the kernel 21 determines whether or not the task in which the exception has occurred has the enhanced attribute, that is, whether or not the task in which the exception has occurred has a task-specific exception handling routine (step S7). If the task attribute is the classic attribute, the result is NO, and the exception handling management table 21t having exception handling management information managed by the kernel 21 is referred to (step S8). If the task attribute is the enhanced attribute, YES is set, and the exception handling management table having the exception handling management information defined in the TCB of the task causing the exception is referred to (step S9).

  Next, the kernel 21 executes an exception handling routine corresponding to the exception cause from the exception handling management information managed by the kernel 21 or the exception handling management information defined in the TCB of the task that generated the exception (step S10). ). In other words, if the task when the exception occurs does not have an exception handling routine for each task, the exception handling managed by the kernel is executed, and the task when the exception occurs has an exception handling routine for each task In this case, an exception handling routine for each task of the task when the exception occurs is executed.

  Finally, when exception processing is executed, the kernel 21 returns context and performs return processing from exception processing (step S11). When the return process is performed, the process returns from the exception process to the program that generated the exception, and the execution of this program is continued.

  As described above, the task that has obtained the execution right is an enhanced attribute task, and when the "def_exc ()" API for registering an exception handling program is executed in the enhanced attribute task, the kernel It is possible to register the exception handling unique to the task in the exception handling management table prepared exclusively in the TCB of the task with the enhanced attribute.

  Furthermore, when an exception occurs during the execution of a task having the enhanced attribute, the kernel can process the generated exception by the exception processing registered in the task in the TCB of this task.

  In the example described above, in the case of an enhanced attribute task, the exception processing management table of the kernel 21 is copied to the exception processing management table dedicated to the task in the TCB at the task generation stage. When it is desired to do so, a unique exception handling routine is described in the task, and the address of the execution routine in the exception handling management table existing in the TCB of the task is rewritten so that the routine is executed. In this way, task-specific exception handling can be easily executed.

  On the other hand, when an exception occurs in a task having a classic attribute and a task-independent portion, the generated exception can be processed by exception processing registered in the exception processing management table managed by the kernel.

  Therefore, according to the information processing apparatus of the present embodiment, it is possible to register exception processing that matches the specification of the application program to be executed for each task, thereby enabling a plurality of designs designed under different ideas on one kernel environment. An application program can be implemented, and registered exception handling can be executed with immediacy under the management of the kernel.

(Second Embodiment)
Next, a second embodiment will be described. In the first embodiment, each enhanced attribute task defines its own exception handling in the exception handling management table for each task. However, if a task calls and uses an independent and sharable function, it is necessary to know in advance what kind of exception processing that function requires, implement that exception processing, and verify it. The efficiency of system development is not improved. That is, a task using a shared routine should not implement exception handling specific to the shared routine in that task. If a shared routine requires special exception handling, the exception handling should be provided by the shared routine, and the exception handling must be fully validated during the development of the shared routine. .

  Therefore, in this embodiment, it is possible to set unique exception handling even in a library routine shared among a plurality of tasks. Specifically, the kernel rewrites and writes back the exception handling management table in the task TCB of the enhanced attribute at the entry and exit of the shared routine. A task that is allowed to call a shared routine that requires specific exception handling is a task with an enhanced attribute, and execution from a task that has a classic attribute and processing independent of the task is not allowed.

Since the hardware and software configurations of the information processing apparatus 1 according to this embodiment are the same as those in the first embodiment, description thereof is omitted.
FIG. 7 is a diagram for explaining a procedure for registering exception processing in the shared routine. Here, it is assumed that the enhanced attribute is assigned to each of the task 24b and the task 24n illustrated in FIG. Hereinafter, task 24b and task 24n are referred to as task B and task N, respectively. Since task B has an enhanced attribute, task B has an exception processing management table 25bt dedicated to task B in TCB B. Similarly, task N also has an exception processing management table 25nt dedicated to task N in TCB N.

  As shown in FIG. 7, the function “fft_SIMD” is shared between the task B and the task N. This shared routine is independent from task B and task N, and the designers of task B and task N know the function of the shared routine “fft_SIMD”, but what kind of exception handling does this shared routine internally? Not enough information about what you need. Therefore, shared routines must provide the necessary exception handling at the same time as their function.

  Therefore, at the entrance of this shared routine, execute “def_exc (FPE, & Ex_SIMD)”, which is an API for registering exception handling, and register the function “Ex_SIMD” of the shared routine as an exception for the “FPE” factor. Yes. Task B and task N calling this shared routine have enhanced attributes, and the exception handling routine “Ex_SIMD” is registered in each exception handling management table generated in TCB B and TCB N. .

  FIG. 8 is a diagram for explaining the flow of execution of exception processing that occurs during execution of the shared routine. As shown in FIG. 8, when task N calls a shared routine, registration of unique exception processing required by the shared routine is performed at the head of the shared routine. For example, in the case of the μITRON specification, by executing “def_exc ()”, the exception processing specified by the shared routine is registered in the exception processing management table 25nt existing in the TCN of task N.

  If an exception occurs while the shared routine called by task N is being executed, kernel 21 accesses TCB N of task N from the ID of task N being executed, and task N has the enhanced attribute. Recognize When the kernel 21 recognizes that the task N being executed has the enhanced attribute, the kernel 21 recognizes that the task N exception handling management table 25nt exists in the task N TCB N, and manages the exception handling in the TCB N. The exception code that generated the table 25nt is referred to as an offset, and the address of the exception processing routine to be executed is read. The read exception handling program specific to the shared routine is executed under the management of the kernel 21. The kernel 21 executes a return processing from the exception processing after executing the exception processing program specific to the shared routine.

  If an exception occurs while task B is executing a shared routine, an exception handling program specific to the shared routine is executed under the management of the kernel 21 in the same manner. When the shared routine “fft_SIMD” rewrites a part of the exception handling management table generated for each of TCB B and TCB N, task B and task N have the registration contents as necessary for the rewritten exception factor. Invalidation by overwriting, that is, exception processing before rewriting can be re-registered.

  As described above, when “def_exc ()”, which is an API for registering an exception handling program at the entrance of a shared routine, is executed, the task that calls the shared routine is the exception required by the shared routine function. Exception handling specific to the shared routine can be executed without owning the processing.

  Therefore, according to the information processing apparatus of the present embodiment, it is possible to register exception processing that matches the specification of the application program executed in the same manner as in the first embodiment, so that it differs on one kernel environment. A plurality of application programs designed based on the idea can be implemented, and registered exception processing can be executed with immediacy under the management of the kernel.

  Furthermore, for exceptions that occur during execution of a shared routine, register the exception handling specific to the shared routine in the exception handling management table of the executing task at the entry of the shared routine that is called during the execution of the task. The designer of this task does not need to know in advance what kind of exception processing the shared routine requires and can improve the efficiency of system development.

(Third embodiment)
Next, a third embodiment will be described. The information processing apparatus 1 according to the present embodiment has a multi-OS. Since the hardware configuration of the information processing apparatus 1 according to the present embodiment is the same as that of the first embodiment, description thereof is omitted. FIG. 9 is a block diagram illustrating an example of the software configuration of the multi-OS. This multi-OS is a method for implementing a general-purpose OS as one task of a real-time kernel, and is proposed in publicly known examples US5,995,745.

  As shown in FIG. 9, the multi-OS is implemented with another OS as one task that operates on the real-time kernel 31. Hereinafter, the OS implemented as this task is referred to as an OS task 32. When the enhanced attribute is given to the OS task 32, the real-time kernel 31 that manages the operation of the OS task 32 generates an exception processing management table dedicated to the OS task 32 in the TCB 33 of the OS task 32.

  The procedure for executing exception processing when an exception occurs during execution of an OS task is described. FIG. 10 is a diagram for explaining an example of the flow of exception processing when an exception occurs during execution of the OS task 32.

  When an exception occurs during execution of the OS task 32, the real-time kernel 31 accesses the TCB 33 of the OS task 32 from the ID of the OS task 32 being executed, and recognizes that the OS task 32 has the enhanced attribute. When the real-time kernel 31 recognizes that the OS task 32 being executed has the enhanced attribute, the real-time kernel 31 recognizes that the exception processing management table for the OS task 32 exists in the TCB 33 of the OS task 32, and the exception processing in the TCB 33 The exception code that generated the management table is referenced as an offset, and the address of the exception processing routine to be executed is read. The read exception handling program specific to the OS task is executed under the management of the real-time kernel 31. The real-time kernel 31 performs a return process from the exception process after executing the exception process program specific to the OS task 32.

  As described above, in the multi-OS environment, when the enhanced attribute is given to an OS task implemented as one task on the real-time kernel 31, an exception processing management table dedicated to this OS task is included in the TCB of this OS task. Is generated. In this case, in the OS task initialization routine, exception processing specific to the general-purpose OS corresponding to the OS task can be registered in the exception processing management table dedicated to this OS task. Therefore, for exceptions that occur while this general-purpose OS obtains the execution right as a task of this real-time kernel, it is specific to the general-purpose OS registered in the exception handling management table in the TCB of the task corresponding to this general-purpose OS. Exception handling is executed.

  Therefore, according to the information processing apparatus of each embodiment described above, it is possible to register exception processing that matches the specification of the application program to be executed for each task, so that it is designed under a different concept on one kernel environment. A plurality of application programs can be implemented, and registered exception handling can be executed with immediacy under the management of the kernel.

  There may be a plurality of general-purpose OSs implemented as tasks on the real-time kernel. Even in this case, the exception handling of this embodiment allows appropriate exception distribution for each general-purpose OS even in a multi-OS environment where multiple general-purpose OSs are implemented, and contradicts the multiple general-purpose OS environments that are implemented. It becomes possible to execute stably without doing.

  As described above, according to the above-described embodiments, exception processing that can occur during execution of an application program is not limited to system-specific exception processing, and can be defined for each task. Attribute as task management information given to each task, an extended task having an exception handling routine defined for each task and a task that executes only an exception handling routine unique to the system managed by the conventional kernel Can be distinguished. By referring to the attribute information, task-specific exception processing can be executed for a task having an extended attribute.

  For this purpose, the kernel extends the data structure for managing the task having the extended attribute, and adds the same data structure as the exception handling management table included in the kernel to the task having the extended attribute. In addition, the kernel provides means for registering the exception processing unique to the task in the exception processing management table for the task to which the extended attribute is given, specifically, the above-described API. Therefore, exception handling that matches the required specifications of each application program can be implemented for each task, and the kernel can execute appropriate exception handling based on the attribute information of the task being executed when an exception occurs. Become.

  As described above, according to each of the above-described embodiments, there is provided means for registering a plurality of exception processes for one exception factor in a kernel environment in which a plurality of application programs can be dynamically generated and executed. In addition, it is possible to realize an information processing apparatus capable of switching and executing exception processing to be executed in accordance with an application program being executed for an exception that occurs.

  The present invention is not limited to the above-described embodiment, and various changes and modifications can be made without departing from the scope of the present invention.

It is a block diagram which shows the structure of the hardware of the information processing apparatus which concerns on 1st Embodiment. It is a block diagram which shows the structure of the software of the information processing apparatus which concerns on 2nd Embodiment. It is a figure for demonstrating the procedure of registration of exception processing. It is a figure for demonstrating the flow of execution of the exception process of the task of a classic attribute. It is a figure for demonstrating the flow of execution of the exception process of the task of enhanced attribute. It is a flowchart which shows the example of the flow of the exception process which a kernel performs. It is a figure for demonstrating the procedure of registration of the exception process in a shared routine. It is a figure for demonstrating the flow of execution of the exception process which occurred during execution of a shared routine. FIG. 3 is a block diagram illustrating an example of a software configuration of a multi-OS. It is a figure for demonstrating the flow of exception processing when an exception generate | occur | produces during execution of OS task.

Explanation of symbols

DESCRIPTION OF SYMBOLS 1 Information processing apparatus, 11 CPU, 21 kernel, 22 API, 23 Exception processing program 24a 24b 24n Task, 25a 25b 25n TCB, 21t 25bt 25nt Exception processing management table

Claims (5)

A storage area managed by the kernel to control the execution of a plurality of tasks included in the system, provided corresponding to each task, and whether each task has an exception handling routine for each task A task attribute information storage unit capable of storing attribute information indicating;
Refer to the attribute information in the task attribute information storage unit when an exception occurs, determine whether the task when the exception occurs has an exception processing routine for each task, and the exception occurs If the task at the time does not have an exception handling routine for each task, execute the exception handling managed by the kernel, and if the task when the exception occurs has an exception handling routine for each task, An information processing apparatus comprising: an exception processing execution unit that executes an exception processing routine for each task included in a task when the exception occurs.   The information processing apparatus according to claim 1, wherein correspondence information for associating the exception with the exception handling routine is provided for a task having an exception handling routine for each task.   The information processing apparatus according to claim 2, further comprising an application program interface for registering the exception handling routine for each task in the correspondence information.   When a plurality of the tasks exist and share a library routine, a dedicated exception handling routine defined in the library routine is determined based on the correspondence information of the task that called the library routine. The information processing apparatus according to claim 2.   The correspondence information is stored in the task control block by copying kernel correspondence information for associating the exception with an exception handling routine managed by the kernel at the time of initialization of the system. The information processing apparatus according to claim 3.

Images