Hints in a data processing apparatus

Abstract

An apparatus is described having decoding circuitry that is responsive to a sequence of instructions to generate control signals, data processing circuitry comprising data processing functional hardware, and a plurality of registers. The data processing circuitry is responsive to the control signals to operate the data processing functional hardware in an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in the plurality of registers, to produce data processing results. The decoding circuitry is responsive to a register identifying hint instruction preceding the sequence of instructions to generate hint metadata in dependence on at least one register identified by the register identifying hint instruction. The data processing circuitry is arranged, when the hint metadata is present, to be responsive to the control signals to operate the data processing functional hardware in a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results, where the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata.

Description

[0001] HINTS IN A DATA PROCESSING APPARATUS

[0002] BACKGROUND

[0003] The present disclosure relates to data processing. In particular, the present disclosure relates to providing operational hints in a data processing apparatus.

[0004] A data processing apparatus is caused to carry out selected data processing operations by being provided with a sequence of instructions defining what those data processing operations should be. The instructions must be predefined for a data processing apparatus, this collection of predefined instructions commonly being referred to as its “instruction set”. It is, on the one hand, useful for a data processing apparatus to be able to perform many defined data processing operations, but on the other hand this comes at the cost of a corresponding large number of instructions needing to be defined as part of its instruction set. Moreover, where the instructions defined for the instruction set are specified within a limited number of bits, this in turn limits the number of individual instructions which can be defined, and therefore for an instruction to be defined for a given data processing operation requires justification for the use of that “instruction space” within the instruction set. Consequently the number of individual data processing operations for which instructions may be defined is limited. This imposes a constraint on the ability of the programmer of the data processing apparatus to define the data processing operations which it should perform in a concise number of data processing instructions. SUMMARY

[0005] In one example arrangement there is provided an apparatus comprising: decoding circuitry to decode instructions, wherein the decoding circuitry is responsive to a sequence of instructions to generate control signals; data processing circuitry comprising data processing functional hardware; and a plurality of registers; wherein the data processing circuitry is responsive to the control signals to operate the data processing functional hardware in an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in the plurality of registers, to produce data processing results; wherein: the decoding circuitry is responsive to a register identifying hint instruction preceding the sequence of instructions to generate hint metadata in dependence on at least one register identified by the register identifying hint instruction; the data processing circuitry is arranged, when the hint metadata is present, to be responsive to the control signals to operate the data processing functional hardware in a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results; and the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata.

[0006] In another example arrangement, there is provided a computer-readable medium to store computer-readable code for fabrication of the apparatus mentioned above. In a yet further example arrangement there is provided a method of modifying an operating procedure of a data processing apparatus, comprising: decoding a sequence of instructions to generate control signals; operating data processing functional hardware, in response to the control signals, in an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in a plurality of registers, to produce data processing results; generating, in response to a register identifying hint instruction preceding the sequence of instructions, hint metadata in dependence on at least one register identified by the register identifying hint instruction; and when the hint metadata is present, operating the data processing functional hardware, in response to the control signals, in a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results, wherein the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata.

[0007] In a still further example arrangement there is provided a computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising: instruction decoding program logic to decode instructions, wherein the instruction decoding program logic is responsive to a sequence of instructions to generate control signals; data processing program logic to simulate data processing functional hardware; and register simulating program logic to maintain register emulating data structures to emulate a plurality of registers; wherein the data processing program logic is responsive to the control signals to operate according to an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in the register emulating data structures, to produce data processing results; wherein: the instruction decoding program logic is responsive to a register identifying hint instruction preceding the sequence of instructions to generate hint metadata in dependence on at least one register identified by the register identifying hint instruction; the data processing program logic is arranged, when the hint metadata is present, to be responsive to the control signals to operate according to a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results; and the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata. Such a computer program 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. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Further aspects, features and advantages of the present technique will be apparent from the following description of examples, which is to be read in conjunction with the accompanying drawings, in which:

[0009] Figure 1 schematically illustrates a data processing apparatus in accordance with one example implementation;

[0010] Figure 2 schematically illustrates a data processing apparatus in accordance with an alternative example implementation;

[0011] Figure 3 schematically illustrates how the hint metadata processing circuitry of Figure 1 may be used to update the hint metadata associated with the registers, in accordance with one example implementation;

[0012] Figure 4 illustrates in more detail the hint control unit of Figure 2, in accordance with one example implementation;

[0013] Figure 5 is a flow diagram illustrating steps performed in response to hint metadata being generated, in accordance with one example implementation;

[0014] Figure 6 is a flow diagram illustrating steps that may be taken in response to one example form of a later trigger referred to in Figure 5, in accordance with one example implementation;

[0015] Figures 7A and 7B schematically illustrates possible encodings of a register identifying hint instruction, in accordance with example implementations;

[0016] Figures 8A and 8B schematically illustrate possible encodings of a register hint clear instruction, in accordance with example implementations;

[0017] Figure 9 is a flow diagram illustrating steps that may be undertaken in response to decoding a register identifying hint instruction, in accordance with one example implementation;

[0018] Figure 10 is a flow diagram illustrating steps that may be undertaken in response to decoding a register hint clear instruction, in accordance with one example implementation;

[0019] Figure 11 illustrates how detection of an event giving an implicit hint clear indication may be processed, in accordance with one example implementation; and

[0020] Figure 12 illustrates a simulation example.

[0021] DESCRIPTION OF EXAMPLES

[0022] In accordance with one example configuration, there is provided an apparatus having decoding circuitry that is arranged to decode instructions, so as to be responsive to a sequence of instructions to generate control signals defining the data processing operations to be performed in order to execute those instructions. The apparatus also includes data processing circuitry providing data processing functional hardware, which is responsive to the control signals to perform the required data processing operations. The apparatus additionally has a plurality of registers which are used by the data processing circuitry when performing those operations, for example to provide source operand values used when performing the operations, or to store result values generated as a result of performing those operations.

[0023] The data processing circuitry is responsive to the control signals to operate the data processing functional hardware in an operating procedure to perform the data processing operations defined by the sequence of instructions, using data stored in the plurality of registers, to produce data processing results.

[0024] In accordance with the techniques described herein, the decoding circuitry is responsive to a register identifying hint instruction preceding the sequence of instructions to generate hint metadata in dependence on at least one register identified by the register identifying hint instruction. Further, the data processing circuitry is arranged, when the hint metadata is present, to be responsive to the control signals to operate the data processing functional hardware in a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results. The modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata

[0025] The present techniques provide a register identifying hint instruction which the programmer of the apparatus can introduce into the sequence of data processing instructions which controls operation of the apparatus. The operation of the apparatus in response to the sequence of data processing instructions is determined by the control signals generated by its decoding circuitry, which in turn depend on the particular sequence of data processing instructions which it receives. Including the register identifying hint instruction in the data processing instructions provided to the apparatus causes a modification in how the apparatus responds to data processing instructions which it receives after that hint instruction, by causing the data processing functional hardware to be operated in a modified operating procedure.

[0026] It is important to appreciate that the above-described instruction is a “hint” instruction, and the present techniques therefore are not concerned with changing the data processing operations carried out in response to the sequence of data processing instructions in a functional manner, i.e. to change the data processing results which the data processing operations produce. Rather, the present techniques are concerned with modifying the manner in which the data processing operations are carried out (in terms of “performance”), such that the data processing operations may, for example, be carried out in a manner for which the efficiency, power consumption, latency, and so on may vary with respect to the manner in which they would have been carried out had the hint instruction not been used. The apparatus is arranged to produce the same data processing results whether the sequence of data processing instructions are carried out according to the operating procedure (i.e. not preceded by the register identifying hint instruction) or are carried out according to the modified operating procedure (i.e. when preceded by the register identifying hint instruction). The same results are produced by either procedure, but the manner in which those results are produced can vary in a range of ways between the operating procedure and the modified operating procedure.

[0027] Accordingly, the present techniques provide the programmer, and indeed the instruction set architect, with a mechanism for modifying the manner in which the apparatus responds to one or more data processing instructions which form the sequence of data processing instructions, without having to redefine a number of data processing instructions as part of the instruction set of the apparatus in order to achieve that modification.

