*Update 2017-05-17. I no longer work for the company where this question originated, and do not have access to Delphi XEx. While I was there, the problem was solved by migrating to mixed FPC+GCC (Pascal+C), with NEON intrinsics for some routines where it made a difference. (FPC+GCC is highly recommended also because it enables using standard tools, particularly Valgrind.) If someone can demonstrate, with credible examples, how they are actually able to produce optimized ARM code from Delphi XEx, I&#39;m happy to accept the answer.*

______


Embarcadero&#39;s Delphi compilers use an LLVM backend to produce native ARM code for Android devices. I have large amounts of Pascal code that I need to compile into Android applications and I would like to know how to make Delphi generate more efficient code. Right now, I&#39;m not even talking about advanced features like automatic SIMD optimizations, just about producing reasonable code. Surely there must be a way to pass parameters to the LLVM side, or somehow affect the result? Usually, any compiler will have many options to affect code compilation and optimization, but Delphi&#39;s ARM targets seem to be just &quot;optimization on/off&quot; and that&#39;s it.

LLVM is supposed to be capable of producing reasonably tight and sensible code, but it seems that Delphi is using its facilities in a weird way. Delphi wants to use the stack very heavily, and it generally only utilizes the processor&#39;s registers r0-r3 as temporary variables. Perhaps the craziest of all, it seems to be loading normal 32 bit integers as four 1-byte load operations. How to make Delphi produce better ARM code, and without the byte-by-byte hassle it is making for Android? 

At first I thought the byte-by-byte loading was for swapping byte order from big-endian, but that was not the case, it is really just loading a 32 bit number with 4 single-byte loads.*  It might be to load the full 32 bits without doing an unaligned word-sized memory load. (whether it SHOULD avoid that is another thing, which would hint to the whole thing being a compiler bug)*

Let&#39;s look at this simple function:

&lt;!-- language: lang-pascal --&gt;
    
    function ReadInteger(APInteger : PInteger) : Integer;
    begin
      Result := APInteger^;
    end;

Even with optimizations switched on, Delphi XE7 with update pack 1, as well as XE6, produce the following ARM assembly code for that function:

