Instructions between control flow events

Abstract

A method including executing a plurality of instructions; identifying control flow events (such as branch instructions, exceptions, and exception return instructions); determining a number of the inst

Description

The present technique relates to data processing. It is desirable to be able to determine how many instruction executions occur within particular blocks of a program without having to rely on static analysis, which can be slow and inaccurate. Such information can be used, for instance, for determinations as to dynamic compilation, which can improve the efficiency of code execution. Viewed from a first example configuration, there is provided an apparatus comprising: a pipeline configured to execute a plurality of instructions; identification circuitry configured to identify control flow events; and storage circuitry configured to store one or more entries , wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate a number of instructions that lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event; and determination circuitry configured to determine the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event, wherein the control flow events comprise control flow instructions and changes in control flow. Viewed from a second example configuration, there is provided a method comprising: executing a plurality of instructions; identifying control flow events; determining a number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event; storing one or more entries, wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event, wherein the control flow events comprise control flow instructions and changes in control flow. Viewed from a third example configuration, there is provided a non-transitory computer-readable medium storing computer-readable code for fabrication of an apparatus comprising: a pipeline configured to execute a plurality of instructions; identification circuitry configured to identify control flow events; and storage circuitry configured to store one or more entries, wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate a number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event; and determination circuitry configured to determine the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event, wherein the control flow events comprise control flow instructions and changes in control flow. Viewed from a fourth example configuration, there is provided a system comprising the apparatus set out above implemented in at least one packaged chip; at least one system component; and a board, wherein the at least one packaged chip and the at least one system component are assembled on the board. Viewed from a fifth example configuration, there is provided a chip-containing product comprising the system described above, wherein the system is assembled on a further board with at least one other product component. The present technique will be described further, by way of example only, with reference to embodiments thereof as illustrated in the accompanying drawings, in which: Figure 1 illustrates a system in accordance with some embodiments; Figure 2 illustrates the relationship between functions and control flow events; Figure 3 illustrates how the storage circuitry might look; Figure 4A shows an example in which the determination circuitry includes count circuitry; Figure 4B shows an alternative example of the determination circuitry, which is based on the difference between instruction addresses; Figure 5 A shows a first example of how entries in the storage circuitry can be completed using the technique of Figure 4B; Figure 5B shows a second example of how entries in the storage circuitry can be completed using the technique of Figure 4B; Figure 5C shows a third example of how entries in the storage circuitry can be completed using the technique of Figure 4B; Figure 5D shows a fourth example of how entries in the storage circuitry can be completed using the technique of Figure 4B; Figure 6 illustrates, in the form of a flowchart, how each control flow event (e.g. control flow instruction) is handled; and Figure 7 shows a method of data processing in the form of a flow chart; Figure 8 shows the apparatus implemented on one chip or distributed over two or more of the chips. Before discussing the embodiments with reference to the accompanying figures, the following description of embodiments and associated advantages is provided. In accordance with some example configurations there is provided an apparatus comprising: a pipeline configured to execute a plurality of instructions; identification circuitry configured to identify control flow events; and storage circuitry configured to store one or more entries , wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate how many instructions lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event; and determination circuitry configured to determine the how many of the instructions lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event, wherein the control flow events comprise control flow instructions and changes in control flow. In these examples, it is possible to recognise control flow events (such as branch instructions, exceptions, and exception return instructions). Details of some of these control flow instructions are recorded in the storage circuitry each entry relating to a different control flow event. Each entry also indicates how many instructions lie between the recorded instructions. So for instance, if entries 1, 2, and 3 relate to branch instructions A, B, and C respectively then for instance entry 1 can indicate how many instructions lie between the start and branch instruction A, entry 2 can indicate how many instructions lie between branch instruction A and B, and entry 3 can indicate how many instructions lie between branch instructions B and C. The indication could be implicit by providing sufficient information for this to be unambiguously determined, or it could be explicit by providing an actual count. Note that the number of instructions in this context refers to the number of actually executed instructions, which may differ from the number of instructions that appear in the program display. For instance, a program might be displayed as a loop containing a single instruction. However, if this loop is executed 10 times then the actual number of executed instructions may be 10. Information regarding the number of instructions in blocks of code can be used to inform a decision of whether compilation is worth performing. For instance, for a block of code that contains a lot of instructions, is time consuming to interpret, or is frequently performed, it might be worth performing compilation as opposed to interpretation. In some instances, the blocks of code could be particular functions. E.g. as marked by a function call and a return instruction (i.e. two branches occur). Note that this technique does not necessitate the analysis of trace streams, which can be time consuming to unravel and interpret, as well as resource intensive to store in order to calculate instruction accounts. In the present technique, the instruction count can be determined quickly (e.g. it does not require raising an exception to access a protected resource) and hence is appropriate for a production level system. Note that the actual decision making process as to which units of code should be interpreted versus compiled is not relevant to the present technique. Any such methodology can be used. In some examples, the given recorded control flow event and the adjacent recorded control flow event are from among events including branch instructions. In general, a control flow events include control flow instructions that can be thought of as an instruction that causes the program flow to deviate from sequential ordering. For instance, the program might jump (potentially temporarily) to a new location in the program rather than just ‘the next instruction’. There are a number of such control flow instructions but not all control flow instructions need to be recorded. In these examples, the control flow instructions that are recorded include (but are not limited to) branch instructions (which can include conditional and unconditional, as well as direct and indirect branch instructions and also return instructions), which cause a jump in program flow. Such branch instructions also include branch-and-link instructions, which perform the same operation as a branch instruction but also store a return program location (e.g. in a link return register). Then when a return instruction is performed, the return can occur to the address stored in the link return register. In some examples, the recorded control flow events are from among events: branch instructions. In these examples, only certain control flow instructions are recorded. These types of control flow instruction might, for instance, be the sort of control flow instructions that completely represent function calls or another unit of execution upon which decisions of compilation versus interpretation are made. In some examples, the control flow instructions are taken control flow instructions. A non-taken branch typically causes the next instruction in the sequence to be executed and hence a non-taken branch generally does not result in a function call. Hence, in some examples such as those where a decision of compilation versus interpretation are made on a function-by-function basis, non-taken branch instructions are not relevant. In some examples, the apparatus wherein the determination circuitry comprises count circuitry configured to count a number of the instructions encountered since the adjacent recorded control flow event. The determination circuitry could be an increment-by-one counter where a running total can either be reset (e.g. back to a starting count such as zero) or can be incremented by one in response to different signals. The count circuitry can thus be incremented each time a new instruction is encountered, with the count circuitry being reset on entry to a function and being read at the end of the function. A value of the count circuitry at the end of the function thereby gives a readout of the number of instructions that have been executed. Such circuitry can be implemented easily and need not consider complex scenarios. In some examples, in response to a next recorded control flow instruction in the control flow instructions being encountered: a new entry in the storage circuitry is configured to indicate the how many of the instructions lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event based on a current value of the count circuitry, and a current value of the count circuitry is then reset. Each time a new entry is to be inserted, it is created indicating how many instructions lie between an event corresponding with the current entry and another event that corresponds with an adjacent entry. That is, there is an indication of how many instructions lie between two recorded control flow events. Having stored this data to the storage circuitry, the count circuitry is then reset (e.g. to zero) to begin counting until a next control flow event. In some examples, in response to a next recorded control flow event from the control flow events being encountered: a new entry in the storage circuitry is configured to indicate the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event based on a current value of the count circuitry based on an address at which the next recorded control flow event occurs and an address at which the adjacent recorded control flow event occurred. Rather than counting each individual instruction, it is possible to determine how many instructions lie between two other instructions (A and B) by subtracting the virtual address (e.g. program counter value) of the destination of A from B. In some situations, a further division might taken place (e.g. if each instruction is represented by several bytes). Using this address manipulation, it is possible to avoid invoking increment circuitry at every single instruction. In some examples, the determination circuitry comprises address storage circuitry configured to store an address of a previous taken branch instruction; and accumulation circuitry configured to store a running count of a number of the instructions encountered since a preceding recorded control flow event. Using the address manipulation technique, non-recorded branch instructions might be recorded that cause the flow of control to go backwards. In this case, simple subtraction may not work. In order to handle this, accumulation circuitry is provided that keeps a running total of the number of instructions encountered so far. By keeping a record of the destination of a previous taken branch instruction it is also possible to continue counting how many instructions are encountered after each taken branch (recorded or not) until a next recorded control flow event is encountered. In some examples, in response to one of the control flow events that is not one of the recorded control flow events, the accumulation circuitry is updated without recording a value of the accumulation circuitry; and in response to one of the control flow events that is one of the recorded control flow events, the accumulation circuitry is updated, a value of the accumulation circuitry is stored to the storage circuitry and the accumulation circuitry is then reset. In some examples, in response to an exception, a current value of the accumulation circuitry is saved. The process that occurs during an exception may generally be unknown - with one or more functions being potentially called (potentially in a nested-like manner). If such control flow events are not recorded then one way to deal with instruction counting using address manipulation is to store a value of the accumulation circuitry (and in some cases), any stored branch destination address. In some examples, in response to a return from the exception a stored value of the accumulation circuitry is restored to the accumulation circuitry. In this way, it is possible to inhibit an exception from affecting a count of a number of instructions between recorded control flow events. In some examples, each of the one or more entries comprises at least one of: a source indicator that indicates a source address associated with the one of the at least some control flow events, and a destination indicator that indicates a destination address associated with the corresponding one of the plurality of recorded control flow events. In some situations, both pieces of information may be provided. However, when dealing with exceptions (whose handling routines may be hidden from software) it is possible that entries may lack information that might reveal this information. In addition, since it may be desirable for information regarding the exception handling routines to be unknown, a number of instructions within blocks of code in the exception handling routine may also be unknown. In some examples, the control flow events include branch instructions, exceptions, and exception returns. Particular embodiments will now be described with reference to the figures. Figure 1 illustrates a system 2 in accordance with some embodiments. The system 2 includes a pipeline 32, which in this example is made up of a fetch circuit 4, decode circuit 6, rename circuit 8, one or more execution units 10, and a writeback circuit 22. The fetch circuit 4 is responsible for fetching instructions that are to be executed (e.g. from a memory and / or an instruction cache). The fetched instructions are then decoded by the decode circuitry 6 to produce one or more corresponding control signals. The instructions represented by these control signals can then be subject to a rename stage by rename circuitry 8, which is able to assign particular registers to the instructions in order to help remove false data dependencies and to allow for reordering of the instructions. The execution units 10 then perform the execution. In general, a number of execution units can be provided, each being tailored towards a separate task. In this example, the execution units include a first Arithmetic Logic Unit (ALU) 12 and a second Arithmetic Logic Unit (ALU) 14, which are responsible for performing various arithmetic and logical operations. A Floating Point Unit (FPU) can be used for performing floating-point operations. A load / store unit 18 is used to interact with the memory system - e.g. to write register values to memory and to retrieve memory values into registers. Finally, in this example, a branch unit 20 is used to perform control flow operations such as those that modify the program counter value. Of course, this is simply one example of execution units. Other systems may use other combinations and / or numbers of the execution units 10. Having performed execution of an instruction (i.e. the control signals that represent an instruction) a writeback is performed by writeback circuitry 22 such that data values are then stored back to registers. In this example, an optional link register 30 is also provided. The link register 30 can be used to store the return location of a previous branch-and-link (BL) instruction so that when a corresponding return (RET) instruction is encountered, the destination of that return is known. Functions are typically characterised by the use of an incoming branch-and-link instruction and an outgoing return instruction. In the branch-and-link instruction: the link register 30 is updated with a next sequential value of the program counter value (e.g. for the instruction following the BL instruction in program order) and a branch to the BL instruction destination takes place. When the corresponding return instruction is called, it performs a branch to the destination given in the link register 30. Prior to the branch-and-link instruction, a further instruction may be used to save the old version of the link register 30 to memory. Similarly, after returning, another instruction may be used to retrieve an old version of the link register 30 from memory. Interpretation is a technique in which instructions received by the decode circuitry 6 are translated from another form (e.g. rather than being read directly) using a piece of software (e.g. a virtual machine).It may be that several hundred (or even thousand) real instructions are executed for each interpreted instruction, which is therefore slow and resource intensive. Another technique that can be used is dynamic compilation where the instructions are translated from their ‘other’ language into a format directly recognisable by the decode circuitry 6 (e.g. using an assembler). The resulting instructions are more efficiently executed since they can be directed executed within the pipeline 32. However, the act of performing the dynamic compilation can be slow. In practice, a mixture of both techniques may be used for different parts (e.g. functions) of a program with some blocks (e.g. functions) being interpreted and other blocks being compiled and run natively. A number of different parameters may be taken into account when determining whether a given block should be compiled or left to interpretation. However, in some examples, the number of instructions that are actually executed is considered. That is, rather than considering the number of instructions that statically lie within the program code, the metric might consider how many instructions are actually handled by the execution units 10. Thus, a loop of one instruction that is executed 1000 times might produce a result of ‘1000’ rather than ‘ T. Having determined how much execution takes place within a particular block / function, it is possible to take a decision on whether time / resource should be invested in compiling that block. For instance, functions in which numerous instructions are executed may be more likely to be compiled (particularly if the length of the function is not very large) because this is more likely to result in instruction efficiency. The present technique provides a mechanism to efficiently count the number of instructions being executed in particular blocks (e.g. functions) and can be performed during runtime of that software. In this example, identification circuitry 24 is provided in order to determine the occurrence of control flow events. These may be control flow instructions (e.g. branches) or other events, such as exceptions, that cause the flow of control to change from its sequential path. Ultimately, the identification circuitry is able to determine the starts and ends of the blocks upon which a compilation / interpretation decision is to be made. Based on the detection of the control flow instructions, the determination circuitry 28 is used to determine the number of instructions that are executed within each block (e.g. function). This is then stored together with identifiers or definitions of each block in the storage circuitry 26. It is then up to the compiler and / or runtime software how the interpreted code is treated. For instance, the interpreted code could be converted into native code and then executed and this process could be repeated each time the interpreted code is encountered. Alternatively, a more static compilation could be performed once and the resulting native code could be directly executed each time the interpreted code is encountered. The compilation technique together with the actual compilation / interpretation decision making process are not relevant to the present technique, which is instead concerned with accurately determining the number of instructions executed within each block (e.g. function) so that such a decision can be made. Figure 2 illustrates the relationship between functions and control flow events (e.g. control flow instructions). The source code of function A contains a number of instructions including a function call to function B. As part of the function call, an old version of the link register 30 is saved e.g. to memory / the stack (not shown in Figure 2). The actual branch is then implemented as a branch-and-link (BL) instruction. A return address (typically the next address in sequence) is stored in the link register 30. A branch then occurs, which alters the program counter value to correspond with the target of the function call. In this case, the target is the start of the function B. Within function B, a similar situation arises. In particular, the code C(); signals a function call to function C. The previous value of the link register 30 (containing the return address in function A) is written to, e.g. the stack. A branch then occurs to function C. Function C then executes and in this example, no further function call occurs (although it is possible for other control flow events to occur such as exceptions - for the purposes of explanation it is assumed that such an event does not occur here). Once the function C has completed execution, a return process occurs. In particular, the return (RET) instruction is executed, which causes a branch to occur to the return address stored in the link register 30. In this case, this causes a return to the instruction after the function call to function C in the function B. The old version of the link register 30 may be retrieved and inserted into the link register 30 (not shown in Figure 2). Function B then completes, and a similar return process occurs with a branch occurring to the address previously stored in the link register 30 - the instruction after function call to function B. Again, any previous value of the link register 30 is then restored to the link register 30. In this example, within this time, it may be concluded that function C is to be compiled. Thus, when it is next called by function A, although the same sequence of events occurs, the execution itself will be of compiled instructions (assuming compilation has completed in time) rather than interpreted instructions and so function C may therefore execute more efficiently. In order to determine whether a given block / function should be compiled, records are kept in storage circuitry 26 regarding the number of instructions that are executed within each block / function. Decisions are then made, and compilation then occurs, in the background. Figure 3 illustrates how the storage circuitry 28 might look, with this information being usable (potentially with other data) to decide whether a particular block of code (e.g. a function) should be compiled or not. In this case, each entry contains at least one of a source address and a destination address. In addition, each entry may contain an instruction count. The source address may be the source of a control flow event - that is the PC value when the control flow event is encountered. The destination address may be the destination of the control flow event - the PC value to where the change in control flow is directed. The instruction count can be provided in two different ways. It can either represent the number of instructions between the source of one entry and the destination of the preceding entry or it can represent the number of instructions between the destination of one entry and the source of the next entry. In the example shown here, the instruction count represents the number of instructions between the source of one entry and the destination of the preceding entry. This means that it is not necessary to update a previously stored entry with the instruction count. In either case, the instruction count can be used to infer the number of instructions within a particular block / function. The method of determining the number of instructions will be illustrated in the following figures. For example, a given entry 40 has a source address of 0x313091 AC and a destination of 0x919AFC04. A next entry has a source address of 0x919AFC24 and a destination address of 0x313091 AO. In other words, a first branch (e.g. a branch and link instruction) goes from 0x313091 AC to 0x919AFC04 and a next branch (e.g. a return instruction) goes from 0x919AFC24 to 0x313091A0. The second entry 42 therefore indicates that there are (919AFC24 - 919AFC04) = 32 bytes between the destination of the previous branch and the source of the current branch. This equates to 32 / 4 = 8 instructions (each of four bytes). Also in this example, a control flow event type is recorded for each entry. This can be used to better understand the nature of each control flow event taken, which can be used to better calculate the size of particular function blocks (for instance). The recording of the control flow event is, however, optional and function sizes can be calculated as part of the return process (which marks the end of a function). Note that not all control flow events may be recorded. In some cases, only those control flow events that define blocks upon which dynamic compilation decisions are made are recorded. For instance, since functions can be defined by branch-and-link and return instructions, it may be appropriate to record only these types of control flow event. In other situations, multiple types of control flow event are recorded. In this situation, it might be necessary to amalgamate / add the instruction counts of several entries in the storage circuitry 26 in order to determine the instruction count of a function. In addition, only taken control flow events may be recorded. As explained above, not each entry has both a source address and a destination address. This can occur in response to certain types of control flow event. For instance, in the case of exceptions, it might not be desirable for the system to reveal where the exception handling code resides in memory (e.g. due to it being higher privileged code) and consequently the destination address associated with a control flow event in the form of an exception may be unavailable. Similarly, on return from an exception, the source address of the return instruction may not be provided, but the destination address (the place to return to from the exception) might be stored. The contents of the storage circuitry 26 may be accessible to software running at a user-level (e.g. lowest level) of privilege. This accessibility may be limited to read only access such that it is possible for a dynamic compiler to take a decision as to whether particular blocks of code should be compiled or not. The determination circuitry 28 can work in a number of ways. Two such ways are illustrated with respect to Figures 4A and 4B. Figure 4A shows an example in which the determination circuitry 28 includes count circuitry 400. Here, whenever an instruction is encountered, a next instruction notification is sent to the count circuitry 400, which causes a count in the count circuitry 400 to be incremented (e.g. by one). In addition, when a control flow event occurs, a notification is sent to the count circuitry 400. This determines whether the control flow event is of a type that should be recorded. If so, a current value of the count circuitry 400 is stored in the storage circuitry 26 together with details of the control flow event. The value of the counter in the count circuitry 400 is then reset. Thus, every instruction causes an increment to occur, with the final result being written to the storage circuitry when a recordable control flow event occurs. Figure 4B shows an alternative example, which is based on the difference between instruction addresses, and can perform the calculation without incrementing a count at each instruction. A difference in address between the start and end of a block (function) can be used to determine how many instructions were encountered (e.g. by dividing the difference by the length of each instruction - often four bytes). A difficulty with this technique is that the program flow might involve further function calls. For instance, a function might call another function. This can be handled by the use of address storage circuitry 404. So for instance, if the address of the previous control flow event occurred at instruction 0x0010 and the next control flow event occurred at instruction 0x0018, then this represents 8 bytes. If each instruction is four bytes, then this represents 2 (8 / 4) instructions. The number of instructions (or alternatively the number of bytes) is then used to increment a running count in the accumulation circuitry 402 and when an update is to occur, the current count is sent to the storage circuitry 26. The address storage circuitry 404 stores the destination of the previous taken control flow event (regardless of whether it was recorded or not) and it is this that helps a running total to be kept. Since the program counter will typically only decrease in response to a taken control flow event, by tracking the destination of each control flow event (regardless of whether it is a recordable type), it is possible to perform the subtraction described above. The subtraction may therefore be performed several times and accumulated (each time) in accumulation circuitry 402. This will be illustrated in more detail in Figures 5A and 5B Note that it is not necessary to consider non-taken control flow events in this manner because a non-taken control flow event will not cause a program counter value to decrease and will not cause the program counter to increase by any value other than the size of the instruction that caused the not-taken control flow event. Figure 5 A shows an example of how entries in the storage circuitry 26 can be completed using the technique of Figure 4B. As previously discussed, each entry relates to a particular taken control flow event (a taken control flow instruction or an exception) and records (where available) the source and destination of that control flow event. In addition, the number of instructions executed since / until an adjacent entry are also recorded. For instance, one entry relating to one recorded control flow instruction might indicate the number of instructions that are executed until another entry relating to a next recorded control flow instruction occurs. In Figure 5A, all taken control flow events are recorded. Figure 5A begins with an entry into function A (label: funcA). This causes the address storage circuitry 404 to store ‘funcA’ as the destination of the previous taken control flow event (regardless of whether it is recorded or not). The program then performs a comparison and at label Ac a branch if not equal (BNE) instruction is executed. In this case, it is assumed that the instruction is not taken and so no entry is made in the storage circuitry 26 and the address storage circuitry 404 is not updated. More (not shown) instructions are executed and then at label Ax, a branch-and-link (BL) instruction to funcB is called. This is an unconditional branch instruction and so it is taken. Consequently an entry is made in the storage circuitry 26. This entry indicates that the source of the control flow change is at label Ax (although in practice a program counter value may be given) and the destination is funcB. The number of instructions is counted as the difference in program counter value between the program counter at Ax (the current program counter value) and the program counter value stored in the address storage circuitry 404 (i.e. the program counter value at funcA). In this case, the result is divided by four because it is assumed that each instruction occupies four bytes of memory. In some embodiments, rather than providing an instruction count a byte difference can be recorded. In addition, because a control flow change is occurring, the new program counter value (i.e. the destination of the branch) is recorded in the address storage circuitry 404. The use of a BL instruction also causes the return address (Az) to be stored in the link register 30. Within funcB, nothing of relevance happens until the return instruction (RET) at exitB. Since RET is a recordable type of control flow event, a new entry is stored in the storage circuitry 26. Here, the source of the RET instruction is the label exitB, and the destination is Az. The number of instructions is calculated as the current program counter value (exitB) minus the value in the address storage circuitry 404 (funcB). Again, as described above, the value is divided by four. The address storage circuitry 404 is then (due to a change in control flow having occurred) updated to the new program counter value Az. The program then enters a loop, which performs a load (LDR), a comparison (CMP) and then performs a test (BNE) to determine if the loop should be restarted. This can result in zero or more entries being added to the storage circuitry 26 depending on how many iterations of the loop are taken. However, each iteration of the loop will relate to a branch instruction (BNE) in which the source is loopAend and the destination is loopA. Some amalgamation of the iterations can also be achieved in order to avoid creating a large number of entries for a loop with a high number of iterations (see, for instance, Figure 5C). Note that in some other examples, rather than producing multiple entries, each entry having the same source and destination are amalgamated. This could be achieved by adding the totals of each execution together (together with a number of occurrences) so that an average can be worked out. A first time around the loop, the number of instructions will be calculated as (loopAend-Az) / 4. At this point, the address storage circuitry 404 will be updated to store the destination of the branch (i.e. loopA) and for further iterations of the loop, the number of instructions will be calculated as (loopAend-loopA) / 4 (with the address storage circuitry 404 being ‘updated’ to loopA each time). In a final iteration of the loop, the branch will not be taken and so no entry will be made. However, the next instruction is a return (RET) instruction and so an entry will be generated for that. The return (RET) instruction will have a source of exitA (the label of the return instruction) and the destination will be any location given in the link register 30. The number of instructions will be calculated as the difference between exitA and the value stored in the address storage circuitry 404, which in this case will be the last taken branch destination - loopA (divided by four if desired). Figure 5B shows a second example in which an exception occurs within the program. In practice, because all control flow events are being recorded in this example, the presence of the exception has only a small effect. The process begins in a similar way to the example of Figure 5A and so the explanation has not been duplicated. Nevertheless, at a point Ak, an exception (a type of control flow event) occurs. A control flow change therefore occurs from the source Ak to (in this example) an unknown destination. The number of instructions executed since the previous entry is given according to the difference between the current program counter value Ak - 4 and the value stored in the address storage circuitry 404 (potentially divided by four). The current program counter value is reduced by four (the length of one instruction) because in the case of an exception, the instruction at Ak will not have executed and so should not be included in the count. When the exception is completed, a further new entry is entered due to the exception return (ERET) instruction. Here, the source is unknown, but the destination is Ak (note that the return address for an exception return instruction is the instruction that was executing when the exception was taken rather than the next instruction). The number of instructions executed since the previous entry may be unknown because the exception handling routine is not visible. The address storage circuitry 404 is then updated with the new value Ak because a control flow change has taken place. At Ax, the branch to funcB occurs. Here, the source and destination are Ax and funcB. The number of executed instructions is equal to the current program counter value minus the value stored in the address storage circuitry 404 (i.e. Ax - Ak) divided by four. Again, a control flow change occurs, so the address storage circuitry 404 is updated with the new destination, which is funcB. The remainder of the example occurs as set out above. Figure 5C shows a variant in which not all control flow events are recorded. In this example, only branch-and-link (BL) and return (RET) instructions have the number of instructions calculated and indeed in this example, entries are only made for those control flow instructions as well. Consequently, no entries are made for other branch instructions or exceptions. The address storage circuitry 404 continues to be updated for taken control flow events (of any kind) as previously discussed. The program flow in Figure 5C is the same as for Figure 5 A. The address storage circuitry 404 is loaded with the first program counter value or (if a control flow event has occurred) the destination of the most recently taken control flow event. A comparison is performed at the start of funcA and a branch if not equal (BNE) occurs at label Ac. The BNE instruction is not of the type that is recorded in the storage circuitry 26. Furthermore, in this example, it is assumed that the BNE is not taken and so no further action occurs. Further instructions may follow and at label Ax, a branch-and-link instruction (BL) to funcB occurs. The branch-and-link instruction is unconditional, is therefore taken, and so an update to the accumulation circuitry is made. In particular, the accumulation circuitry is incremented by a value equal to the current program counter value (Ax) minus the program counter value stored in the address storage circuitry 404 (funcA) divided by four (if appropriate). In this case, the BL instruction is of the kind of instruction that is recorded so an entry is inserted in the storage circuitry 26. The source (Ax) of the instruction and the destination (funcB) of the instruction are both recorded together with the number of instructions that have occurred since the last recorded entry - which has been accumulated in the accumulation circuitry 402 ((Ax-funcA) / 4). The instruction count in the accumulation circuitry 402 is then reset (e.g. to 0). At the same time, the address storage circuitry 404 is updated with the destination of the taken branch-and-link instruction, which is funcB. At funcB, a number of instructions may be executed, before a return (RET) instruction is encountered. The return (RET) instruction is one for which an entry is made in the storage circuitry 26 and is unconditional, so is taken. The entry therefore has a source of exitB, a destination of Az, and the number of instructions is equal to exitB minus the address stored in the address storage circuitry 404 (divided by four). The accumulation circuitry 402 is reset to 0, and the address storage circuitry 404 is set to the destination of the return instruction (i.e. to Az). The loop is then encountered. Unlike the example in Figure 5A, the details of the loop are not stored in the storage circuitry 26 because the loop makes use of a BNE instruction, which is a type of control flow instruction that is not recorded (regardless of whether it is taken or not). Instead, each time the BNE instruction is encountered, the accumulation circuitry 402 is incremented by the difference between the program counter value of the current taken branch instruction and the address stored in the address storage circuitry 404. The address in the address storage circuitry 404 is then updated to correspond with the destination of the branch. In this way, the address storage circuitry 404 can be used to calculate the number of instructions encountered since the most recent branch. The accumulation circuitry 402 then adds these numbers together until a control flow event that is to be recorded is encountered, at which point the value in the accumulation circuitry 402 is stored in the storage circuitry and then reset. In this case, the accumulated value is transferred to the storage circuitry 26 when the next instruction (RET at exitA) is encountered. Since the return instruction is of a type that is recorded, this causes the storage circuitry 26 to be updated and the accumulation circuitry 402 to be reset. Figure 5D shows an example that is similar to Figures 5B and 5C. In particular, this is an example in which only branch-and-link (BL) instructions and (non-exception) return instructions (RET) are recorded and in which an exception occurs. The process proceeds in the same way as for Figure 5C. However, at label Ak, an exception occurs. An exception is not one of the types of control flow even that is recorded and hence no entry is inserted into the storage circuitry 26. Moreover, in this example it is also not desirable for the accumulation circuitry 402 to be incremented by instructions within the exception. Consequently, a value of the accumulation circuitry 402 and a value of the address storage circuitry 404 are saved prior to the exception being handled (e.g. on the stack). In this example, these values are assumed to be restored as part of the exception return (ERET) instruction that is encountered once the exception has been serviced. Thus, for the purposes of the determination circuitry 28, it will be as if no exception occurred and indeed, the remainder of the flow proceeds in the same way as for Figure 5D. In other examples, the exception return (ERET) instruction will not restore the value of the address storage circuitry 404 and this is instead achieved by software (e.g. in the code that makes up the exception handling routine). Of course, the skilled person will appreciate that whichever approach is used is largely immaterial to the present technique. Note that the accumulation circuitry 402 and the address storage circuitry 404 may continue to operate in the same way as previously described. For instance, during the exception handling routine, various control flow events might be encountered -including branch-and-link (BL) instructions and return (RET) instructions. Details of these events might therefore be stored into the storage circuitry 26. However, in some embodiments, the taking of an exception could cause the determination circuitry 28 to deactivate until an exception return instruction is encountered. It will be appreciated that the accumulation circuitry 402 will include (a) the count of instructions since the last recorded control flow event. In addition to this, depending on the techniques that are implemented, the accumulation circuitry 402 may also include (b) a loop count (e.g. as used in the examples of Figures 5C and 5D). Figure 6 illustrates, in the form of a flowchart 600, how each control flow event (e.g. control flow instruction) is handled. In practice, the handling of exceptions can differ as to whether recording is restricted or not. For instance, in a first scenario (A), where recording is restricted to user-space events, neither exceptions nor exception returns are recorded and no recording of information occurs within the exception handling routing. In a second scenario (B), where recording is limited to user-space events plus the details of when an exception is being handled, exceptions and exception returns are recorded but recording does not occur within the exception handling routine. In a third scenario (C), where recording is complete, exceptions and exception returns are recorded together with other events encountered within the exception handling routine. With scenario (C), there may be no need to save the accumulator because it continues to be updated on each branch in the exception handling routine. In contrast, in scenarios A and B, the accumulator is saved and restored around the exception because we may switch to a different process in the handler which we want to independently record. The process begins at step 602 where a new event occurs. At step 604, it is determined whether the event is taken or not. If not, then the process simply returns to step 602. Otherwise, at step 606 it is determined whether the event is a branch instruction, exception, or exception return. If the event is a branch instruction then at step 608, the accumulation circuitry 402 is updated / incremented. This increment amount is equal to the difference between the current program counter value and the address stored in the address storage circuitry 404. Then at step 610 the address storage circuitry 404 stores the target of the branch. At step 612, it is determined if the branch instruction is to be recorded (e.g. dependent on which of scenarios A-C is being followed). If not, then the process returns to step 602. If so then a new record is set at step 614 using the current value of the accumulator 402 and the address storage circuitry 404. The value in the accumulator 402 is then set to 0. The process then returns to step 602. If, at step 606, the type of event i s an exception then at step 616, the accumulation value 402 is updated / incremented. The amount of the increment is equal to the current program counter value minus the address stored in the address storage circuitry 404, and this may be divided by the length of an instruction in bytes (e.g. by 4). At step 618 the address storage circuitry 404 is set to store the target address of the exception branch if permitted (depending on which of scenarios A-C is in effect above). Then at step 620, it is determined whether the event is one that is recorded or not. If so then a new record is set at step 622 using a current value of the accumulation value 402 and the address storage circuitry 404. The accumulation value 402 is then set to 0. In either case, at step 624, the current values in the accumulation circuitry 402 are saved. This saving can be performed in hardware, or it can be performed in software as part of the process of the exception handling routine (e.g. at the start of the exception handling routine). If, at step 606, the type of event is an exception return then at step 626, then at step 630, the value of the accumulation circuitry 402 is restored from a previous value together and the address storage circuitry 404 is restored from a previous value. In practice, this step may alternatively be performed in software as part of a return from an exception handling routine. The accumulation circuitry 402 is then updated if this is permitted (depending on which of scenarios A-C is in effect above). Then at step 630, the address storage circuitry 404 is updated using the target of the exception return. Then, at step 632, it is determined whether the event is one that is recorded. If so, then at step 634 a new record is generated using the values stored in the accumulation circuitry 406 and the accumulation value 402 is set to 0. In either case, the process then returns to step 602. Figure 7 shows a method of data processing in the form of a flow chart 700. At step 702, instructions are executed. At step 704, control flow events are identified. At step 706, it is determined how many instructions lie between adjacent recorded control flow events. Then at step 708, entries are stored (e.g. in storage circuitry 26), with each entry corresponding to a different recorded control flow event and indicating a number of instructions since an adjacent (e.g. the previous) recorded control flow event. Using this process, it is possible to determine how many instructions are executed in the execution of different blocks of code (e.g. functions). This determination can be made without resorting to raising exceptions to read restricted data and without static analysis of the program instructions (which can be hard if not impossible to analyse). This allows for the dynamic compilation of programs, e.g. so that a runtime decision can be made as to which blocks of code should be left to interpretation and which should be compiled, in order to improve performance over code execution. Concepts described herein may be embodied in a system comprising at least one packaged chip. The apparatus described earlier is implemented in the at least one packaged chip (either being implemented in one specific chip of the system, or distributed over more than one packaged chip). The at least one packaged chip is assembled on a board with at least one system component. A chip-containing product may comprise the system assembled on a further board with at least one other product component. The system or the chip-containing product may be assembled into a housing or onto a structural support (such as a frame or blade). As shown in Figure 8, one or more packaged chips 800, with the apparatus described above implemented on one chip or distributed over two or more of the chips, are manufactured by a semiconductor chip manufacturer. In some examples, the chip product 800 made by the semiconductor chip manufacturer may be provided as a semiconductor package which comprises a protective casing (e.g. made of metal, plastic, glass or ceramic) containing the semiconductor devices implementing the apparatus described above and connectors, such as lands, balls or pins, for connecting the semiconductor devices to an external environment. Where more than one chip 800 is provided, these could be provided as separate integrated circuits (provided as separate packages), or could be packaged by the semiconductor provider into a multi-chip semiconductor package (e.g. using an interposer, or by using three-dimensional integration to provide a multi-layer chip product comprising two or more vertically stacked integrated circuit layers). In some examples, a collection of chiplets (i.e. small modular chips with particular functionality) may itself be referred to as a chip. A chiplet may be packaged individually in a semiconductor package and / or together with other chiplets into a multi-chiplet semiconductor package (e.g. using an interposer, or by using three-dimensional integration to provide a multi-layer chiplet product comprising two or more vertically stacked integrated circuit layers). The one or more packaged chips 800 are assembled on a board 802 together with at least one system component 804 to provide a system 806. For example, the board may comprise a printed circuit board. The board substrate may be made of any of a variety of materials, e.g. plastic, glass, ceramic, or a flexible substrate material such as paper, plastic or textile material. The at least one system component 804 comprise one or more external components which are not part of the one or more packaged chip(s) 800. For example, the at least one system component 804 could include, for example, any one or more of the following: another packaged chip (e.g. provided by a different manufacturer or produced on a different process node), an interface module, a resistor, a capacitor, an inductor, a transformer, a diode, a transistor and / or a sensor. A chip-containing product 816 is manufactured comprising the system 806 (including the board 802, the one or more chips 800 and the at least one system component 804) and one or more product components 812. The product components 812 comprise one or more further components which are not part of the system 806. As a non-exhaustive list of examples, the one or more product components 812 could include a user input / output device such as a keypad, touch screen, microphone, loudspeaker, display screen, haptic device, etc.; a wireless communication transmitter / receiver; a sensor; an actuator for actuating mechanical motion; a thermal control device; a further packaged chip; an interface module; a resistor; a capacitor; an inductor; a transformer; a diode; and / or a transistor. The system 806 and one or more product components 812 may be assembled on to a further board 814. The board 802 or the further board 814 may be provided on or within a device housing or other structural support (e g. a frame or blade) to provide a product which can be handled by a user and / or is intended for operational use by a person or company. The system 806 or the chip-containing product 816 may be at least one of: an end-user product, a machine, a medical device, a computing or telecommunications infrastructure product, or an automation control system. For example, as a non-exhaustive list of examples, the chip-containing product could be any of the following: a telecommunications device, a mobile phone, a tablet, a laptop, a computer, a server (e.g. a rack server or blade server), an infrastructure device, networking equipment, a vehicle or other automotive product, industrial machinery, consumer device, smart card, credit card, smart glasses, avionics device, robotics device, camera, television, smart television, DVD players, settop box, wearable device, domestic appliance, smart meter, medical device, heating / lighting control device, sensor, and / or a control system for controlling public infrastructure equipment such as smart motorway or traffic lights. Concepts described herein may be embodied in computer-readable code for fabrication of an apparatus that embodies the described concepts. For example, the computer-readable code can be used at one or more stages of a semiconductor design and fabrication process, including an electronic design automation (EDA) stage, to fabricate an integrated circuit comprising the apparatus embodying the concepts. The above computer-readable code may additionally or alternatively enable the definition, modelling, simulation, verification and / or testing of an apparatus embodying the concepts described herein. For example, the computer-readable code for fabrication of an apparatus embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concepts. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits for defining an apparatus embodying the concepts. The code may define a HDL representation of the one or more logic circuits embodying the apparatus in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed Integrated Circuit Hardware Description Language) as well as intermediate representations such as FIRRTL. Computer-readable code may provide definitions embodying the concept using systemlevel modelling languages such as SystemC and SystemVerilog or other behavioural representations of the concepts that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concepts. Additionally or alternatively, the computer-readable code may define a low-level description of integrated circuit components that embody concepts described herein, such as one or more netlists or integrated circuit layout definitions, including representations such as GDSII. The one or more netlists or other computer-readable representation of integrated circuit components may be generated by applying one or more logic synthesis processes to an RTL representation to generate definitions for use in fabrication of an apparatus embodying the invention. Alternatively or additionally, the one or more logic synthesis processes can generate from the computer-readable code a bitstream to be loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for the purposes of verification and test of the concepts prior to fabrication in an integrated circuit or the FPGA may be deployed in a product directly. The computer-readable code may comprise a mix of code representations for fabrication of an apparatus, for example including a mix of one or more of an RTL representation, a netlist representation, or another computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus embodying the invention. Alternatively or additionally, the concept may be defined in a combination of a computer-readable definition to be used in a semiconductor design and fabrication process to fabricate an apparatus and computer-readable code defining instructions which are to be executed by the defined apparatus once fabricated. Such computer-readable code can be disposed in any known transitory computer-readable medium (such as wired or wireless transmission of code over a network) or non-transitory computer-readable medium such as semiconductor, magnetic disk, or optical disc. An integrated circuit fabricated using the computer-readable code may comprise components such as one or more of a central processing unit, graphics processing unit, neural processing unit, digital signal processor or other components that individually or collectively embody the concept. In the present application, the words “configured to...” are used to mean that an element of an apparatus has a configuration able to carry out the defined operation. In this context, a “configuration” means an arrangement or manner of interconnection of hardware or software. For example, the apparatus may have dedicated hardware which provides the defined operation, or a processor or other processing device may be programmed to perform the function. “Configured to” does not imply that the apparatus element needs to be changed in any way in order to provide the defined operation. Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to those precise embodiments, and that various changes, additions and modifications can be effected therein by one skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the dependent claims could be made with the features of the independent claims without departing from the scope of the present invention.