[0028] One form of hint instruction has been previously described in commonly owned US Patent 10,572,259, the entire contents of which are hereby incorporated by reference. In accordance with the techniques described in that earlier case, the hint instruction described therein seeks to directly identify a number of subsequent instructions after the hint instruction to which the hint applies, for example by specifying a hint assertion vector, where each bit in the hint assertion vector corresponds to an instruction in a number of subsequent instructions, and the decoder is then arranged to cause at least one performance modifying control signal to be asserted in association with those identified instructions. Whilst such an approach can work well in some applications, it has been realised that there are some limitations when using that form of hint instruction. Firstly, the number of subsequent instructions that can be specifically identified in such a way is quite limited, given the instruction encoding space available, and hence the hint can only be applied to a relatively small number of instructions. As a result multiple hint instruction spread throughout the instruction sequence may be required, which can reduce the performance and negate the benefit of the modified operating procedure. This can be problematic in many practical scenarios, for example where loop unrolling is used. In addition, seeking to directly identify the instructions to which the hint should be applied can be problematic in many code sequences, for example where the code contains branches, since each branch path may contain different numbers of instructions that it may be appropriate to seek to associate the hint with, and accordingly it is not possible to directly identify the instructions to which the hint should be associated using techniques such as the earlier-mentioned hint assertion vector.

[0029] In accordance with the techniques described herein, these problems are alleviated through the use of the above described register identifying hint instruction. When using such a hint instruction, the hint instruction identifies at least one register, and hint metadata is generated in dependence on the one or more registers identified. This hint metadata can then be used to influence the operating procedure used to perform the data processing operations defined by the subsequent sequence of instructions. For example, the operating procedure may be altered in association with one or more instructions that access the identified register(s), with the aim of seeking to improve performance. Since the register identifying hint instruction identifies one or more registers, with each register being accessed by one or more instructions, rather than seeking to directly identify one or more instructions in the subsequent instruction sequence, the technique is very scalable, allowing the hint to be applied in respect of a large number of subsequent instructions. Further, the hint can be used with code sequences where use of the previously described form of hint instruction would be problematic, for example code sequences including branches, since the hint information can be applied irrespective of the branch path taken. Furthermore, the register identifying hint instruction is easier to implement in hardware, merely requiring metadata to be kept on a register-by-register basis rather than needing to provide instruction tracking hardware.

[0030] Which registers are identified within the register identifying hint instruction can be chosen in dependence on the code within which the register identifying hint instruction is used, and the type of hint seeking to be generated by the use of the register identifying hint instruction. However, typically it is expected that the at least one register identified by the register identifying hint instruction will be a register that will be accessed by at least one instruction in the following sequence of instructions. The hint metadata generated as a result of the register identifying hint instruction is used to cause the data processing circuitry to operate the data processing functional hardware in a modified operating procedure, where that modified operating procedure differs from the normal operating procedure by implementing one or more performance measures in dependence on the hint metadata. The time at which these performance measures are implemented may vary, for example dependent on the form of hint metadata generated and / or the type of performance measure being implemented. However, typically the aim of implementing the one or more performance measures will be to seek to improve performance of the apparatus when performing the data processing operations defined by the sequence of instructions.

[0031] There are many different types of performance measure that could be implemented. For instance, in one example use case, the above-mentioned register identifying hint instructions can be used in the application of non-temporal behaviour to memory operations. Non-temporal memory operations are a variant of normal load and store operations, where the accessed data is not expected to be accessed again soon, and therefore does not need to be retained in the caches. Hence, if certain accesses can be flagged as being non-temporal, the cache allocation / eviction policy of one or more caches can take that information into account in order to seek to make more optimal use of the cache resources, thereby improving performance, reducing energy consumption, etc.

[0032] As another illustrative example use case, the above-mentioned register identifying hint instructions can be used to flag prefetch behaviour in respect of certain instructions. For instance, the generated hint metadata could be used to trigger prefetching behaviour to occur, or indeed in some instances to disable prefetching behaviour, in association with certain instructions that reference the register(s) indicated by a register identifying hint instruction, with the aim of seeking to improve overall performance of the apparatus.

[0033] As mentioned earlier, the point in time at which any given performance measure is implemented in dependence on the generated hint metadata may vary in dependence on a variety of factors, for example the type of hint metadata generated. In one example implementation, at least one of the one or more performance measures is implemented in association with performing one or more data processing operations defined by one or more given instructions in the sequence of instructions that accesses a given register identified by the register identifying hint instruction Hence, in such implementations, the performance measure may be implemented in combination with the performance of at least a certain type of data processing operation that accesses a given register identified by the register identifying hint instruction. As a particular example of where such an approach may be appropriate, this may be used when the hint metadata provides a non-temporal hint in association with the data stored in the given register. For instance, a memory access operation may be used to load data from memory into the given register, or to store data from the given register to memory, and when that memory access activity causes the data to be cached within a cache structure of the apparatus, the flagging of the data as being non-temporal can enable a more efficient implementation of the cache structure, for example by marking that data as being able to be evicted more quickly than might otherwise be the case, thereby freeing up space for the data that will in fact be used repeatedly.

[0034] In one example implementation, the one or more given instructions may be instructions that use a value held in the given register in a predetermined manner. Hence, the use of the hint metadata to trigger a performance measure may be dependent on how the value in the given register is used. By way of one specific example, it may be decided to trigger a performance measure when the value held the given register is used as a pointer by a memory access instruction. For example, it may be considered that this is the use case where it is appropriate to mark the access as being non-temporal.

[0035] Similarly, the one or more given instructions may be instructions of a predetermined type, and hence only when an instruction is of that predetermined type, and optionally also uses the data held in the given register in a particular way, will the hint metadata come into play and cause an associated performance measure to be implemented. By way of example, the use of the hint metadata to trigger a performance measure may be limited to memory access instructions.

[0036] Whilst in the above examples the performance measure is triggered in association with the performance of a data processing operation defined by a particular instruction, in addition, or alternatively, one or more performance measures may be implemented in response to generation of the hint metadata. In particular, for some types of hint metadata, it may be possible to act on the hint metadata once that hint metadata has been generated, to trigger one or more performance measures without needing to wait for one or more subsequent instructions to access the register(s) identified by the register identifying hint instruction. By way of specific example, when performing prefetching, it may be flagged using the hint metadata that the data to be used by one or more subsequent instructions that reference a given register identified by the register identifying hint instruction should be prefetched into a cache to improve performance when those one or more subsequent instructions are actually executed, and accordingly the prefetching activity can be implemented before those instructions are executed In some examples a subsequent instruction that modifies the value of a register that has been flagged using hint metadata would trigger a further prefetch, thereby improving the performance of further subsequent instructions that use the flagged register as a pointer. It will therefore be appreciated that in some examples the one or more performance measures may be triggered both in response to the generation of the hint metadata, and in response to subsequent instructions that modify the value stored in the register tagged by the hint metadata As another example, the hint metadata could be used to disable prefetch training on a given load event. For example pointer chasing workloads are known to be adversarial to prefetching and can pollute prefetch training structures. Thus, bypassing training for these load events may improve overall prefetch performance.

[0037] There are a number of ways in which the hint metadata may be maintained and used by the apparatus. In one example implementation, the apparatus further comprises hint metadata storage associated with the plurality of registers, and hint metadata processing circuitry to store the hint metadata in the hint metadata storage. In accordance with such an approach, the data processing circuitry can then be arranged to access the hint metadata storage in order to determine, for a specified register, whether that specified register has hint metadata associated therewith. Hence, in accordance with such an approach, when a register identifying hint instruction is decoded by the decoding circuitry, the generated hint metadata can be forwarded to the hint metadata processing circuitry to cause that hint metadata to be stored in the hint metadata storage in association with the identified register(s). Since the hint metadata is provided on a register-by-register basis, the amount of storage required to maintain the hint metadata can be quite small. Indeed, in a simple implementation where only one type of hint metadata is used, and that hint metadata is either present or absent for any given register, then it will be appreciated that the hint metadata storage requirements may amount to just a single bit per register, hence requiring a very low overhead in terms of additional storage to maintain the hint metadata information.

[0038] The hint metadata storage can take a variety of forms, and hence for example could be a separate storage structure to the storage structure providing the plurality of registers, or could be integrated therewith. In one example implementation, the hint metadata storage comprises a metadata field provided for each register, into which any associated hint metadata is stored by the hint metadata processing circuitry.

