ARM Overview: Difference between revisions

Many uses means either few multifunctional (and theferefore complex and power-consuming) devices, or many simple devices suited just for that kind of operation. ARM processors as RISC devices chose simplicity over complexity, and therefore they are way too many cores with different instructions used. To have just ''one assembler to rule them all'', ARM defined Unified Assembly Language which can be translated for *'''any*''' of ARM cores.

Along with the general purpose registers, there is also the CPSR register, or, the 'Current Program Status Register'. This registers keeps track of the current operating mode, whether interrupts are enabled or not, etc. The operating system can read and write to this register using the MSR\MRS instructions. ([http://www.arm.com/support/faqdev/1472.html See Here]) There are several other system registers which can be used to [[Detecting_Raspberry_Pi_Board|detect the ARM board]] for example.

<small id="Note1">Note 1: Stack is 8 byte aligned at all times outside of prologue/epilogue of non-leaf function. Leaf functions can have 4 byte aligned stacks. 8 byte alignment is required for ldrd/strd to function on the stack, which mostly only comes into play when using varargs with 64-bit integers. Care must be taken in interrupts and exceptions to align the stack to 8 byte before calling C code.</small>

Loading of large immediate values into registers can be interestingly different from X86x86/X64x64. A immediate value being a value that is literally encoded into the instruction. For example the X86x86/X64x64 compatible processors support loading a 32-bit immediate (also called a constant) into an arbitrary register. The ARM's A32 and Thumb32 instruction sets do not. Instead one must use a series instructions to gain the same effect or store the value in memory outside of the instruction stream. In essence one may consider the storage of the value outside of the instruction stream the same as storage inside but the does exist a difference in many ways and this is something to keep in mind about the ARM. But, any compiler or assembler can and may take care of this problem for you. If you are compiling C/C++ code then these problems will be transparent to you for example, but as I said this is good information to know and understand especially with system software development.

Example, of machine code produced by GCC to load a register with a 32-bit value. As you can note the immediate value is technically outside of the instruction stream. On the X86x86/X64x64 the complete

Almost all instructions support conditional execution which is directly encoded into the instruction. On a X86x86/X64x64 architecture when a series of instructions need to be conditionally executed you will likely find a branching instruction which creates a completely separate code path for the processor to follow is the branch happens. The ARM supports branching, but also almost all individual instructions support conditional execution so that instead of causing the processor to potentially flush and refill the pipeline because a branch occurred instead it will load instructions into the pipeline which have a special conditional field. There are a maximum of 16 specified conditional codes with one reserved condition making 15 usable conditions. So instead of making a branch only to execute a few instructions those few instructions can remain in the execution path and will not be executed or will be executed simply using the conditional codes.

Memory detection is much different if you are coming from a background in the X86x86/X64x64 architecture. The ARM cores are used in many embedded applications and therefore the system board which the core resides on does not need to be overly complicated in order to be compatible with others boards. This is because almost any production board with an ARM core on it was likely custom designed just for that purpose. It is quite possible to use some generic board, but for lots of embedded applications there may not even be an operating system.

Therefore memory detection mechanisms may be non-existent and instead your operating system may opt for a value to be encoded into it at compile for for a specific system (board) which is known to have a certain amount of memory, or you may have a specific driver that your operating system loads just for that board (or is compiled in) where the driver can be queried by your kernel for the amount of memory installed. There are lots of ways and these were just two ideas, but the important part is to understand that unlike the X86x86/X64x64 compatible systems you will likely find absolutely no mechanisms to ''properly'' poll the amount of memory.

For exceptions, ARM uses a table similar to the IVT of the real mode x86. The table consists of a number of 32-bit entries. Each entry is an instruction (ARM instructions are 4bytes4 bytes in length.) that jumps to the appropriate handler.

Take note of that, and understand the design impact it imposes: On x86, the hardware vector table holds the addresses of handler routines. On ARM, the hardware vector table holds actual instructions. These instructions must fit into 4 bytes. This is actually not a big deal since all ARM instructions (assuming ARM mode and not Thumb, or Jazelle) are actually 4Bytes4 bytes anyway. The general idea is to emulate the behaviour of something like the x86 and simply place a jump instruction into the actual vector table, so that upon indexing into the table, the ARM processor is made to act as if it jumped to an address contained in the jump instruction. From there, consistency is obtained, and portability is eased.

===== Missing Division Functions (__aeabi_uidivmod, __aeabi_idiv) / No Division Support =====

A discussion about this section, and also at the end an example of LIBGCClibgcc's version of the divide function:

The source for LIBGCClibgcc and source of the division emulation function:

! colspan="8" | Little Endian Word Size (32Bit32-bit)

! colspan="8" | Little Endian Half-Word Size (16Bit16-bit)

! colspan="8" | Byte Size (8Bit8-bit)

''From reading the data sheet it appears that if operating in big endian mode the half-word access would be reversed to be more natural as you would expect on the X86x86/64x64 architecture. But, since I can not actually test it at the moment I am hoping I got it right.''

The reason memory access has to be aligned is because unaligned access requires additional access cycles, due tueto the way memory modules work (see DDR datasheet below), and would increase the complexity of load / store operations (and the processor core).

===== Specifying CPSR using AS (binutilsBinutils/GCC) Syntax =====

The X86x86/X64x64 target architecture will cause GCC to treat ''char'' as ''signed char'' [expected behavior by most], but when targeting the

| [[ARM_Beagleboard|BeagleboardBeagleBoard]]

| Tutorial on bare-metal [OS] development on the Texas Instruments BeagleboardBeagleBoard. Written specifically for the BeagleboardBeagleBoard-xM Rev C.

| Information about interfacing a PS2PS/2 device specifically the mouse, and starts with using the PL050. See links at bottom if PL050 is not of interest.

*[http://infocenter.arm.com/help/index.jsp ArmARM Infocenter]

*[http://re-eject.gbadev.org/files/GasARMRef.pdf GasGAS ARM Reference]

*[http://www.arm.com/miscPDFs/9658.pdf ArmARM Assembly Language Programming]