&lt;!-- language: lang-asm --&gt;
    
    Disassembly of section .text._ZN16Uarmcodetestform11ReadIntegerEPi:
    
    00000000 &lt;_ZN16Uarmcodetestform11ReadIntegerEPi&gt;:
       0:	b580      	push	{r7, lr}
       2:	466f      	mov	r7, sp
       4:	b083      	sub	sp, #12
       6:	9002      	str	r0, [sp, #8]
       8:	78c1      	ldrb	r1, [r0, #3]
       a:	7882      	ldrb	r2, [r0, #2]
       c:	ea42 2101 	orr.w	r1, r2, r1, lsl #8
      10:	7842      	ldrb	r2, [r0, #1]
      12:	7803      	ldrb	r3, [r0, #0]
      14:	ea43 2202 	orr.w	r2, r3, r2, lsl #8
      18:	ea42 4101 	orr.w	r1, r2, r1, lsl #16
      1c:	9101      	str	r1, [sp, #4]
      1e:	9000      	str	r0, [sp, #0]
      20:	4608      	mov	r0, r1
      22:	b003      	add	sp, #12
      24:	bd80      	pop	{r7, pc}


Just count the number of instructions and memory accesses Delphi needs for that. And constructing a 32 bit integer from 4 single-byte loads... If I change the function a little bit and use a var parameter instead of a pointer, it is slightly less convoluted:

&lt;!-- language: lang-asm --&gt;
    
    Disassembly of section .text._ZN16Uarmcodetestform14ReadIntegerVarERi:
    
    00000000 &lt;_ZN16Uarmcodetestform14ReadIntegerVarERi&gt;:
       0:	b580      	push	{r7, lr}
       2:	466f      	mov	r7, sp
       4:	b083      	sub	sp, #12
       6:	9002      	str	r0, [sp, #8]
       8:	6801      	ldr	r1, [r0, #0]
       a:	9101      	str	r1, [sp, #4]
       c:	9000      	str	r0, [sp, #0]
       e:	4608      	mov	r0, r1
      10:	b003      	add	sp, #12
      12:	bd80      	pop	{r7, pc}

I won&#39;t include the disassembly here, but for iOS, Delphi produces identical code for the pointer and var parameter versions, and they are almost but not exactly the same as the Android var parameter version. 
*Edit: to clarify, the byte-by-byte loading is only on Android. And only on Android, the pointer and var parameter versions differ from each other. On iOS both versions generate exactly the same code.*

For comparison, here&#39;s what FPC 2.7.1 (SVN trunk version from March 2014) thinks of the function with optimization level -O2. The pointer and var parameter versions are exactly the same.

&lt;!-- language: lang-asm --&gt;
    
    Disassembly of section .text.n_p$armcodetest_$$_readinteger$pinteger$$longint:

    00000000 &lt;P$ARMCODETEST_$$_READINTEGER$PINTEGER$$LONGINT&gt;:
    
       0:	6800      	ldr	r0, [r0, #0]
       2:	46f7      	mov	pc, lr

I also tested an equivalent C function with the C compiler that comes with the Android NDK.

&lt;!-- language: lang-c --&gt;

    int ReadInteger(int *APInteger)
    {
    	return *APInteger;
    }

And this compiles into essentially the same thing FPC made:

&lt;!-- language: lang-asm --&gt;
    
    Disassembly of section .text._Z11ReadIntegerPi:
    
    00000000 &lt;_Z11ReadIntegerPi&gt;:
       0:	6800      	ldr	r0, [r0, #0]
       2:	4770      	bx	lr

How to affect Delphi XEx code generation for Android/ARM targets?

Is the x86 Architecture specially designed to work with a keyboard while ARM expects to be mobile? What are the key differences between the two?

How does the ARM architecture differ from x86?

Raspberry Pi Type 3 has 64-bit CPU, but its architecture is not `arm64` but `armhf`.
What is the difference between `arm64` and `armhf`?


What is difference between arm64 and armhf?

[FJCVTZS][1] is &quot;Floating-point Javascript Convert to Signed fixed-point, rounding toward Zero&quot;.  It is supported in Arm v8.3-A chips and later.  Which is odd, because you don&#39;t expect to see JavaScript so close to the bare metal.

I can find explanations of what the instruction does, but not why it exists.  [This thread][2] says &quot;it exists as a single instruction is because JS&#39;s lack of an integer type means certain use cases need this operation obscenely often for no good algorithmic reason.&quot;.  That&#39;s plausible but I would like a more detailed understanding.



  [1]: https://developer.arm.com/documentation/dui0801/h/A64-Floating-point-Instructions/FJCVTZS
  [2]: https://twitter.com/marcan42/status/1009468989213327360

Why do ARM chips have an instruction with Javascript in the name (FJCVTZS)?

In my current project I make use of multiple .so files. These are located at the armeabi and armeabi-v7a folder. Unfortunately one of the .so files is a 6MB and I need to reduce file size. Instead of having a fat APK file, I would like to use just the armeabi files and remove the armeabi-v7a folder.

According to the NDK documentation, armeabi-v7a code is extended armeabi code which can contain extra CPU instructions. This all goes beyond my expertise, but I question why one would like to have both armeabi-v7a and armeabi code. There must be a good reason to have both, right?

On my test devices this all seem to work fine. These have ARM v7 CPU&#39;s. Is it safe to assume that everything works now?

Why use armeabi-v7a code over armeabi code?

I have two &quot;unlocked&quot; devices, an iPad mini 3, and a Galaxy Edge 6, both endowed with a terminal and a minimalistic set of unix commands. I thought both devices have arm64 processors but when I ran

    uname -a

on both devices I got the following :

for the iPad mini 3 :

    xxxxs-iPad:/var/mobile root# uname -a
    Darwin xxxx-iPad 14.0.0 Darwin Kernel Version 14.0.0: Wed Jun 24 00:50:15 PDT 2015; root:xnu-2784.30.7-30/RELEASE_ARM64_S5L8960X iPad4, **arm64**, J85mAP

for the Samsung Galaxy s6 Edge :

    u0_a203@zerolte:/ $ uname -a
    Linux localhost 3.10.61-4497415 #1 SMP PREEMPT Thu Apr 9 15:06:40 KST 2015 **aarch64** GNU/Linux

If I am not wrong, the last info in both case, J85mAP and GNU/Linux, stand for firmwares, and the antepenultimate infos, arm64 and aarch64, stand for the processors.

My questions are the following : obviously the strings &quot;arm64&quot; and &quot;aarch64&quot; are not the same, but I always thought arm64 and aarch64 were the same. (It&#39;s even told when you put the arm64 tag to a question here.)  

So, are they really identical?  

Especially, what should I worry about in case of cross-building libraries for both targets ? In fact, I have gcc 5.2.0 in mind, but maybe also lower versions. Can I just pass

    -target=arm64

or

    -target=aarch64

according to which device I target and just worry about the rest of options to configure?

**EDIT** Hum, look for this again, without success.

Differences between arm64 and aarch64

I have an embedded application with a time-critical ISR that needs to iterate through an array of size 256 (preferably 1024, but 256 is the minimum) and check if a value matches the arrays contents. A `bool` will be set to true is this is the case.

The microcontroller is an NXP LPC4357, ARM Cortex M4 core, and the compiler is GCC. I already have combined optimisation level 2 (3 is slower) and placing the function in RAM instead of flash. I also use pointer arithmetic and a `for` loop, which does down-counting instead of up (checking if `i!=0` is faster than checking if `i&lt;256`). All in all, I end up with a duration of 12.5&amp;nbsp;&#181;s which has to be reduced drastically to be feasible. This is the (pseudo) code I use now:

    uint32_t i;
    uint32_t *array_ptr = &amp;theArray[0];
    uint32_t compareVal = 0x1234ABCD;
    bool validFlag = false;

    for (i=256; i!=0; i--)
    {
        if (compareVal == *array_ptr++)
        {
             validFlag = true;
             break;
         }
    }

What would be the absolute fastest way to do this? Using inline assembly is allowed. Other &#39;less elegant&#39; tricks are also allowed.


Quickly find whether a value is present in a C array?

I am attempting to get cross-compiling for Raspberry Pi working on my Ubuntu machine. 

During my initial attempts I was using the arm-linux-gnueabi compiler, which is available in the Ubuntu repo. I got this working. I was able to build all my dependencies and use the cross-compiler in my cmake project.

However, I believe I should be using the hf version, so I switched to arm-linux-gnueabihf. Then I realized that this does not work with Raspberry Pi since it is armv6.

After some Googling, I then found the [pre-built toolchain from GitHub][1].

I downloaded the toolchain, but I don&#39;t really understand how to &quot;install&quot; it. I extracted the files to my home directory. The directory structure looks like this:

    /gcc-linearo-arm-linux-gnueabihf-raspbian
        /arm-linux-gnueabihf
            /bin
                (contains g++, gcc, etc)
            /lib
                (contains libstdc++ library)
        /bin
            (contains arm-linux-gnueabihf-g++, arm-linux-gnueabihf-...)
        /lib
            (gcc lib stuff)
       

If I change directory to the INNER bin folder I am able to compile a test program from the terminal without any problems.

    ~/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/
    arm-linux-gnueabihf/bin$ g++ test.cpp -o test

I then tried to compile a test program in the OUTER bin folder, which contains the prefixed versions of the tools.

     ~/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin$ 
     arm-linux-gnueabihf-g++ test.cpp -o test

However, when I try to use the compiler now (from outside the inner bin directory), it is unable to find the libstdc++ shared library that comes with the toolchain:

    arm-linux-gnueabihf-gcc: error while loading shared libraries: 
    libstdc++.so.6: cannot open shared object file: No such file or directory.

Furthermore, I want to be able to use the compiler without having to navigate to the bin directory. So I tried adding the OUTER bin directory (since I want the prefixed versions) and both lib directories to my PATH:

    export PATH=$PATH:~/tools/.../bin
    export PATH=$PATH:~/tools/.../lib
    export PATH=$PATH:~/tools/.../.../lib

However, this results in the same error. How should I &quot;install&quot; the toolchain so that I can use the toolchain from everywhere, just like I can when I use the cross-compilers from the Ubuntu repo?


  [1]: https://github.com/raspberrypi/tools

How to install the Raspberry Pi cross compiler on my Linux host machine?

I use the latest `Apple M1` chip processor. And I keep getting errors while application installation.

say.,
```
brew install openjdk@11
```

```
Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)!
Please create a new installation in /opt/homebrew using one of the
&quot;Alternative Installs&quot; from:
  https://docs.brew.sh/Installation
You can migrate your previously installed formula list with:
  brew bundle dump
```

Need help with exact steps to follow. 

Error: Cannot install in Homebrew on ARM processor in Intel default prefix (/usr/local)

When I compile C code with my cross toolchain, the linker prints pages of warnings saying that my executable uses hard floats but my libc uses soft floats. What&#39;s the difference?

What&#39;s the difference between hard and soft floating point numbers?

The final images produced by compliers contain both bin file and extended loader format ELf file ,what is the difference between the two , especially the utility of ELF file.

What is the difference between ELF files and bin files?

I am reading definitions over and over again and I still not getting what are SP and LR in ARM? I understand PC (it shows next instruction&#39;s address), SP and LR probably are similar, but I just don&#39;t get what it is. Could you please help me?

**edit:** if you could explain it with examples, it would be superb.

**edit:** finally figured out what LR is for, still not getting what SP is for.

What are SP (stack) and LR in ARM?

I&#39;m new to the field of microcontrollers. I need to port an IDE which is compiling programs for AVR microcontrollers to compile programs for ARM microcontrollers. I have just replaced the compiler from AVR to ARM and added some options as told by someone.
The following is the command:

    \ARM-GCC\bin\arm-none-eabi-gcc -O0 -ffunction-sections -Wall -std=gnu99 -mfloat-abi=soft 
    -Wa,-adhlns=&quot;$@.lst&quot; -fmessage-length=0 -mcpu=cortex-m0 -mthumb -g3 -gdwarf-2 -Wl,
    --gc-sections -o &lt;Dir_name&gt;\Build_Files\Blink_arm.cpp.elf  &lt;Dir_name&gt;\Build_Files\Blink_arm.cpp.o &lt;Dir_name&gt;\Build_Files\core.a 
    -L&lt;Dir_name&gt;\Build_Files -lm 


When I execute it I get the follwing error:

    tools/arm-gcc/bin/../lib/gcc/arm-none-eabi/4.6.2\libc.a(lib_a-exit.o): In function `exit&#39;:
    exit.c:(.text+0x18): undefined reference to `_exit&#39;  
    collect2: ld returned 1 exit status

May I get some help on what is this error and how can I solve it. And also I don&#39;t know what those options in the command line specify.

exit.c:(.text+0x18): undefined reference to `_exit&#39; when using arm-none-eabi-gcc

I want to know the difference between FIQ and IRQ interrupt system in
any microprocessor, e.g: ARM926EJ.

What is the difference between FIQ and IRQ interrupt system?

I&#39;ve seen [a lot of talk about running Mono/.NET code on the Raspberry Pi][1]. Has there been any success in actually running any Mono code on a Raspberry Pi?

On their site, they list several Linux distributions that work on the device and some of these distributions include Mono. However, none detail whether Mono works on it.

Is there a working implementation?

  [1]: https://stackoverflow.com/questions/9547047/monodevelop-armv6-raspberry-pi


Mono on Raspberry Pi

This is a problem that happens specifically on the ARM, not on x86 or x64.  I had this problem reported by a user and was able to reproduce it using UWP on Raspberry Pi 2 via Windows IoT.  I&#39;ve seen this kind of problem before with mismatched calling conventions, but I&#39;m specifying Cdecl in the P/Invoke declaration and I tried explicitly adding __cdecl on the native side with the same results.  Here is some info:

P/Invoke declaration ([reference][1]):

    [DllImport(Constants.DllName, CallingConvention = CallingConvention.Cdecl)]
    public static extern FLSliceResult FLEncoder_Finish(FLEncoder* encoder, FLError* outError);


The C# structs ([reference][2]):

    internal unsafe partial struct FLSliceResult
    {
        public void* buf;
        private UIntPtr _size;
    
        public ulong size
        {
            get {
                return _size.ToUInt64();
            }
            set {
                _size = (UIntPtr)value;
            }
        }
    }
    
    internal enum FLError
    {
        NoError = 0,
        MemoryError,
        OutOfRange,
        InvalidData,
        EncodeError,
        JSONError,
        UnknownValue,
        InternalError,
        NotFound,
        SharedKeysStateError,
    }
    
    internal unsafe struct FLEncoder
    {
    }

The function in the C header ([reference][3])

    FLSliceResult FLEncoder_Finish(FLEncoder, FLError*);

FLSliceResult may be causing some problems because it is returned by value and has some C++ stuff on it on the native side?

The structs on the native side have actual information, but for the C API, FLEncoder is defined [as an opaque pointer][4].  When calling the method above on x86 and x64 things work smoothly, but on the ARM, I observe the following.  The address of the first argument is the address of the SECOND argument, and the second argument is null (e.g., when I log the addresses on the C# side I get, for example, 0x054f59b8 and 0x0583f3bc, but then on the native side the arguments are 0x0583f3bc and 0x00000000).  What could cause this kind of out of order problem?  Does anyone have any ideas, because I am stumped...

Here is the code I run to reproduce:

    unsafe {
        var enc = Native.FLEncoder_New();
        Native.FLEncoder_BeginDict(enc, 1);
        Native.FLEncoder_WriteKey(enc, &quot;answer&quot;);
        Native.FLEncoder_WriteInt(enc, 42);
        Native.FLEncoder_EndDict(enc);
        FLError err;
        NativeRaw.FLEncoder_Finish(enc, &amp;err);
        Native.FLEncoder_Free(enc);
    }

Running a C++ app with the following works fine:

    auto enc = FLEncoder_New();
    FLEncoder_BeginDict(enc, 1);
    FLEncoder_WriteKey(enc, FLSTR(&quot;answer&quot;));
    FLEncoder_WriteInt(enc, 42);
    FLEncoder_EndDict(enc);
    FLError err;
    auto result = FLEncoder_Finish(enc, &amp;err);
    FLEncoder_Free(enc);

This logic can trigger the crash with the latest [developer build][6] but unfortunately I have not yet figured out how to reliably be able to provide native debug symbols via Nuget such that it can be stepped through (only building everything from source seems to do that...) so debugging is a bit awkward because both native and managed components need to be built.  I am open to suggestions on how to make this easier though if someone wants to try.  But if anyone has experienced this before or has any ideas about why this happens, please add an answer, thanks!  Of course, if anyone wants a reproduction case (either an easy to build one that doesn&#39;t provide source stepping or a hard to build one that does) then leave a comment but I don&#39;t want to go through the process of making one if no one is going to use it (I&#39;m not sure how popular running Windows stuff on actual ARM is)

**EDIT** Interesting update:  If I &quot;fake&quot; the signature in C# and remove the 2nd parameter, then the first one comes through OK.

**EDIT 2** Second interesting update:  If I change the C# FLSliceResult definition of size from `UIntPtr` to `ulong` then the arguments come in correctly...which doesn&#39;t make sense since `size_t` on ARM should be unsigned int.

**EDIT 3** Adding ` [StructLayout(LayoutKind.Sequential, Size = 12)]` to the definition in C# also makes this work, but WHY?  sizeof(FLSliceResult) in C / C++ for this architecture returns 8 as it should.  Setting the same size in C# causes a crash, but setting it to 12 makes it work.

**EDIT 4** I minimalized the test case so that I could write a C++ test case as well.  In C# UWP it fails, but in C++ UWP it succeeds.

**EDIT 5** [Here](https://gist.github.com/borrrden/58b6b7e49053395e18684ed7f4971f32) are the disassembled instructions for both C++ and C# for comparison (though C# I&#39;m not sure how much to take so I erred on the side of taking too much)

**EDIT 6** Further analysis shows that during the &quot;good&quot; run when I lie and say that the struct is 12 bytes on C#, the return value gets passed to register r0, with the other two args coming in via r1, r2.  However, in the bad run, this is shifted over so that the two args are coming in via r0, r1 and the return value is somewhere else (stack pointer?)

**EDIT 7** I consulted the [Procedure Call Standard for the ARM Architecture](http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf).  I found this quote:  &quot;A Composite Type larger than 4 bytes, or whose size cannot be determined statically by both caller and
callee, is stored in memory at an address passed as an extra argument when the function was called (&#167;5.5,
rule A.4). The memory to be used for the result may be modified at any point during the function call.&quot;  This implies that passing into r0 is the correct behavior as extra argument implies the first one (since C calling convention doesn&#39;t have a way to specify the number of arguments).  I wonder if the CLR is confusing this with another rule about **fundamental** 64-bit data types:  &quot;A double-word sized Fundamental Data Type (e.g., long long, double and 64-bit containerized vectors) is
returned in r0 and r1.&quot;

**EDIT 8** Ok there is a lot of evidence pointing to the CLR doing the wrong thing here, so I filed a [bug report](https://github.com/dotnet/coreclr/issues/12503).  I hope someone notices it between all the automated bots posting issues on that repo :-S.

  [1]: https://github.com/couchbase/couchbase-lite-core/blob/e8a4c5e3df5796b380d2019546b403ab0229702f/CSharp/src/LiteCore.Shared/Interop/Fleece_native.cs#L490-L491
  [2]: https://github.com/couchbase/couchbase-lite-core/blob/e8a4c5e3df5796b380d2019546b403ab0229702f/CSharp/src/LiteCore.Shared/Interop/Fleece_defs.cs
  [3]: https://github.com/couchbaselabs/fleece/blob/b607804bd45b0298f612d8fd1b5299b773a4a89b/Fleece/Fleece.h#L516
  [4]: https://github.com/couchbaselabs/fleece/blob/b607804bd45b0298f612d8fd1b5299b773a4a89b/Fleece/Fleece.h#L38
  [5]: https://github.com/couchbase/couchbase-lite-net/blob/feature/api-v2/src/Couchbase.Lite.Tests.UWP/UnitTestApp.xaml.cs#L68
  [6]: https://github.com/couchbase/couchbase-lite-net/releases/tag/2.0.0-db009

What could cause P/Invoke arguments to be out of order when passed?

I&#39;m new to Android Studio. My computer doesn&#39;t support HAXM so it won&#39;t let me install that to use for virtualization. In some similar questions on this website people mention setting up a virtual device with an ARM instead of HAXM. How can I do this? 

In the AVD manager all of the premade hardware profiles use HAXM, and when I click &quot;New Hardware Profile&quot; I don&#39;t see any option to use ARM. I looked in the SDK Manager and for API 22 I have installed &quot;ARM EABI v7a System Image&quot; and &quot;Google APIs ARM EABI v7a System Image&quot;, are those what I need? 

How can I create a custom virtual phone with ARM, or is there a way I can use one of the preexisting hardware devices with ARM instead of HAXM?

Android Studio - How Can I Make an AVD With ARM Instead of HAXM?

I have been having this problem for the last few days and I can&#39;t get my head around what is really happening here, or what is the problem.

I have a makefile with these flags:


    CC = arm-linux-gnueabihf-gcc-4.6
    FLAGS = -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -mfloat-abi=softfp -std=gnu99

I have a library in a .a file, which has some object files, all I need to do is link them in with my executable.  I know the prototypes and all that, the only thing that complains is the following:

    /usr/bin/ld: error: *EXECUTABLE* uses VFP register arguments, *OBJECTFILE* does not
    /usr/bin/ld: failed to merge target specific data of file *OBJECTFILE*

When I don&#39;t use the -mfloat-abi=softfp, I get another error relating to floating point registers.

Does anyone have any idea what is causing this, and what I can do to fix this, such as making it so that my executable does not use Virtual Floating Point Register arguments?

    x@x:~/Desktop/perf_test$ make
    arm-linux-gnueabihf-gcc-4.6 -c -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -ftree-vectorize -std=gnu99 -mfloat-abi=softfp  perf_test.c ../baseline/util.c
    arm-linux-gnueabihf-gcc-4.6 -o perf_test perf_test.o util.o  ../baseline/lib.a
    /usr/bin/ld: error: perf_test uses VFP register arguments, perf_test.o does not
    /usr/bin/ld: failed to merge target specific data of file perf_test.o
    /usr/bin/ld: error: perf_test uses VFP register arguments, util.o does not
    /usr/bin/ld: failed to merge target specific data of file util.o
    /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(a.o) does not
    /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(a.o)
    /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(b.o) does not
    /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(b.o)
    /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(c.o) does not
    /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(c.o)
    /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(d.o) does not
    /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(d.o)
    /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(e.o) does not
    /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(e.o)
    /usr/bin/ld: error: perf_test uses VFP register arguments, ../baseline/lib.a(f.o) does not
    /usr/bin/ld: failed to merge target specific data of file ../baseline/lib.a(f.o)
    collect2: ld returned 1 exit status
    make: *** [perf_test] Error 1

ARM compilation error, VFP registers used by executable, not object file

What is the difference between arm-linux-gcc and arm-none-linux-gnueabi and arm-linux-gnueabi
toolchains?

Do they compile differently? 

What is the difference between arm-linux-gcc and arm-none-linux-gnueabi

What for do we need ARM EABI v7a System image in Android development?
What is the purpose of that particular image?

What is the use of ARM EABI v7a System image in android?

I am constantly getting this warning while building my android studio code using terminal command `gradle clean assembleRelease`:

`Unable to strip library &#39;lib.so&#39; due to missing strip tool for ABI &#39;ARMEABI&#39;. Packaging it as is.`

Please help me on how to get this warning resolved.

Note: I know this won&#39;t affect the behaviour of my app, but my APK is too bulky and this will surely help me reduce APK size. So I need this resolved.

Android Studio : Missing Strip Tool

As we know, for X86 architecture: After we press the power button, machine starts to execute code at 0xFFFFFFF0, then it starts to execute code in BIOS in order to do hardware initialization. After BIOS execution, it use bootloader to load the OS image into memory. At the end, OS code starts to run. 
For ARM architecture, what is the booting process after use press the power button?
Thanks!


What is the booting process for ARM?

It&#39;s been a while since I last coded arm assembler and I&#39;m a little rusty on the details. If I call a C function from arm,  I only have to worry about saving r0-r3 and lr, right?

If the C function uses any other registers, is it responsible for saving those on the stack and restoring them? In other words, the compiler would generate code to do this for C functions. 

For example if I use r10 in an assembler function, I don&#39;t have to push its value on the stack, or to memory, and pop/restore it after a C call, do I?

This is for arm-eabi-gcc 4.3.0.

What registers to save in the ARM C calling convention?

What basically `__asm__ __volatile__ ()` does and what is significance of `&quot;memory&quot;` for ARM architecture?


Working of __asm__ __volatile__ (&quot;&quot; : : : &quot;memory&quot;)

What is the difference between arm-eabi, gnueabi and gnueabi-hf cross compilers?
I am kind of finding it difficult to choose the executable that is correct for my target platform.
Is there a native compiler for arm?

Difference between arm-eabi arm-gnueabi and gnueabi-hf compilers

under &quot;The Thumb instruction set&quot; in section 1-34 of &quot;ARM11TechnicalRefManual&quot; it said that:  

&quot;The Thumb instruction set is a subset of the most commonly used 32-bit ARM instructions.Thumb instructions are 16 bits long,and have a corresponding 32-bit ARM instruction that has the same effect on processor model.&quot;  

can any one explain more about this especially second sentence and say how does processor perform it?

What is the ARM Thumb Instruction set?

I am a bit confused about instruction sets. There are Thumb, ARM and Thumb 2. From what I have read Thumb instructions are all 16-bit but inside the **ARMv7M user manual** (page vi) there are Thumb 16-bit and Thumb 32-bit instructions mentioned. 

Now I have to overcome this confusion. It is said that Thumb 2 supports 16-bit and 32-bit instructions. So is ARMv7M in fact supporting Thumb 2 instructions and not just Thumb?  

One more thing. Can I say that Thumb (32-bit) is the same as ARM instructions which are allso 32-bit?

What is the difference between the ARM, Thumb and Thumb 2 instruction encodings?

I have successfully installed python 3.9.1 with Numpy and Matplotlib on a new Mac mini with Apple Silicon. However, I cannot install SciPy : I get compilation errors when using 

```
python3 -m pip install scipy
```

I also tried installing everything from brew, and `import scipy` works, but using it gives a seg fault. I have installed ARM versions of lapack and openblas, but this does not fix the problem.

Has anyone succeeded? (I am interested in running it natively, not through Rosetta).

How to install SciPy on Apple Silicon (ARM / M1)

When you build a gcc toolchain there is the possibility to build it as  arm-elf or as arm-none-eabi, but what is the difference? 

I use the eabi today, but that is just since everyone else seem to do that... but since that is a really bad argument, it would be really nice to understand the difference.

Note: This toolchain will crosscompile code for Cortex-M3 based mcu:s like the stm32.

Thanks

----

**Some links**:

EABI:

* http://en.wikipedia.org/wiki/Application_binary_interface
* http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.swdev.abi/index.html

ELF: 

* http://en.wikipedia.org/wiki/Executable_and_Linkable_Format

arm gcc toolchain as arm-elf or arm-none-eabi, what is the difference?

I have created a cross compiled arm executable. I want to find the library dependency of the executable. I am using ubuntu natty and installed arm-linux-gnueabi tool chain, which does not contain ldd. Is there a tool available to view arm executables library dependancy in linux.

cross compiler ldd

I&#39;m learning the linux kernel internals and while reading &quot;Understanding Linux Kernel&quot;, quite a few memory related questions struck me. One of them is, how the Linux kernel handles the memory mapping if the physical memory of say only 512 MB is installed on my system. 

As I read, kernel maps **0(or 16) MB-896MB** physical RAM into 0xC0000000 linear address and can directly address it. So, in the above described case where I only have 512 MB:

 - How can the kernel map 896 MB from only 512 MB ? In the scheme described, the kernel set things up so that every process&#39;s page tables mapped virtual addresses from 0xC0000000 to 0xFFFFFFFF (1GB) directly to physical addresses from 0x00000000 to 0x3FFFFFFF (1GB). But when I have only 512 MB physical RAM, how can I map, virtual addresses from 0xC0000000-0xFFFFFFFF to physical 0x00000000-0x3FFFFFFF ? Point is I have a physical range of only  0x00000000-0x20000000.

 - What about user mode processes in this situation? 

 - Every article explains only the situation, when you&#39;ve installed 4 GB of memory and the kernel maps the 1 GB into kernel space and user processes uses the remaining amount of RAM.

I would appreciate any help in improving my understanding.

Thanks..!

How does the linux kernel manage less than 1GB physical memory?

&gt; **TL/DR**: Where can I find more information about building a GCC 4.7.0 cross-compiling toolchain for ARM (gnueabi) platform (intended to run on a Raspberry Pi device)?

I have just got a brand new Raspberry Pi and I am very eager to start programming for it. I&#39;ve managed to install the GCC toolchain (I am using the Arch Linux system image) and compiled some basic programs, all working fine.

I&#39;ve also tried to compile the Boost libraries because I often use them in my projects and everything seemed to work fine by following the instructions (`./bootstrap.sh` + `./b2`) except for the fact that the compilation was painfully slow. I left it on for a few hours but it barely got past the first few source files. After I left it running for the night, I discovered that the build process aborted due to RAM shortage.

So, my guess is that Rasp Pi is simply underpowered for compiling something of such size as Boost. So, cross-compilation comes to my mind. However, even though there is a lot of information about ARM cross compilation available online, I find it confusing. Where does one even start? 

I have a recent GCC version (4.7.0) available on my Raspberry Pi, so I would ideally like to cross-compile with the same version. Where can I get the GCC 4.7.0 toolchain for ARM? (I will be compiling on x86 CentOS 6.2)

**Edit:**

I deallocated unneeded GPU memory and set up a 4GB swap partition on a USB drive, while build files are on a NFS share. Boost is now compiling much much faster, so it is manageable. I would still like to know how can I set up a GCC 4.7 toolchain for cross compilation on my x86 PC though, since I intend to do a lot of compiling and I would like it to be as fast as possible.

**Edit 2:**

Since GCC 4.7.0 is relatively new, there does not seem to be a pre-built cross-compiler (i386-&gt;ARM). I will probably have to build one myself, which seems an non-trivial task (I&#39;ve tried and failed). Does anyone know of a tutorial to follow for building a GCC cross-compiler, hopefully for one of the recent versions?  

I&#39;ve tried with [this great shell script][1] (which worked great for building a same-arch compiler) and I&#39;ve successfully built `binutils` and GCC&#39;s prerequisites, but then GCC build kept failing with many cryptic errors. I am really lost here, so I would greatly appreciate your help.

GCC on Raspberry Pi was configured with

    --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib 
    --mandir=/usr/share/man --infodir=/usr/share/info 
    --with-bugurl=https://bugs.archlinux.org/ 
    --enable-languages=c,c++,fortran,lto,objc,obj-c++ --enable-shared 
    --enable-threads=posix --with-system-zlib --enable-__cxa_atexit 
    --disable-libunwind-exceptions --enable-clocale=gnu 
    --disable-libstdcxx-pch --enable-libstdcxx-time 
    --enable-gnu-unique-object --enable-linker-build-id --with-ppl 
    --enable-cloog-backend=isl --enable-lto --enable-gold 
    --enable-ld=default --enable-plugin --with-plugin-ld=ld.gold 
    --with-linker-hash-style=gnu --disable-multilib --disable-libssp 
    --disable-build-with-cxx --disable-build-poststage1-with-cxx 
    --enable-checking=release --host=arm-unknown-linux-gnueabi 
    --build=arm-unknown-linux-gnueabi 

**Edit 3:**

I managed to build a 4.7 GCC toolchain for ARM (yay!) using [this shell script][2] as suggested by user dwelch in the comments. I also built `newlib` and `libstdc++` using [this article][3] as a guide. The toolchain works fine, but hen I run the executable on my Raspberry Pi, it fails with `Illegal instruction`. What could be the cause of that? 


  [1]: http://joelinoff.com/blog/?p=658
  [2]: http://github.com/dwelch67/raspberrypi
  [3]: http://wiki.osdev.org/OS_Specific_Toolchain

All Arm Solutions on Gang of Coders

Total of 32 Arm Solutions