[0039] In implementations where at least one of the performance measures is implemented in association with performing one or more data processing operations defined by one or more given instructions that access a given register identified by the register identifying hint instruction, then the fact that those one or more given instructions identify the given register may cause the hint metadata for the given register be accessed and the at least one performance measure to be implemented. Hence, it is not necessarily the case that the register in question needs to be accessed in order to trigger the use of the hint metadata, but instead it is the fact that the instruction refers to that register that may cause the hint metadata for that register to be used. Purely by way of example, it may be detected early in the processing pipeline that a register is used as a destination, and in such cases a performance optimisation could be triggered early before the result of the instruction is available and hence before the actual access to the register to write the result can take place.

[0040] As mentioned earlier, there are a number of ways in which the hint metadata may be maintained and used by the apparatus. As an alternative to providing hint metadata storage associated with the plurality of registers, the apparatus may instead provide hint control circuitry provided in association with the decoding circuitry, with that hint control circuitry being used to store the hint metadata and to then determine when to trigger each of the one or more performance measures. Hence, in accordance with such an approach, the metadata is maintained close to the decoding circuitry, rather than directly in association with the registers referenced by the data processing circuitry when performing the required data processing operations.

[0041] In accordance with one particular example of such an approach, where at least one of the performance measures is implemented in association with performing one or more data processing operations defined by one or more given instructions that access a given register identified by the register identifying hint instruction, when the one or more given instructions is / are decoded the hint control circuitry may be arranged to cause at least one performance modifying control signal to be issued in association with one or more control signals generated by the decoding circuitry to identify the one or more data processing operations defined by the one or more given instructions. Then, when the data processing functional hardware performs the one or more data processing operations, the at least one performance modifying control signal can be used to trigger the at least one performance measure. Hence, in accordance with such an approach, performance modifying control signals can be used to supplement the usual control signals from the decoding circuitry, in order to trigger changes in the operating procedure of the data processing functional hardware so as to implement one or more performance measures in dependence on the hint metadata.

[0042] In accordance with one example implementation, multiple register identifying hint instructions can be utilised within program code. In that event, the decoding circuitry may thus be responsive to a further register identifying hint instruction to generate further hint metadata indicative of at least one register identified by the further register identifying hint instruction Depending on implementation, this further hint metadata may be arranged to supplement the earlier generated hint metadata, or alternatively may be arranged to replace that earlier generated hint metadata. In one particular example implementation, the register identifying hint instructions may be defined such that they always supplement any existing hint metadata generated by previous register identifying hint instructions, and other mechanisms (as will be discussed in more detail later) are used to clear existing hint metadata when it is no longer required. In addition, it should be noted that the further register identifying hint instruction may be a different variant of register identifying hint instruction to the earlier mentioned register identifying hint instruction (for example it may specify a different type of hint metadata), or alternatively may merely be another instance of the same variant of register identifying hint instruction.

[0043] As an alternative to defining the register identifying hint instructions as always generating hint metadata that supplements any existing hint metadata, or indeed defining the hint instructions so that any newly generated hint metadata always overwrites previously generated hint metadata, such behaviour can be made configurable through the use of an append flag. In particular, in one example implementation, when the further register identifying hint instruction incorporates an append flag, the further hint metadata is arranged to supplement the existing hint metadata, whilst in the absence of the append flag the generation of the further hint metadata causes the existing hint metadata to be cleared (at least in respect of the register or registers identified by the further register identifying hint instruction). Such an approach can provide a great deal of flexibility, allowing complex combinations of hint metadata to be established through the execution of multiple register identifying hint instructions, but also in some instances (when the append flag is not present) allowing certain hint metadata to be cleared without requiring any additional explicit action to be taken to clear that hint metadata.

[0044] In one example implementation, a register hint clear instruction is also provided in the instruction set architecture. The decoding circuitry is then responsive to an instance of such a register hint clear instruction to clear the hint metadata associated with each register identified by the register hint clear instruction. This hence provides an explicit mechanism for invalidating hint metadata when it should no longer be used. This can for example be particularly useful in implementations where the default position adopted is for any further generated hint metadata to supplement existing hint metadata, since it provides a separate mechanism for removing hint metadata when it is no longer needed / appropriate.

[0045] In one example implementation, the register hint clear instruction may be a clear all instruction that causes all existing hint metadata to be cleared. In one particular example implementation, such a register hint clear instruction might be restricted to a particular class of registers, for example to clear hint information associated with all vector registers whilst leaving hint information associated with nonvector registers untouched

[0046] As an alternative to using the above-mentioned register hint clear instructions, or in addition thereto, in one example implementation the hint metadata associated with at least a given register may be cleared in response to detection of one or more events. The types of events that could be used for this purpose may vary dependent on a variety of factors, including for example the type of hint information provided by the hint metadata. However, by way of example, such an event may be detected in response to execution of an instruction of a predetermined type that causes at least a given type of access to be performed to the given register. Considering by way of specific example the non-temporal hint form of hint metadata discussed earlier, this hint may be used in association with memory access instructions that use the value in the identified (given) register as a pointer. However, the number of instructions that are suitable for performing pointer arithmetic may typically be quite limited and there may be other instructions that are executed that are not suitable for pointer arithmetic. When a register that has previously been identified as having non-temporal hint metadata associated with it is then used as the destination for such an instruction (i.e. an instruction that cannot be used for pointer arithmetic), this implicitly means that the register in question will no longer contain a pointer after that instruction has been executed. Hence, execution of that instruction could be considered an example of the above-mentioned “event”, and could cause automatic clearing of the non-temporal hint flag of the destination register, and therefore remove the need for the use of a nontemporal hint clearing instruction in such instances.

[0047] The above is merely one example of an event that could result in the automatic clearing of certain hint metadata, but there are a variety of other events that could also be used for a similar purpose. Purely by way of example, the taking of an exception could be used to trigger clearing of hint metadata. In particular, in one example implementation it is not considered appropriate to maintain hint information when taking an exception, and hence when an exception is taken by the data processing circuitry, any existing hint metadata could be automatically cleared. Instead, in the event that an exception is taken (for example due to an interrupt occurring) between execution of the register identifying hint instruction and execution of the instructions that the resultant hint metadata applies to, the processing circuitry can be arranged to just discard the hint information (such hint information can merely be maintained as micro-architectural state rather than architectural state, and hence is not state that would be saved prior to taking such an exception, and later restored on return from the exception) on taking the exception, and will then just execute the instructions normally (without the associated hint metadata) when a return from the exception takes place.

[0048] As a yet further example, the apparatus could be arranged such that hint metadata is cleared on a transition between different software functions, if it is desired to limit the use of hint metadata to instructions executed by a particular software function. In one example implementation this may be done by clearing the hint metadata in response to the processing circuitry executing the type of branch instruction(s) typically used for function calls. Such an implementation may also clear the metadata in response to the type of branch instruction(s) typically used to perform a function return. However, in other implementations, if desired, the transition between different software functions may not be viewed as such an event, and instead hint metadata may be maintained between different software functions if that were considered appropriate.

[0049] As a still further example of an event that may cause hint metadata to be cleared, identification of an end of a loop for which the hint metadata is intended to be used could be used to trigger the clearing of the associated hint metadata. There are various ways in which the detection of the end of the loop may occur but, by way of one specific example, this may occur on detecting execution of a particular instruction that terminates the loop in question.

[0050] By allowing events such as those discussed above to automatically clear certain hint metadata, this can reduce the requirement for the use of hint clearing instructions, thus improving code density and thereby improving performance and energy consumption.

[0051] Whilst in one example implementation the register identifying hint instruction may be used merely to generate hint metadata of a particular type, in other example implementations the register identifying hint instruction may be able to generate hint metadata of different types. In such instances the register identifying hint instruction may specify a hint type. This can be done in a variety of ways, for example by providing different variants of the register identifying hint instruction for each hint type, or by including a field within the register identifying hint instruction that is used to specify the hint type. In situations where a field is provided for specifying the hint type, then in one example implementation the register identifying hint instruction may comprise a hint type vector that identifies which of plural hint types the hint metadata is to be generated for. For example, a single bit may be provided within the hint type vector for each possible hint type, with the setting or clearing of that bit indicating whether the register identifying hint instruction is to be used to generate hint metadata of that type or not.

