Hello everyone. Welcome to today's training topic, ARMv8-M mainline floating point execution. Before we start our training just to do a quick introduction about myself. I'm Uma Maheswari Ramalingam working in Arm as a Principal Engineer. I joined Arm in 2006 and from then onwards, I have been predominantly working in Cortex-M processors and its architecture extensions. Let's get started. Having seen a background in its operations with a digital signal processing as we have seen in our earlier sessions, the DSP extension is about the instructions that operate on fixed-point numbers and floating point extension is about floating-point instructions. One other key element with the floating point extension is that it has some interaction with the v8-M based exception model as well which we will look into it in our current session. As a part of learning objective for this training session, at the end of this topic you will be able to summarize the floating-point extension features in ARMv8-M architecture. You will be able to describe the floating-point register bank versus normal register bank. We will also be looking into a quick view of floating-point system control registers present within the architecture. We'll also see details on how to enable the floating-point extension from software and describe the mnemonic structure of the floating-point instructions. Towards the end, we will elaborately see the types of floating-point exceptions and how it interacts with the ARMv8-M exception model. The agenda for this training is a quick overview of floating-point extensions, the details on floating-point registers, how to enable FPU interactions between the FPU exceptions, and last but not the least we'll also understand on how the FPU instructions are organized from a mnemonics annotation. The floating-point extension of ARMv8-M architecture largely defines the floating point unit of the Cortex-M processor. This is an optional extension which can be implemented and enabled only when the main line extension is implemented. To start off with an overview of what an ARMv8-M floating-point extension consist of, let us try to understand a little bit of the background and history of how a simple floating point operation and how it plays a role in our computer architecture. In computing, the floating point arithmetic is an arithmetic using the representation of real numbers as an approximation so as to support the trade-off between the range and precision. Before going deep into the floating-point arithmetic, let me try to give you the story of Ariane-5 rocket launch. It's quite possible that few people might already know about it, but just to refresh it I would like to quickly touch upon the story. On June 4 1996, the maiden flight of Ariane 5 launcher ended in failure. Only about 30 seconds after initiation of the flight sequence at an altitude of about 3,700 meters, the launcher veered off its flight path and broke up and exploded. The failure of the Ariane 5 was due to specification on the design errors and the software of the inertial reference system. What exactly happened? The rocket represented the horizontal bias or the BH value as a 64-bit floating variable which was frequently adequate from a mathematical perspective, however, the problems began to occur when the software attempted to stuff the 64-bit variable which can represent billions of potential values into a 16-bit integer which can only represent 65,535 values. For the first few seconds of the flight the rocket's acceleration was slow, so the conversion between the two values was successful. However as the rocket's velocity increased, the 64-bit variable exceeded the 65,000 or 65K and became too large to fit in, in the 16-bit variable. It was at this point that the processor encountered an operand error and calculated the BH value or the horizontal bias value with a diagnostic which caused the rocket explosion in just 40 seconds of the launch. To be precise, what exactly has happened? An overflow. Had overflow followed the IEEE754 FP standard by default policy, the recalibration software would have delivered an invalid result to be ignored by the motor guidance programs and the Ariane 5 would have continued as intended saving $400 million. Over the years instead of having a variety of floating-point representation across systems, the IEEE some do a full standard for the floating-point arithmetic was established. Since then the IEEE 754 standard is used, making it common standard used across NPCs and our embroidery processes resulting in same results across the platforms. In a computing context, there is an important detail to be understood, is the accuracy versus precision. Accuracy is about how close of value is to what it is meant to be? A precision is about how exactly we can specify it. With integers we can represent very precise numbers, but to store very precise numbers that are very big or very small we would need a lot of storage. Bigger the number, the more storage. With floating-point we deliberately lose precision in order to able to store very big or small numbers with a consistent amount of storage. There are three basic formats of IEEE; sometimes EEEE is used in architectures. They are single precision, double precision, and half precision. Single precision usually represent the float type in C language family while the double-precision represents a double type in C language family. Historically, Arm family of processes include the vector floating point or the VFP as a co-processor extinction in the classic family of processors. Over a period of time, the VFP architecture has evolved and has versions to include a wide variety of floating-point operations in all three positions. ARMv8-M support VFP-v5, that is version 5 of Arm vector floating-point architecture. This includes a broad set of single precision, half precision, and double-precision floating point arithmetic operations, conversion between the integers and the floating-point operations. VFP-v5 also introduces some new instructions and fuse multiply operations. We'll see more details in the upcoming slides. Since ARMv8-M architecture uses FP-v5 that is version 5 of Arm vector floating-point unit architecture, it falls apart of CP 10 and CP 11 co-processor encoding space. As a part of floating-point extension along with the floating point instructions, a bunch of floating-point system control registers are added in co-processor system space and system control block of the PPB space. Just to quickly touch upon the details for media on VFP feature registers or the MVFR registers, the software can use these registers to identify the floating-point extension features whether a single precision or a double-precision is being implemented within a system. We'll see more details on the FPSCR, FPCAR, and the FPCCR in the upcoming slides.