Claims

1. An apparatus comprising:a pipeline configured to execute a plurality of instructions;identification circuitry configured to identify control flow events; andstorage circuitry configured to store one or more entries, wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate a number of instructions that lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event; anddetermination circuitry configured to determine the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event, whereinthe control flow events comprise control flow instructions and changes in control flow.

2. The apparatus according to claim 1, whereinthe given recorded control flow event and the adjacent recorded control flow event are from among events including: branch instructions.

3. The apparatus according to claim 1, whereinthe recorded control flow events are from among events: branch instructions.

4. The apparatus according to any preceding claim, whereinthe control flow instructions are taken control flow instructions.

5. The apparatus according to any one of claims 1-4, whereinthe determination circuitry comprises count circuitry configured to count a number of the instructions encountered since the adjacent recorded control flow event.

6. The apparatus according to claim 5, whereinin response to a next recorded control flow event from the control flow events being encountered:a new entry in the storage circuitry is configured to indicate the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event based on a current value of the count circuitry, anda current value of the count circuitry is then reset.

7. The apparatus according to any one of claims 1-4, whereinin response to a next recorded control flow event from the control flow events being encountered:a new entry in the storage circuitry is configured to indicate a number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event based on a current value of the count circuitry based on an address at which the next recorded control flow event occurs and an address at which the adjacent recorded control flow event occurred.