[0052] In one such example use case, the identified register(s) will be associated with each of the hint types identified by the hint type vector. However, in an alternative implementation it may be possible, for each hint type specified in the hint type vector, for the register identifying hint instruction to identify one or more registers to be associated with that hint type. Hence, different registers could be associated with different hint types within the same single instruction. This could for example be possible in situations where sufficient instruction encoding space was available to encode that level of information within a single instruction.

[0053] The various types of hint that may be supported may vary dependent on implementation. As discussed earlier, one type of hint would be a non-temporal hint, identifying that the data in the identified register is likely to be used only once, or a few times, and hence if stored in a cache structure could be marked for eviction earlier than it might otherwise be Such a non-temporal hint may also trigger prefetching of the data in question, since the non-temporal hint could also be viewed as implying that the data will be accessed soon. However, as another hint type, a prefetch hint may be provided to specifically identify that the data associated with the identified register should be prefetched. This could for example be used in respect of data that is likely to be accessed soon, but also (in contrast to non-temporal data) is likely to be accessed repeatedly.

[0054] As another example of the type of hint metadata that could be supported, the execution of the register identifying hint instruction may be used to provide a hint as to the value stored in the identified register. Use of such a hint might for example influence branch prediction mechanisms, for instance by enabling a more likely branch path to be distinguished from a less likely branch path (for instance if which path is taken is dependent on whether the value in a given register matches a particular value, for example a 0 value, and the hint metadata indicates that the expected value in that given register is indeed a 0 value).

[0055] As a yet further example of the type of hint metadata that could be supported, the execution of the register identifying hint instruction may be used to provide a branch hint which could for example indicate that the value stored in the identified register contains a function pointer, i.e. will be used to identify an address of a function that may be branched to upon encountering a subsequent branch instruction. Such a branch instruction (that uses a value in a register to work out where to branch to) may be referred to as an indirect branch instruction, and it can be difficult to use branch prediction mechanisms to improve performance in the presence of indirect branches (for example, a branch prediction mechanism may be able to predict that the branch will be taken, but that may not allow prefetching of the required instructions if the address to be accessed cannot be determined). However, by using such a branch hint in association with a given register, the branch predictor is provided with a hint to prefetch instructions from the address identified in the given register. If in due course an indirect branch instruction is indeed encountered that identifies the given register as containing an address indication used to identify where to branch to, then if the branch predictor predicts that branch is taken those prefetched instructions can start to be used, thereby improving performance.

[0056] There are many other examples of hint metadata that could be generated, that may be used to modify the manner in which the data processing functional hardware operates. For instance the hint metadata could be used to modify a manner in which at least one of: caching; prefetching; branch prediction; decode width selection; instruction caching; atomic memory transacting; and memory transaction order constraining is carried out in the apparatus in the modified operating procedure with respect to the operating procedure.

[0057] In one example implementation the hint metadata associated with a given register is maintained irrespective of whether a value stored in the given register is modified. Hence, in such instances the hint metadata is considered to be associated with the register rather than the content of that register. However, if desired, in an alternative example implementation the apparatus may be arranged to clear hint metadata associated with the given register when the content of that register is altered. In one example implementation the plurality of registers may comprise registers of multiple types. In such an implementation, an encoding of the register identifying hint instruction may be arranged to indicate a register type of the at least one register This allows hint metadata to be generated for registers of a particular type. There are various ways in which the register type can be encoded within the instruction. For example, multiple different register identifying hint instructions could be provided, one for each type of register. Alternatively a field may be provided within the register identifying hint instruction that can be used to specify the register type.

[0058] Particular example implementations will now be discussed with reference to the accompanying figures.

[0059] Figure 1 illustrates a data processing apparatus 100 in accordance with one example implementation. This apparatus 100 is schematically illustrated as comprising execution circuitry 102, which will be recognised as the component of the apparatus which will execute the instructions provided to it by the apparatus programmer. It will further be recognised by one of ordinary skill in the art that, merely for the purposes of clarity, the components of the apparatus 100 are only shown schematically and at a relatively gross level of detail, with one of ordinary skill in the art being familiar with the many different ways in which components of a data processing apparatus such as execution circuitry 102 might be configured. Accordingly, further detail of the configuration of such components is dispensed with here for brevity. Nevertheless, as shown in Figure 1 , the execution circuitry 102 is shown to comprise control circuitry 104 which maintains overall control of the execution circuitry 102, as well as an instance of ALU circuitry 106 (arithmetic logic unit) The ALU circuitry 104 is provided here as an example of data processing functional hardware within the execution circuitry 102, but one of ordinary skill in the art will be familiar with many different varieties of data processing functional hardware which may form part of execution circuitry 102. The ALU 106 performs its data processing operations with respect to data values held in the registers 108. Further, the content of the registers 108 are loaded from and stored to storage outside the execution circuitry by means of the load / store circuitry 110. Data values may be temporarily cached in the data cache 112 (which may in fact comprise a hierarchy of data cache levels), whilst long term storage for the data values is provided by the memory 114.

[0060] The memory 114 is also the storage location for the data processing instructions which the apparatus programmer provides to configure the data processing operations which the apparatus should carry out. These instructions are retrieved from the memory by means of the fetch circuitry 118, and may be cached in instruction cache 116 (which may in fact be a hierarchy of instruction caches). Typically the fetch circuitry 118 retrieves instructions from memory 114 in sequence, the current instruction of the instructions being identified by a program counter (PC) value provided to it by program counter circuitry 124. However, in addition, the activities of the fetch circuitry 118 may be influenced by branch prediction circuitry 128, which as will be understood by those of ordinary skill in the art can be used to seek to provide a prediction as to the outcome of certain branch instructions, such as whether the branches will be taken or not taken. In the event that a branch is predicted as taken, the branch prediction circuitry may be able to identify a predicted target address to which the instruction flow will branch. Based on that information, the fetch circuitry 118 may then begin to fetch instructions from that predicted target address.

[0061] Instructions retrieved from the instruction cache 116 or the memory 114 may be temporarily buffered in an instruction buffer 120 before being decoded by decoding circuitry 122. The instructions retrieved by the fetch circuitry 118 and decoded by the decoding circuitry 122 specify the data processing operations which are carried out by the execution circuity 102, and indeed can control the operation of any other instruction-configurable component of the apparatus 100. This control is mediated between the decoding circuitry 122 and the execution circuitry 102 by control signals and it should be noted that these control signals may also control other instruction-configurable components of the apparatus 100 and Figure 1 illustrates the example of these control signals also potentially being received by the load / store circuitry 110, instruction cache 116, and the data cache 112.

[0062] As discussed earlier, the present techniques provide a register identifying hint instruction which the programmer of the apparatus can introduce into the sequence of data processing instructions to be executed by the apparatus. Such an instruction will identify at least one register, and when that instruction is decoded by the decoding circuitry 122 it will result in the generation of hint metadata. When using an apparatus of the form described in Figure 1 , that generated hint metadata is forwarded to the execution circuitry along with associated control signals, identifying an action to be taken by hint metadata processing circuitry 109 in order to execute the register identifying hint instruction. In particular, as shown in Figure 1 , hint metadata storage 111 may be provided in association with the registers 108, and the hint metadata processing circuitry 109 is arranged to store the generated hint metadata in association with the relevant register or registers. The hint metadata storage 111 may be a separate storage structure to the storage structure providing the registers 108, or, as will be discussed later with reference to Figure 3, in one example implementation the storage structure providing the registers may have a metadata field associated with each register in which to place any hint metadata generated in association with that register.

[0063] As discussed earlier, when such hint metadata is stored within the hint metadata storage 111 , the presence of that hint metadata can be used to influence how the data processing functional hardware of the apparatus is operated, and in particular the apparatus may, in response to the control signals generated by the decoding circuitry 12 as a result of executing a given sequence of instructions, operate the data processing functional hardware in a modified operating procedure rather than a normal operating procedure that would be used in the absence of such hint metadata. The modified operating procedure differs from the normal operating procedure by implementing one or more performance measures in dependence on the hint metadata. As shown schematically in Figure 1 , when operating the data processing functional hardware in the modified operating procedure, various performance modifying control signals may be propagated within the apparatus in order to trigger the associated performance measures.

