The COSMIC functional size measurement (FSM) method can be applied in di erent phases of software projects: early in the design phase or after the implementation has been delivered. Di erent software artifacts can be used to produce the COSMIC functional size of a piece of software: speci cation requirements, implemented code, etc. COSMIC has been used in di erent domains (e.g. Management Information Systems (MIS), Real-time Embedded Systems-RTES, etc.), and has been applied to di erent conceptual frameworks and programming paradigms. Assembly language is the lowest-level programming language designed for a speci c type of processor executing machine code. Assembly can be compiled or interpreted from di erent high-level languages. ARM® processors account for 90% of those used in the mobile industry and controllers of IoT devices. In addition, 75% of the processors used in invehicle infotainment Advanced Driver-Assistance Systems (ADAS) are made by ARM. As a whole, they address 33% of the total addressable market. In this paper, we propose an FSM procedure based on COSMIC ISO 19761 to measure software artifacts expressed in ARM's base 32-bit Assembly code. An FSM automation prototype tool is also introduced.
The world of technology is going through a new phase, and the work ow of software development is starting to take on a newer more e cient form. Due to the always changing requirements of the industry, newer programming languages with features more suited to the market keep springing up. In addition, older languages are often updated or used as a basis for newer languages with better speci cations, lest they get ignored by a programming team.
Software Engineering is both a technical and a managerial process, where the
best-suited programming language and style are picked by experts for building
either a simple or a complex component of a project [
The genericness of COSMIC's rules allows them to be easily adapted to
different use cases. However, applying COSMIC to assembly languages, which has
been largely ignored in literature, can be very useful. Any language, whether
compiled or interpreted, or a hybrid of both, is bound to be represented in
binary streams of 1s and 0s for a processing unit to execute [
There are numerous microprocessor manufacturers in the market, many of
which adhere to a speci c base architecture and assembly language. ARM [
The rest of the paper is organized in the following manner: Section 2 provides an exhaustive literature survey of di erent COSMIC FSM procedures using different programming and modelling languages, including attempts to implement tools which automate the measurement procedures. Section 3 contains overviews of the COSMIC method and the ARM microprocessor family. Section 4 presents our proposed measurement procedure, as well as an illustrative example using two di erent ARM instructions. Finally, sections 5 and 6 respectively present an automated measurement prototype and conclude the paper with a statement of our planned future work.
Many approaches have been proposed in the literature to automate
COSMICbased measurements, for di erent types of input and in di erent domains. One
of the most notable inputs are conceptual models, which have taken many
different forms, and evolved throughout the years. One of the earliest attempts was
undertaken by Jenner [
A lot of e ort has also been made for other conceptual models. Diab et al.
formalised the rules of applying to ROOM framework for real-time applications,
and implemented a tool that works with RRRT models [
Another kind of input that has been explored in literature is plain text. Ishrar
et al. [
Tools have also been developed for actual programming environments. Soubra
et al. [
To the best of our knowledge, no attempts have been made to de ne rules and
guidelines based on the COSMIC method, for any low-level assembly language.
The closest thing to our approach was a work by Soubra and Abran who applied
COSMIC rules to Arduino C, mapping COSMIC to the di erent components of
an Arduino board [
This section presents overviews of COSMIC and ARM architecture. 3.1
COSMIC is an ISO-standardised method of quantifying FURs. It de nes how to decompose the system into layers and how to di erentiate between the various movements of data in a system according to what is called the boundaries of a Functional Process. It also dictates the guidelines of de ning the granularity of the measurement. The measurement unit is coined a COSMIC Functional Point (CFP), and each data movement has the size of 1 CFP.
The four kinds of data movements according to COSMIC are as follows:1. Entry (E): This corresponds to a data group passing a boundary from a functional user into a functional process, as a reaction to some trigger. 2. Exit (X): This corresponds to a data group crossing a boundary and moving outside the functional process. 3. Read (R): Data is read from some persistent storage into the currently running functional process that requires it. 4. Write (W): Data is written to some persistent storage within the reach of the currently running functional process.
Persistent storage is de ned as storage with means of storing data after a functional process terminates and/or of allowing a process to retrieve data that has been manipulated by some other functional process or another occurrence of the same process.
COSMIC rules can not be applied directly to measure the size of FURs; two other stages need to be carried out rst:1. Measurement Strategy Phase, in which the scope and the purpose of the measurement is de ned. This is done by applying the COSMIC Software Context Model. 2. Mapping phase, where the measurement rules of COSMIC are mapped and de ned for the domain being measured.
After the measurement takes place, the nal size of software is calculated by summing up the sizes of all the functional processes present within the de ned scope. The FSM procedure proposed in this paper is based on version 4.0.2 of COSMIC.
ARM is a family of RISC architectures for computer processors, based on the A32 Instruction Set Architecture -ISA, and its variations, the A64 and the T32 ISAs. The A64 ISA, the most recent addition, was introduced in tandem with the new ARMv8-A microarchitecture which supports 64-bit memory addressing. To maximise code density, T32 ISA have variable instruction lengths. To meet the typical need for oating point operations, an extension ISA exists. Other than that, additional ISA extensions are available for domains such as Machine Learning, which provide increased parallelism.
As of 2019, ARM processors account for 90% of those used in the mobile
industry and controllers of IoT devices. In addition, 75% of the processors used in
in-vehicle infotainment Advanced Driver-Assistance Systems (ADAS) are made
by ARM. As a whole, they address 33% of the total addressable market [
At the time of writing, three di erent families of chips are in production: the
(A)pplication family which is targeted at high-performance general applications,
the (R)eal-time family which is optimised for time-critical and real-time domains,
and nally the (M)icrocontroller family [
The register le in an ARM core consists of 31 registers, whose sizes are either
32- or 64-bits according to the version of the processor. Of those registers, 16 are
always visible to the user, while the remaining are used to store program states,
such as the program counter, and the stack pointer, and handle exceptions. As
for memory, di erent processors have di erent levels of caching, and some have
none at all, while providing a standard interface to an external memory [
One de ning feature of ARM instructions is the ability to conditionally execute commands by setting a speci c eld to the required the status of the system that the instruction must run in. If the condition is not met, an instruction is treated as a No Operation (NOP) instruction. This is more e cient than relying on branch instructions. 4
An FSM ARM
To correctly measure the functional size of a program represented in ARM instructions, we have to de ne the scope and the purpose of our measurement, and then we have to map COSMIC terms to ARM components. 4.1
The purpose of this procedure is to apply the COSMIC method to the compiled ARM assembly code. As to the scope, it is at the hardware level of a computing entity, be it a stand-alone processor, or a separate core in a multi-core system. Since we are working at such a low level, the granularity here would be at the processor instruction level, since each instruction carries out a distinctive operation that a ects the state of the system.
We consider the decoding circuitry (DC) to be our sole functional user. We say the decoding circuitry is the hardware unit responsible for extracting the di erent parameters from the fetched instruction, and analysing it so that the proper hardware signals, required for executing the instruction correctly, may be red.
As for the persistent storage, we consider the register le, any caches present,
and any existing co-processor register les/memories to be common persistent
storage units for any ARM processor. In addition, if a processor is complying
with the Harvard architecture, then the Data Memory is also a part of the
persistent storage. However, if the processor is based on von Neumann's, such
as pre-ARM9 processors [
Our mapping is based on our abstract view of instructions, which was inspired from the o cial documentation of ARM's ISA. In our model, we view each instruction simply as a subroutine carrying out a speci c operation, see gure 1. It must be stressed that this is not to be confused with the commonly known idea of an assembly subroutine which usually involves a branch and ending in a return. In our representation, every single instruction (including the branch and the return instructions) is a subroutine, carrying out a certain set of operations to achieve an intended change in the state of the system. void i n s t r u c t i o n ( h a l f b y t e c o n d i t i o n F i e l d , f b oo l ea n S g , param1 , param2 , . . . ) f // Optional s t a t u s r e g i s t e r check i f ( s t a t u s R e g i s t e r [ c o n d i t i o n B i t s ] != c o n d i t i o n F i e l d )
return ; // D e t a i l s o f t h e i n s t r u c t i o n go here // Optional s t a t u s r e g i s t e r update // ( f o r a r i t h m e t i c i n s t r u c t i o n s only ) i f ( S == t r u e )
u p d a t e S t a t u s R e g s i t e r ( ) g return ;
Moreover, for an instruction to be executed, the hardware needs to determine certain operands from the decoded instruction. The operands would naturally di er according to the nature of the instruction, and they can include information about the speci c index or label of the needed data in the persistent storage. Therefore, we perceive the operands as entries coming from the instruction decoder to the subroutine, which is then later used to carry out the intended job, by using the operands to read a register, write to memory, or carry out an arithmetic operation, etc. It should be noted that due to the instruction format of ARM instructions, a Read can take place at the beginning of the execution of an instruction, where the condition eld is compared to the status register bits that correspond to the needed comparison.
So based on the aforementioned idea, each instruction stored in the instruction memory is considered a separate independent functional process, which is triggered by fetching the instruction from the instruction memory according to the Program Counter, and passing it to the DC. This would be the Triggering Event. Of the extracted parameters, the condition eld, shown in gure 1, is the Triggering Entry, since it is common for all instructions. This Entry will be followed by others carrying the operands and signals as explained before.
We de ne the start of the functional boundary for incoming data groups to be the circuitry connecting the instruction decoding mechanism (i.e. the DC) and the execution circuitry, which can, but need not, contain a mixture of ALUs, shifters, and/or sign extenders. Naturally, the boundary will contain the register le where register contents will be fetched according to the instruction operands and other persistent storage. The boundary also encapsulates the circuitry required for reading and writing from the other persistent storage members. This de nition is arbitrary enough for and can be applied to any processor having a decoding and an execution stage in its pipeline.
The mappings of the COSMIC rules regarding data group movements into ARM terms are summarized in table 1. 4.3
Using the rules de ned in Section 4.2 to measure the size in CFP of every instruction, we aggregate the results coming from all instructions at the end of the execution of our program. For some instructions, such as the ADC (Add with Carry) instruction, the CFP count of the actions carrying out the instruction's objective will always be the same for any instance of the instruction, no matter the value of the operands. In other words, apart from the optional condition eld check, the CFP will be the same. On the other hand, other instructions, such as the PUSH instruction, would have di erent counts for di erent instances. The reason for this would be the nature of the parameters of the instruction, which can lead to di erent amounts of data movements based on their values. This is elaborated in the example below. Hence, we segregate ARM instructions into two types: xed size and variable size instructions, from a COSMIC FSM point of view.
To show how an instruction is broken down to be measured, gures 2 and 3 shows examples of breaking down an instruction into measureable form. Both examples borrow the parameter names from the syntax de nition of the corresponding instructions in ARM's ISA documentation. The CFP count of ADC instruction, where Operand2 is an immediate, not an optionally-shifted register value, is always 8 CFP, while the CFP count of PUSH instruction varies according to the reglist parameter. reglist is a mask that determines which registers will be pushed to the stack, as shown in the pseudo-code in the gure. Therefore, the CFP would vary based on the cardinality of reglist.
The status ags corresponding to the results of arithmetic operations are not automatically updated after each instruction in ARM. Instead, an optional identi er, S, has to be included in the instruction for this to happen. Therefore, an additional Write (1 CFP) updating the status register may take place depending on the presence of that identi er. 5
In this section, we present a prototype tool for a program expressed in ARM assembly language. 5.1
To retrieve a sample of machine code that can easily be analyzed and processed to carry out the proposed FSM procedure, we wrote a simple program in C as shown in gure 4. The C program contains two functions: square() and factorial(), of which the latter is recursive. The C le was compiled using GCC on a Raspberry Pi® 1 B+ board. The board runs on a Broadcom BCM2835 processor running an ARM ARM1176JZF-S™ core. This allowed us to have a binary void ADC( h a l f b y t e c o n d i t i o n F i e l d , boolean S , int rd , int rn , int Operand2 ) f 5 E n t r i e s i f ( s t a t u s R e g i s t e r [ c o n d i t i o n B i t s ] != c o n d i t i o n F i e l d ) return ; return ;
1 Write ( o p t i o n a l ) executable in ARM machine language. The next step was to translate the binary le to a human-readable le that can be used to analyze the instructions more easily. This is where GNU's objdump tool came in. We used this tool to disassemble the binary le, separating the ARM instructions according to the subroutines, see gure 5. The objdump returns an instruction in the form of fhexadecimal representation, the natural language name of the instruction, list of needed operandsg. This form adheres to ARM's assembly syntax. #include <s t d i o . h> int square ( int x ) f return x ∗ x ; g int f a c t o r i a l ( int x ) f i f ( x == 0) f return 1 ; g return x ∗ f a c t o r i a l ( x 1) ; g int main ( ) f int x = 5 ; x = x + 9 ; int y = square ( x ) ; y = f a c t o r i a l ( y ) ; p r i n t f ( "%dnn" , y ) ; return 0 ; g We used Python2 to implement our automated measurement tool, and gure 6 shows the UI of the tool. The tool accepts as input a text containing objdump's disassembly, object, or C le. The tool also gives the user the option to exclude C's standard headers from the measurement. For an accurate measurement of the CFP count of the input program, we comply with the syntax and the pseudocode de ned in ARM's o cial speci cations of their 32-bit ISA, A323. The ARM Quick Reference Card4 was also used as a guide. 2 https://www.python.org/ 3 https://developer.arm.com/docs/ddi0597/h 4 https://www.ee.ryerson.ca/ courses/coe718/Data-Sheets/ARM/IS-arm.pdf
We start by using a regular expression to preprocess and lter out noninstruction elements of the le, mainly assembly labels of di erent sections in the code. After retrieving the list of instructions, we carry out the following steps: 1. For each xed-size instruction, that always has the same functional size, we count its number of occurrences. We then multiply the occurrences by its size in CFP. 2. For variable size instructions, we further analyze the operands of each occurrence of such instructions to determine its exact COSMIC functional size. 3. For pseudo-instructions and aliases, we translate the instruction to an equivalent list of ARM instructions and use these resulting instructions for the measurement.
For our prototype, we only consider a subset of instructions, which are the ones present in our sample le. We plan to include all the instructions in the nal version of our prototype tool.
Our prototype tool returns the total CFP count of the input le with its breakdown into the di erent types of data movements, as shown in gure 7. It also returns the count of each unique instruction in the program. The user can save the output as two di erent. The rst of them is the functional size in CFP of the whole program, as well as the count of each unique instruction in the examined program. This is depicted in gure 8.
The second output is a Comma-Separated Values (CSV) le, containing a list of the hexadecimal codes, the instruction names, the operands, as well as the individual CFP count of each instruction. gure 9. shows the CSV output le. 6
FSM is used to estimate development e ort, manage project scope changes, measure productivity, benchmark, and normalize quality and maintenance ratios. COSMIC ISO 19761 is considered a second-generation FSM method that is designed to be independent of any implementation decisions embedded in the operational artifacts of the software to be measured.
In this paper, we proposed an application of the COSMIC method to an assembly language. We explained how the COSMIC measurement methods could be used to measure the functionality of compiled ARM programs, with an illustrative example and we introduced an automated measurement tool prototype that can easily produce the functional size in CFP of an ARM program.
We believe that our work would in uence the embedded systems industry, especially with the present boom in the domain of IoT and portable devices. In addition, we believe that our work would be useful to the compiler construction eld, as the CFP count can provide insight into the di erence of the e ciencies of two similar compilers.
In the future, we hope to apply our technique to a Complex Instruction Set Computer (CISC) language, and carry out a study to compare sizes in CFP as code is compiled into another.