8. The apparatus according to claim 7, whereinthe determination circuitry comprises address storage circuitry configured to store an address of a previous taken branch instruction; andaccumulation circuitry configured to store a running count of a number of the instructions encountered since a preceding recorded control flow event.

9. The apparatus according to claim 8, whereinin response to one of the control flow events that is not one of the recorded control flow events, the accumulation circuitry is updated without recording a value of the accumulation circuitry; andin response to one of the control flow events that is one of the recorded control flow events, the accumulation circuitry is updated, a value of theaccumulation circuitry is stored to the storage circuitry and the accumulation circuitry is then reset.

10. The apparatus according to any one of claims 8-9, whereinin response to an exception, a current value of the accumulation circuitry is saved.

11. The apparatus according to claim 10, whereinin response to a return from the exception a stored value of the accumulation circuitry is restored to the accumulation circuitry.

12. The apparatus according to any preceding claim, whereineach of the one or more entries comprises at least one of: a source indicator that indicates a source address associated with the one of the at least some control flow events, and a destination indicator that indicates a destination address associated with the corresponding one of the plurality of recorded control flow events.

13. The apparatus according to any preceding claim, whereinthe control flow events include branch instructions, exceptions, and exception returns.

14. A method comprising:executing a plurality of instructions;identifying control flow events;determining a number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event;storing one or more entries, wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate the number of the instructions that lie between the corresponding one of the plurality ofrecorded control flow events and the adjacent recorded control flow event, whereinthe control flow events comprise control flow instructions and changes in control flow.

15. Anon-transitory computer-readable medium storing computer-readablecode for fabrication of an apparatus comprising:a pipeline configured to execute a plurality of instructions;identification circuitry configured to identify control flow events; andstorage circuitry configured to store one or more entries, wherein each of the one or more entries is associated with a corresponding one of a plurality of recorded control flow events from the control flow events and is configured to indicate a number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and the adjacent recorded control flow event; anddetermination circuitry configured to determine the number of the instructions that lie between the corresponding one of the plurality of recorded control flow events and an adjacent recorded control flow event, whereinthe control flow events comprise control flow instructions and changes in control flow.

16. A system comprising:the apparatus of any one of claims 1-13, implemented in at least one packaged chip;at least one system component; anda board, whereinthe at least one packaged chip and the at least one system component are assembled on the board.

17. A chip-containing product comprising the system of claim 16, whereinthe system is assembled on a further board with at least one other productcomponent.

Images