[0064] A wide variety of different performance measures may be implemented, and indeed the timing at which those performance measures take place may vary, dependent on the type of performance measure being implemented. However, purely by way of illustrative example, one form of hint metadata that may be generated may be referred to as a non-temporal hint, and if such a non-temporal hint is associated with a given register, this may trigger the implementation of a performance measure when the data held in that register is used in a particular way. In one particular example implementation, when the data held in given register is used as a pointer for a memory access operation, then the accessed data may be flagged as being non-temporal. This may allow an improvement in the overall performance of the apparatus, by allowing the data cache(s) to be used more efficiently, since such data marked as being non-temporal can be allowed to be evicted more promptly from the cache than might otherwise be the case, thereby increasing the likelihood that data that will be reused is retained within the cache.

[0065] As another example of hint metadata that may be generated, a prefetch hint may be generated in association with a given register, to identify that the data to be used by one or more subsequent instructions that reference that given register should be prefetched into a cache to improve performance when those one or more subsequent instructions are actually executed. Such prefetching activity can be implemented before those instructions are executed. As a result of such prefetching, it is expected that the overall performance of the apparatus will be improved.

[0066] As another example of the type of hint metadata that could be supported, a data value hint could be generated for association with the given register, to provide a hint as to the value stored in that given register. Use of such a data value hint could be used in a variety of ways. Purely by way of example, such a data value hint might influence branch prediction mechanisms, for example by enabling a more likely branch path to be distinguished from a less likely branch path (for instance if which path is taken is dependent on whether the value in a given register matches a particular value, for example a 0 value, and the hint metadata indicates that the expected value in that given register is indeed a 0 value).

[0067] As a yet further example of the type of hint metadata that could be supported, a branch hint could be generated for associating with a given register. This could for example be used to indicate that the value stored in the given register contains a function pointer, i.e. will be used to identify an address of a function that may be branched to upon encountering a subsequent indirect branch instruction. By using such a branch hint, the branch prediction circuitry 128 is provided with a hint to cause instructions to be prefetched starting from the address identified in the given register. If in due course an indirect branch instruction is indeed encountered that identifies the given register as containing an address indication used to identify where to branch to, then if the branch predictor predicts that branch is taken those prefetched instructions can start to be used, thereby improving performance.

[0068] An important point to appreciate here is that irrespective of whether or not hint metadata is present, and hence irrespective of whether one or more performance modifying control signals are asserted in order to implement one or more associated performance measures, whilst this may modify the manner in which the data processing operations defined by data processing instructions are carried out, this will not change the data processing results of those data processing operations. In other words, the data processing results which are produced as a consequence of the data processing instructions (other than the hint instruction) which the decoding circuitry receives do not change in dependence on whether hint metadata has been generated. The data processing results thus remain the same (dependent only on the data processing instructions received and the data values to which those instructions refer).

[0069] In addition to the earlier mentioned register identifying hint instruction, the sequence of instructions may also include one or more instances of a register hint clear instruction. This can result in the generation of control signals sent to the hint metadata processing circuitry 109 to cause it to update the hint metadata stored in the hint metadata storage 11 1 , in particular by clearing one or more existing items of hint metadata. The register hint clear instruction may for example identify one or more registers, resulting in hint metadata associated with those registers being cleared, or may alternatively take the form of a “clear all” register hint clear instruction that could for example cause all existing hint metadata stored in the hint metadata storage 111 to be cleared. In instances where multiple different types of hint metadata are supported, the register hint clear instructions could identify type information, such that the clearing activities are restricted to one or more given types of hint metadata.

[0070] Figure 2 schematically illustrates an apparatus 100’ in accordance with an alternative example implementation. In this example, rather than providing hint metadata processing circuitry 109 and associated hint metadata storage 111 within the execution circuitry 102, a hint control unit 126 (also referred to herein as hint control circuitry) is provided in association with the decoding circuitry 122. The hint control unit can be arranged to receive information about the decoding operations of the decoding circuitry 122, and when that information provides hint metadata resulting from the decoding of a register identifying hint instruction, it can be arranged to store that hint metadata for future reference. When that information relates to another instruction, it can then check whether it would be appropriate to trigger a performance measure based on the stored hint metadata, for example due to such an instruction referencing a register for which hint metadata has been stored. When it is determined that a performance measure should be initiated, the hint control unit 126 can notify the decoding circuitry 12 accordingly, so that performance modifying control signals can be issued by the decoding circuitry 12 in association with the other control signals issued by the decoding circuitry. It should be appreciated that the “control signals” and the “performance modifying control signals” which the decoding circuitry asserts may all be considered as a variety of “control signal”, but are given these distinct labels here to facilitate the present discussion.

[0071] Further, when a register hint clear instruction is decoded by the decoding circuitry 122, this may cause control signals to be sent to the hint control unit 126 to cause it to clear certain items of hint metadata stored therein, so that thereafter performance measures are not triggered by that cleared hint metadata.

[0072] Figure 3 schematically illustrates how the hint metadata processing circuitry 109 of Figure 1 may be used. In this example, it is assumed that the hint metadata storage 111 is implemented within the set of registers 108, by providing a metadata field 150 in association with each register. As a result, the register will have a data field in which the data value currently held by that register is stored, and the associated metadata field 150 can be selectively populated by the hint metadata processing circuitry 109 in dependence on register identifying hint instructions or register hint clear instructions. Hence, when a register identifying hint instruction is decoded that identifies a given register, the hint metadata generated can be passed to the hint metadata processing circuitry 109, for storage within the metadata field 150 associated with that given register. Similarly, if a register hint clear instruction is decoded that identifies that the hint metadata associated with that given register (or at least one or more types of hint metadata associated with that given register) should be cleared, then the hint metadata processing circuitry 109 can be arranged to delete that identified hint metadata from the metadata field 150 associated with the given register.

[0073] Figure 4 is a block diagram illustrating components that may be provided within the hint control unit 126 of Figure 2, in accordance with one example implementation. Hint metadata storage 166 is provided, and the hint control unit is responsive to receiving hint information from the decoding circuitry 122 generated in response to the decoding of a register identifying hint instruction to cause that hint information to be stored within the hint metadata storage. The hint metadata storage 166 can be arranged in a variety of ways, but irrespective of how it is constructed will associate each item of stored hint metadata with the register to which that item of hint metadata relates. In some example embodiments that only support a single type of hint, the hint type is implicit and may not need to be stored in the metadata storage 166. In such embodiments the metadata storage 166 may only store a list of registers that the hint is associated with. When the hint control unit receives control signals from the decoding circuitry 122 generated in response to decoding a register hint clear instruction, it will then update the hint metadata storage 166 accordingly, and in particular will clear one or more items of hint metadata in dependence on the control signals received from the decoding circuitry 122.

[0074] The hint control unit 126 also comprises control circuitry 160 which is arranged to determine when one or more performance measures should be triggered, and will trigger any such performance measures by issuing one or more performance modifying control signals back to the decoding circuitry 122 for propagation on to other components of the apparatus in association with the normal control signals generated by the decoding circuitry 122 as a result of decoding the stream of fetched instructions.

[0075] As shown in Figure 4, the control circuitry 160 may comprise hint match detection circuitry 162 which, on receipt of certain information from the decoding circuitry 122 indicative of instructions that have been decoded, is arranged to reference the hint metadata storage 166 in order to determine whether a hint match has been detected. Purely by way of illustration, considering the earlier example of a non-temporal hint associated with a given register, if the information received in respect of a decoded instruction indicates that that instruction is a memory access instruction, and is using the data in the given register as a pointer, then it may be determined that a hint match has been detected, and at that point the hint match detection circuitry can inform the performance measure triggering circuitry 164, in order to cause the appropriate performance modifying control signal(s) to be generated.

[0076] It should be noted that the performance measure triggering circuitry 164 may not necessarily only respond to signals from the hint match detection circuitry 162. For example, considering the earlier example of a prefetch hint, the performance measure triggering circuitry 164 may respond to the contents of the hint metadata storage 166 to issue one or more performance modifying control signals to initiate prefetch activity in order to cause certain data to be prefetched into the cache in anticipation of a subsequent instruction requesting access to that data, and hence the presence of the hint information in the hint metadata storage may be sufficient in that case to trigger the performance measure.

[0077] Figure 5 is a flow diagram indicating steps that may be performed in response to hint metadata being generated as a result of decoding a register identifying hint instruction. If at step 200 it is determined that such hint metadata has been generated, then at step 205 that hint metadata will be stored within the apparatus for future reference. In the example of Figure 1 , this is achieved by the hint metadata processing circuitry 109 storing that hint metadata within the hint metadata storage 111 associated with the registers 108, whilst in the example of Figure 2 this is achieved by the hint control unit 126 causing that hint metadata to be stored within the hint metadata storage 166.

