Common architecture terms
The architecture uses a number of terms, usually written in small capital letters in documentation, which have very specific meanings. While the Arm Architecture Reference Manuals provide a full definition of each term, here we will look at the most common terms and what they mean to programmers.
PE Processing Element
Processing Element (PE) is a generic term for an implementation of the Arm architecture. You can think of a PE as anything that has its own program counter and can execute a program. For example, the Arm Architecture Reference Manual states:
The states that determine how a PE operates, including the current Exception level and security state, and in AArch32 state, the PE mode.
Manuals use the generic term PE because there are many different potential micro-architectures. For example, the following micro-architectures are possible in the Arm Cortex-A processors:
- Cortex-A8 is a single core, single-thread processor. The entire processor is a PE.
- Cortex-A53 is a multi-core processor, each core is a single thread. Each core is a PE.
is a multi-core processor, each core has two threads. Each thread is a PE.
By using the term PE, the architecture is kept separate from the specific design decisions that are made in different processors.
A feature which is IMPLEMENTATION DEFINED (IMP DEF for short) is defined by the specific micro-architecture. The implementation must present a consistent behavior/value.
For example, the size of the caches is IMP DEF. The architecture provides a defined mechanism for software to query what the cache sizes are, but the size of the cache is up to the processor designer.
Similarly, support for the cryptography instructions is IMP DEF. Again, there are registers to allow software to determine if the instructions are present or not.
In both examples, the choice is static. That is, a given processor either will, or will not, support the features and instructions. The presence of the feature cannot change at runtime.
For Cortex-A processors, some IMP DEF choices will be fixed, and some will be synthesis options. For example, on Cortex-A57 the size of the L1 caches is fixed, and the size of the L2 cache is a synthesis option. However, the decision about the size of the L2 cache is made at design time. It is still static at runtime.
Full details of the IMP DEF options will be documented in the TRM.
UNPREDICTABLE and CONSTRAINED UNPREDICTABLE
UNPREDICTABLE and CONSTRAINED UNPREDICTABLE are used to describe things that software should not do.
When something is UNPREDICTABLE or CONSTRAINED UNPREDICTABLE, the software cannot rely on the behavior of the processor. The processor might also exhibit different behaviors if software carried out the bad action multiple times.
For example, providing a misaligned translation table is CONSTRAINED UNPREDICTABLE. This represents bad software. Bad software is software that violates the architectural rule that translation tables should adhere to.
Unlike IMP DEF behaviors, the TRM does not usually describe all the UNPREDICTABLE behaviors.
Sometimes, we will remove a feature from the architecture. There are several reasons that might happen, such as performance or because the feature is no longer commonly used and is unnecessary. However, there may still be some legacy software that relies upon the feature. Therefore, before removing a feature completely, we will first mark it as DEPRECATED. For example, the Arm Architecture Reference Manual states:
The uses of the IT instruction, and use of the CP15DMB, CP15DSB and CP151SB barrier instructions, are deprecated for performance reasons.
DEPRECATED is a warning to developers that a feature will be removed in the future, and that they should start removing it from their code.
Often, a control will be added to the architecture at the same time, allowing the feature to be disabled. This control allows developers to test for use of the feature in legacy code.
RES0/RES1 Reserved, should be Zero/Reserved, should be One
Reserved, should be Zero/Reserved, should be One (RES0/RES1) is used to describe a field that is unused and has no functional effect on the processor.
A reserved field might be used in some future version of the architecture. In this instance, the RES0/RES1 field value of 1 will give the new behavior.
A RES0 field will not always read as 0, and a RES1 field might not always read as 1. RES0/1 only tells you that the field is unused.
There are times when RES0/RES1 fields must be stateful. Stateful means that the fields read back the last written value.