[0078] At step 210, it is then determined whether the hint type associated with that hint metadata is such that a performance measure can be implemented at that point in time, and if so at step 215 the performance measure is triggered by issuing one or more performance modifying control signals to the appropriate component of the apparatus. As an example, the earlier mentioned prefetch hint may result in such performance modifying control signals being issued to prefetch circuitry associated with one or more data caches 112, in order to initiate prefetching of certain data into that data cache.

[0079] However, if the hint type is such that a performance measure is not to be initiated straightaway, but instead that hint metadata will be useful at a subsequent point in time, for example when a downstream instruction within the sequence is decoded for execution, then the process will proceed to step 220 in order to await a later trigger of a performance measure when a triggering event occurs. As shown in Figure 5, step 220 will also be reached following step 215 in some implementations, since even if a performance measure is triggered at step 215 based on the hint metadata stored at step 205, it may be the case that one or more further performance measures will also be triggered at a later point in time based on that hint metadata. It will be appreciated by one of ordinary skill in the art the performance measures triggered at steps 215 and 220 may be the same, or it may be appropriate to trigger different performance measures in these two cases.

[0080] Figure 6 is a flow diagram illustrating steps that may be performed to implement step 220 of Figure 5, and in particular represents an example of a later trigger that may occur based on stored hint metadata. At step 250, it is determined whether an instruction has been decoded by the decoding circuitry 122, and if so at step 255 it is determined whether execution of the instruction will cause a register to be accessed for which hint metadata is provided. This determination can be made at a variety of locations within the apparatus, dependent on the particular implementation. For example, when adopting the approach of Figure 1 , the hint metadata processing circuitry 109 may, in response to control signals received from the decoding circuitry 122 relating to the decoded instruction, access the hint metadata storage 111 in order to determine whether there is hint metadata stored in association with one or more of the registers to be accessed when executing that decoded instruction. Alternatively, when adopting the approach of Figures 2 and 3, the hint match detection circuitry 162 forming part of the control circuitry 160 within the hint control unit 126 may be arranged to make that determination, with reference to the contents of the hint metadata storage 166.

[0081] If it is determined that execution of the instruction will not cause a register to be accessed for which hint metadata is provided, then the process proceeds to step 265 where the data processing operation required by the instruction is performed in the usual manner by the appropriate data processing functional hardware within the execution circuitry 102. Once the execution of the instruction has been completed the process proceeds back to step 250 to await the next instruction to be executed. However, if it is determined that execution of the instruction will cause a register to be accessed for which there is associated hint metadata, it is determined at step 260 whether any other qualifying conditions for triggering a performance measure are met. These conditions may take a variety of forms. However, considering the earlier discussed non-temporal hint, such conditions may involve determining whether the register is used in a particular way (in particular, for the non-temporal hint example, whether the data value in the register is used as a pointer), and whether the instruction is of a particular type (in particular, for the non-temporal hint example, whether the instruction is a memory access instruction).

[0082] If any other qualifying conditions for triggering the performance measure are not met, then the process proceeds to step 265, where the required data processing operation is performed as normal. However, if any other qualifying conditions are met, then the process proceeds to step 270, where, in addition to performing the required data processing operation, implementation of an appropriate performance measure is triggered (as discussed earlier the performance measure may be dependent on the form of hint metadata in question). Once the execution of the instruction has been completed with the appropriate performance measure, the process proceeds back to step 250 to await the next instruction to be executed.

[0083] Figure 7A schematically illustrates an encoding of the register identifying hint instruction in one example implementation. In this case, the encoding 300 includes an opcode portion 302 that will identify the instruction as being a register identifying hint instruction, and a register identifier field 306 for identifying one or more registers. In implementations that allow different forms of hint, then a hint type field 304 can be used to identify the type of hint to which the hint instruction relates, and hence will define the form of hint metadata that is to be stored in association with each register identified in the field 306. In some instances, there may be more than one type of register provided within the apparatus, for example one set of registers for storing data of one size, and another set of registers for storing data of another size, and / or different sets of registers for storing different forms of data value (for example scalar values or vector values). In such cases, if desired, a register type field 308 may be provided to identify which register type hint metadata is to be generated for, the register type information being used in combination with the register identifier field information to identify the particular register or registers. In another example implementation, there may be no register type field 308, but instead different variants of the register identifying hint instruction may be provided for the different register types, and as a result the opcode field 302 will specify which variant of the register identifying hint instruction is being defined.

[0084] In one example implementation, it may be the case that any newly generated hint metadata for a given register supplements any existing hint metadata stored for that given register, or indeed in another example implementation it may be the case that such newly generated hint metadata always replaces any existing hint metadata stored for the given register thus causing any existing hint metadata to be deleted. However, in a further alternative implementation, an append flag field 310 may be provided and the value of that field may determine whether the generated hint metadata supplements or replaces any existing hint metadata for the register(s) in question. Hence, if the append flag is set (also referred to herein as the append flag being present), the generated hint metadata that is stored when the hint instruction is executed may supplement any existing hint metadata for the register(s) in question, whereas if the append flag is clear (also referred to herein as the append flag being absent) the newly generated hint metadata will replace any existing hint metadata for the register(s) in question. In some alternative examples if the append flag is clear, the newly generated hint metadata may replace all existing hint metadata, regardless of which register it is associated with. This provides a great deal of flexibility in how the register identifying hint instructions are used, and can for example be used in some instances to clear out of date hint metadata without needing to explicitly issue any further instruction to clear that hint metadata.

[0085] Figure 7B illustrates another alternative example encoding of the register identifying hint instruction. In accordance with this encoding 320, an opcode field 322 is provided to identify the instruction, and a hint type vector field 324 is provided to identify one or more types of hint metadata that are to be generated when executing this instruction. For example, the hint type vector may include a bit for each supported hint type, and setting of a bit within the hint type vector will identify that hint metadata of that type is to be generated when the instruction is executed. A register identifier field 326 is then provided to identify the registers with which the generated hint metadata should be associated. In one example implementation, for any one given instance of the instruction, the generated hint metadata will be the same for all the register identifiers specified in 326. However, in another example implementation, the hint type vector 324 may be expanded to allow one or more hints to be defined independently for each of the registers indicated by the register identifiers 326.

[0086] As with the example of Figure 7A, a register type field 328 may be provided, or alternatively different variants of instruction may be defined dependent on the register type for which hint metadata is to be generated. Also, as with the example of Figure 7A, an append flag field 330 can be provided if desired, to allow the generated hint metadata to either supplement any existing hint metadata for the register(s) in question or to overwrite any such existing hint metadata.

[0087] Even in situations where the append flag is provided, it can be useful to provide other mechanisms for clearing existing hint metadata. For instance, it may be desired to invalidate some existing hint metadata for one or more registers without necessarily setting any new hint metadata for those one or more registers. In one example implementation, the instruction set is arranged to include a register hint clear instruction, and Figure 8A schematically illustrates fields that may be provided within such an instruction in accordance with one example encoding. In accordance with this encoding 340, an opcode field 342 is used to define the instruction as being a register hint clear instruction, and, assuming more than one hint type is supported by the apparatus, a hint type field 344 may be provided to identify which hint type the register hint clear instruction relates to. In the example of Figure 8A, the register hint clear instruction will cause all hint metadata of the specified type to be invalidated, and hence will include a clear all indicator 346 (while this is shown as a separate field for clarity in Figure 8A, it will be appreciated that this information could form part of the opcode encoding in field 342 if desired). Hence, when the register hint clear instruction in accordance with the encoding 340 is executed, any hint metadata of the hint type indicated in the field 344 associated with any of the registers will be cleared. Alternatively in some embodiments the hint type field 344 may not be provided and the hint clear instruction may clear hints of all types.

[0088] Figure 8B illustrates another example encoding 350 of the register hint clear instruction, which again includes an opcode field 355 to identify the instruction, and a hint type field 354 to identify the hint type to which instruction relates. In this case, the field 356 is used as a register identifier field to identify one or more registers whose hint metadata of the associated hint type should be cleared. As with the example shown in Figure 8A the hint type field 354 may not be provided and alternatively the hint clear instruction may clear all types of hint information associated with the registers specified by the register identifiers 356.

[0089] As with the example of the register identifying hint instructions, different variants of the register hint clear instruction shown in Figure 8A or Figure 8B could be specified for different register types, so as to only clear the hint metadata for registers of the identified register type. Further, whilst in the example shown in Figures 8A and 8B the register hint clear instructions are restricted to hint metadata of a particular type, as noted above, if desired, other variants of the instruction could be specified that clear the hint metadata for the identified registers (or all registers) irrespective of the hint type. As a yet further variant, in an analogous way to the register identifying hint instruction of Figure 7B, the hint type field 344, 354 of Figures 8A and 8B could be replaced by a hint type vector field to allow more than one hint type to be identified by the instructions, such that hint metadata of each set hint type indicated by the hint type vector will then be cleared for the relevant register or registers. In some examples the clear all hint instruction in Figure 8A may be encoded as a variant of the hint clear instruction shown in Figure 8B. For example setting the register identifier field 356 to an otherwise invalid value could be used to signify that the hint information for all registers should be cleared.

[0090] Figure 9 is a flow diagram illustrating steps performed upon decoding a register identifying hint instruction in accordance with one example implementation where the earlier discussed append flag is provided. When such an instruction is decoded at step 400, then at step 405 it is determined whether hint metadata is already active for the register or registers identified by the register identifying hint instruction. If not, then the process proceeds to step 410 where the hint metadata generated from the decoded instruction is stored. However, if it is determined at step 405 that there is already existing hint metadata, it is then determined at step 415 whether the append flag is set, and if so the process proceeds to step 410. However if the append flag is not set, then at step 420 the currently active hint metadata for the register or registers in question is cleared, and the newly generated hint metadata produced as a result of the decoded instruction is stored to replace that earlier hint metadata. In some examples, when the append flag is clear, step 420 will clear the existing hint metadata for all of the registers, and therefore all hint metadata will be replaced by the new metadata generated from the hint instruction.

[0091] Figure 10 is a flow diagram illustrating steps performed upon decoding a register hint clear instruction, in accordance with one example implementation. When such an instruction is decoded at step 450, it is determined at step 455 whether the variant of register hint clear instruction is a clear all variant If so, the process proceeds to step 465 where all existing hint metadata is cleared (as discussed earlier the clearing may be restricted to particular hint types, and / or to hint metadata associated with particular register types). If it is determined at step 455 that the clear all variant of the register hint clear instruction is not being used, at step 460 the hint metadata for each register identified by the hint clear instruction is cleared. Again, the hint metadata cleared may be restricted to one or more particular hint types and / or to hint metadata associated with particular register types.

[0092] As an alternative to using the above-mentioned register hint clear instructions, or in addition thereto, in one example implementation the hint metadata associated with at least a given register may be cleared in response to detection of one or more events This is illustrated schematically in Figure 11 . Hence, if at step 470 an event is detected that is interpreted as giving an implicit hint clear indication then the hint metadata that the event infers should no longer be valid is cleared at step 475. As discussed earlier, the types of events that could be used for this purpose may vary dependent on a variety of factors, including for example the type of hint information provided by the hint metadata. However, purely by way of one specific example, and considering the earlier mentioned non-temporal hint, such a non-temporal hint may be used in association with memory access instructions that use the value in a given register as a pointer. However, the number of instructions that are suitable for performing pointer arithmetic may typically be quite limited and there may be other instructions that are executed that are not suitable for pointer arithmetic. When a register that has previously been identified as having non-temporal hint metadata associated with it is then used as the destination for such an instruction (i.e. an instruction that cannot be used for pointer arithmetic), this implicitly means that the register in question will no longer contain a pointer after that instruction has been executed. Hence, execution of that instruction could be considered an example of the above-mentioned “event”, and could cause automatic clearing of the non-temporal hint flag of the destination register, and therefore remove the need for the use of a non-temporal hint clearing instruction in such instances.

[0093] The following example instruction sequences are provided merely to illustrate ways in which the register identifying hint instructions defined herein may be used. In the following examples the register identifying hint instruction is assumed to generate a non-temporal hint and is referred to as an NTHINTSET instruction. Similarly, where used, the earlier described register hint clear instruction is referred to as an NTHINTCLR instruction.

[0094] Example sequence 1

[0095] NTHINTSET R2 / / Mark R2 and R3 as non-temporal pointers

[0096] NTHINTSET R3

[0097] LDR RO, [R2] / / R2 used as pointer, marked as non-temporal

[0098] STR R1, [R4] / / R4 not a non-temporal pointer, STR is not non-temporal

[0099] STR R1, [R4, R2] / / R2 used as offset, not pointer, STR not marked as non-temporal

[0100] STR R8, [R3] / / R3 used as pointer, marked as non-temporal The hint information will stay active until cleared, and hence, when used in association with a loop, can be arranged to remain active for multiple iterations of that loop. In one example arrangement, the hint instruction could be positioned above a loop and be used to annotate the instructions within the loop, which would avoid the per iteration overhead of executing such a hint instruction if it were included within the body of the loop. When the register is reused (e g. after a loop) the hint information can be cleared if desired, as indicated by the following example instruction sequence

[0101] Example sequence 2

[0102] NTHINTSET R2

[0103] LoopStart:

[0104] LDR RO, [R2] / / R2 used as pointer, marked as non-temporal

[0105] STR R1 , [R4] / / R4 not a non-temporal pointer, STR is not non-temporal

[0106] <other instructions>

[0107] CMP

[0108] BNE LoopStart

[0109] NTHINTCLR R2

[0110] LDR RO, [R2] / / R2 no longer a non-temporal pointer, not marked as

[0111] / / non-temporal load

[0112] As noted earlier, only a relatively small number of instructions are suitable for performing pointer arithmetic. For example, considering the Arm instructions developed by Arm Limited, Cambridge, United Kingdom, the DSP instructions that do SIMD (single instruction multiple data) operations in the R registers are not suitable for pointer arithmetic. Using a register as the destination for an instruction that cannot be used for pointer arithmetic implicitly means that that register no longer contains a pointer. Such an instruction could automatically clear the non-temporal hint flag of the destination register and therefore reduce the number of non-temporal hint clearing instructions required, as illustrated by way of example in the following instruction sequence.

[0113] NTHINTSET R2 / / Mark R2 as non-temporal pointer

[0114] NTHINTSET R3 / / Mark R3 as non-temporal pointer

[0115] LDR RO, [R2] / / R2 used as pointer, marked as non-temporal.

[0116] SSUB8 R2, RO, R1 / / SIMD DSP instruction that’s classed as hint clearing uses R2

[0117] / / as destination. R2 no longer marks loads as being

[0118] / / non-temporal.

[0119] MOV R9, R2 MOV R2, R6 / / Move new pointer into R2.

[0120] LDR RO, [R2] / / Not marked as non-temporal load

[0121] LDR RO, [R3] / / R3 used as pointer, still marked as non-temporal.

[0122] 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.

[0123] 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 system-level 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.

[0124] 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.

[0125] 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.

[0126] 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.

[0127] Figure 12 illustrates a simulator implementation that may be used. Whilst the earlier described embodiments implement the present invention in terms of apparatus and methods for operating specific processing hardware supporting the techniques concerned, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein which is implemented through the use of a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software based implementation of a hardware architecture. Varieties of simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 530, optionally running a host operating system 520, supporting the simulator program 510 In some arrangements, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations which execute at a reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a desire to run code native to another processor for compatibility or re-use reasons. For example, the simulator implementation may provide an instruction execution environment with additional functionality which is not supported by the host processor hardware, or provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USEN IX Conference, Pages 53 - 63.

[0128] To the extent that embodiments have previously been described with reference to particular hardware constructs or features, in a simulated embodiment, equivalent functionality may be provided by suitable software constructs or features. For example, particular circuitry may be implemented in a simulated embodiment as computer program logic. Similarly, memory hardware, such as a register or cache, may be implemented in a simulated embodiment as a software data structure. In arrangements where one or more of the hardware elements referenced in the previously described embodiments are present on the host hardware (for example, host processor 530), some simulated embodiments may make use of the host hardware, where suitable The simulator program 510 may be stored on a computer-readable storage medium (which may be a non-transitory medium), and provides a program interface (instruction execution environment) to the target code 500 (which may include applications, operating systems and a hypervisor) which is the same as the interface of the hardware architecture being modelled by the simulator program 510. Thus, the program instructions of the target code 500 described above may be executed from within the instruction execution environment using the simulator program 510, so that a host computer 530 which does not actually have the hardware features of the apparatus 100, 100’ discussed above can emulate these features.

[0129] The functions of the earlier described apparatus used to modify its operating procedure in dependence on hint metadata generated through execution of register identifying hint instructions can be emulated by corresponding program logic. By providing a simulation of the earlier described apparatus in a software form, this can allow debugging software for interacting with the apparatus to be developed before the hardware is actually available.

[0130] Hence, the simulator program 510 may have data processing program logic 512 which simulates the state of the execution circuitry 102 described above, and hence is arranged to simulate the data processing functional hardware. Instruction decoding program logic 514 decodes instructions of the target code 500 and maps these to corresponding sets of instructions in the native instruction set of the host apparatus 530. The register simulating program logic 513 maps register accesses requested by the target code to accesses to corresponding register-emulating data structures 533 (also referred to herein as simulated registers) maintained by the host hardware of the host apparatus 530, such as by accessing data in registers or memory 532 of the host apparatus 530.

[0131] 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.

[0132] In the present application, lists of features preceded with the phrase “at least one of’ mean that any one or more of those features can be provided either individually or in combination. For example, “at least one of: [A], [B] and [C]” encompasses any of the following options: A alone (without B or C), B alone (without A or C), C alone (without A or B), A and B in combination (without C), A and C in combination (without B), B and C in combination (without A), or A, B and C in combination.

[0133] 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 and modifications can be effected therein by one of ordinary skill in the art without departing from the scope of the invention as defined by the appended claims.

Claims

CLAIMS1. Apparatus comprising: decoding circuitry to decode instructions, wherein the decoding circuitry is responsive to a sequence of instructions to generate control signals; data processing circuitry comprising data processing functional hardware; and a plurality of registers; wherein the data processing circuitry is responsive to the control signals to operate the data processing functional hardware in an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in the plurality of registers, to produce data processing results; wherein: the decoding circuitry is responsive to a register identifying hint instruction preceding the sequence of instructions to generate hint metadata in dependence on at least one register identified by the register identifying hint instruction; the data processing circuitry is arranged, when the hint metadata is present, to be responsive to the control signals to operate the data processing functional hardware in a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results; and the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata.

2. An apparatus as claimed in Claim 1 , wherein at least one of the one or more performance measures is implemented in association with performing one or more data processing operations defined by one or more given instructions in the sequence of instructions that accesses a given register identified by the register identifying hint instruction.

3. An apparatus as claimed in Claim 2, wherein the one or more given instructions are instructions that use a value held in the given register in a predetermined manner.

4. An apparatus as claimed in Claim 2 or Claim 3, wherein the one or more given instructions are instructions of a predetermined type.

5. An apparatus as claimed in any preceding claim, wherein at least one of the one or more performance measures is implemented in response to generation of the hint metadata6. An apparatus as claimed in any preceding claim, further comprising: hint metadata storage associated with the plurality of registers; and hint metadata processing circuitry to store the hint metadata in the hint metadata storage; wherein the data processing circuitry is arranged to access the hint metadata storage in order to determine, for a specified register, whether that specified register has hint metadata associated therewith.

7. An apparatus as claimed in Claim 6, wherein the hint metadata storage comprises a metadata field provided for each register, into which any associated hint metadata is stored by the hint metadata processing circuitry.

8. An apparatus as claimed in Claim 6 or Claim 7 when dependent on claim 2, wherein when the data processing functional hardware performs the one or more data processing operations defined by the one or more given instructions, the one or more given instructions identifying the given register causes the hint metadata for the given register to be accessed and the at least one performance measure to be implemented.

9. An apparatus as claimed in any of claims 1 to 5, further comprising hint control circuitry provided in association with the decoding circuitry to store the hint metadata, and to determine when to trigger each of the one or more performance measures.

10. An apparatus as claimed in Claim 9 when dependent on Claim 2, wherein: when the one or more given instructions is decoded, the hint control circuitry is arranged to cause at least one performance modifying control signal to be issued in association with one or more control signals generated by the decoding circuitry to identify the one or more data processing operations defined by the one or more given instructions; and when the data processing functional hardware performs the one or more data processing operations, the at least one performance modifying control signal triggers the at least one performance measure to be implemented.

11. An apparatus as claimed in any preceding claim, wherein the decoding circuitry is responsive to a further register identifying hint instruction to generate further hint metadata indicative of at least one register identified by the further register identifying hint instruction.

12. An apparatus as claimed in Claim 11 , wherein the further hint metadata is arranged to supplement the hint metadata.

13. An apparatus as claimed in Claim 11 , wherein when the further register identifying hint instruction incorporates an append flag, the further hint metadata is arranged to supplement the hint metadata, whilst in the absence of the append flag the generation of the further hint metadata causes the hint metadata to be cleared.

14. An apparatus as claimed in any preceding claim, wherein the decoding circuitry is responsive to a register hint clear instruction to clear the hint metadata associated with each register identified by the register hint clear instruction.

15. An apparatus as claimed in any preceding claim, wherein the decode circuitry is responsive to a register hint clear all instruction to clear all existing hint metadata.

16. An apparatus as claimed in any preceding claim, wherein the hint metadata associated with at least a given register is cleared in response to detection of one or more events.

17. An apparatus as claimed in Claim 16, wherein the one or more events comprise one or more of: taking of an exception; transition between different software functions; identification of an end of a loop for which the hint metadata is intended to be used; execution of an instruction of a predetermined type that causes at least a given type of access to be performed to the given register.

18. An apparatus as claimed in any preceding claim, wherein the register identifying hint instruction specifies a hint type.

19. An apparatus as claimed in Claim 18, wherein the register identifying hint instruction comprises a hint type vector identifying which of plural hint types the hint metadata is to be generated for.

20. An apparatus as claimed in Claim 19, wherein for each hint type specified in the hint type vector, the register identifying hint instruction is arranged to identify one or more registers to be associated with that hint type.21 . An apparatus as claimed in any preceding claim wherein the hint metadata associated with a given register is maintained irrespective of whether a value stored in the given register is modified.

22. An apparatus as claimed in any preceding claim, wherein the hint metadata for a given register is used to indicate that the given register is storing a value that will be used as a pointer to identify an address in memory, and the data processing circuitry is arranged when performing an access to memory in response to a memory access instruction that specifies the given register as a pointer, to mark the access as a non-temporal access.

23. An apparatus as claimed in any preceding claim, wherein: the plurality of registers comprise registers of multiple types; and an encoding of the register identifying hint instruction is arranged to indicate a register type of the at least one register.

24. A method of modifying an operating procedure of a data processing apparatus, comprising: decoding a sequence of instructions to generate control signals; operating data processing functional hardware, in response to the control signals, in an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in a plurality of registers, to produce data processing results; generating, in response to a register identifying hint instruction preceding the sequence of instructions, hint metadata in dependence on at least one register identified by the register identifying hint instruction; and when the hint metadata is present, operating the data processing functional hardware, in response to the control signals, in a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results, wherein the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata.

25. A computer program comprising instructions which, when executed by a host data processing apparatus, control the host data processing apparatus to provide an instruction execution environment for executing target program code, the computer program comprising: instruction decoding program logic to decode instructions, wherein the instruction decoding program logic is responsive to a sequence of instructions to generate control signals; data processing program logic to simulate data processing functional hardware; and register simulating program logic to maintain register emulating data structures to emulate a plurality of registers;wherein the data processing program logic is responsive to the control signals to operate according to an operating procedure to perform data processing operations defined by the sequence of instructions, using data stored in the register emulating data structures, to produce data processing results; wherein: the instruction decoding program logic is responsive to a register identifying hint instruction preceding the sequence of instructions to generate hint metadata in dependence on at least one register identified by the register identifying hint instruction; the data processing program logic is arranged, when the hint metadata is present, to be responsive to the control signals to operate according to a modified operating procedure to perform the data processing operations defined by the sequence of instructions to produce the data processing results; and the modified operating procedure differs from the operating procedure by implementing one or more performance measures in dependence on the hint metadata.

Images