I am having some trouble understanding my current situation due to the fact that I spend most of my time coding x86 software.
Apple have released a new requirement that apps must support 64 bit architecture from february 2015. From what I understand I can make a 'fat' binary with 32 bit and 64 bit code inside it.
The part that I am confused about is the fact that my project uses OpenMP and inline neon assembler code (hand tuned math libraries), this compiles fine on 32 bit ARM and runs perfectly.
I need some advice on how to get my project ready for Apples new requirement.
How can I enable OpenMP for GCC 4.9.2? There is not even a omp.h in the folder
Is the neon instruction set supported?
My SDK (Marmalade) says it supports armv8-a and simd, what does that say in terms of supporting neon?
How much of my inline arm assembly do I need to edit? I have LOTS of it and I am kind of panicking right now.
I hope someone can help me.
Links:
https://gcc.gnu.org/gcc-4.9/changes.html
http://docs.madewithmarmalade.com/display/MD750/Release+Notes#ReleaseNotes-7.5BetaReleaseNotes
Related
Does Delphi support ARMv5 and ARMv6 CPU's and is there a way to make my app work on them?
The answer is no because Delphi compiles native code targeted at a specific CPU, in this case ARMv7 with NEON support.
David I posted this on the subject:
Brian Long gives additional Android requirements in his blog post at
http://blog.blong.com/2013/09/delphi-for-android-aka-delphi-xe5-aka.html?showComment=1378942045563&m=1
Here is what he lists from our Documentation:
Android requirements
Because the Delphi compiler generates native machine instructions, its
output is processor-specific. In other words it doesn’t target the
Dalvik Virtual Machine, where regular Android applications reside,
which are basically Java p-code applications that are executed by a
variant of the Java VM. Instead it generates raw machine code, as all
the current wave of Delphi compilers do (the long gone Delphi for .NET
was the exception to this general rule). So because it’ a compiler
compiling native machine instructions Delphi’s Android support has the
following requirements:
there must be a GPU
the CPU must be ARMv7 with NEON instruction support
the OS on the target device must be one of: GingerBread: Android
2.3.3+ (MR1 or later), which is API level 10 Ice Cream Sandwich: Android 4.0.3+ (MR1 or later), which is API level 15 Jelly Bean:
Android 4.1+ (release, MR1, MR2 or later), which are API levels 16, 17
and 18
Embarcadero clearly states in their manual what is supported.
As far as I know (and what embarcadero tells on the RAD studio road shows), for Android at least ARM v7 with NEON support is required.
Edit: The (German) data sheet states "Android-Smartphones und –Tablet-Computer: ARMv7-Geräte mit NEON-Unterstützung," on the bottom of the last page.
Anthony Blake published a novel fft approach he calls the Fastest Fourier Transform in the South, and I'd like to use it in my iOS apps. He's also a user here on SO, so if he can answer this question, that would be great :) But if not, maybe another XCode/MacOS guru can point the way to solving the problem.
The issue is described in this github issue posting here. The short version, as I understand it, is that XCode is trying to build a 64 bit version of the library, but the code itself is 32 bit. I don't know if the ffts code as its posted there will work as part of a 64 bit app anyway (there's a lot of assembly there, and it's my understanding that assembly has to be hand-tuned to particular processors, and he may not have done such tuning for a 64 bit processor yet). What I want to know is:
How can I compile and use this library as part of an iOS app?
If I do so, can I make the app a 32 bit app on a 64 bit iOS device, so that I don't have to worry about compiling both 32 and 64 bit versions?
As a side note, I do believe that this question should be tagged 'ffts' (as 'fftw' is a tag), but meh.
I'd use the Accelerate framework, unless you measure things and can prove that it isn't fast enough. Apple has some pretty clever people working on these libraries (from personal knowledge, not just an assumption), so beating them in speed, especially on all kinds of different devices, would be quite a challenge.
Go to your project's target build settings and and leave only armv7 as build arhitecture and armv7 & armv7s as valid architectures.
This will build your project for both 32bit & 64bit devices but the app will run in 32bit mode.
I've been searching around the Lazarus IDE documentation for a bit, and thus far only found information related to cross compiling, so I was hoping someone could give me a straight answer on this. I'm currently working on a project that will require compilation for 32-bit Windows as well as 64-bit Windows. Additionally, I've already set up both versions of the Free Pascal Compiler. Does Lazarus have any built in functionality for configuring in both compilers, and then based on the build target, using the appropriate compiler? Ideally, this would be done at a global level, so that the configuration persists across projects, but if it can only be done at the project level, I don't mind doing it that way.
On further reading, I think I found my answer. I didn't realize it, but fpc has the same sort of front-end functionality as gcc. With that said, implementing the functionality described in my question is just a matter of installing the compiler as a cross compiler, rather than as an independent compiler. Since it doesn't look like you can use the x86_64 compiler to create a 32-bit version, you'll have to compile the 32-bit version, and then crosscompile the 64-bit version. In my case, I first compiled and installed the Win32 compiler using:
make all install INSTALL_PREFIX=C:\path\to\lazarus\1.0.8\fpc\2.6.3 OS_TARGET=win32 CPU_TARGET=i686 PP=ppc386.exe
Next, I compiled and crossinstalled the 64-bit compiler:
make crossall crossinstall INSTALL_PREFIX=C:\path\to\lazarus\1.0.8\fpc\2.6.3 OS_TARGET=win64 CPU_TARGET=x86_64
To confirm that it worked, you can find an executable called, ppcrossx64 in your C:\path\to\lazarus\1.0.8\fpc\2.6.3\bin\i386-win32 folder.
I would like to translate X86_64, x86, ARM executables into LLVM IR (disassembly).
What solution do you suggest ?
mcsema is a production-quality binary lifter. It takes x86 and x86-64 and statically "lifts" it to LLVM IR. It's actively maintained, BSD licensed, and has extensive tests and documentation.
https://github.com/trailofbits/mcsema
Consider using RevGen tool developed within the S2E project. It allows converting x86 binaries to LLVM IR. The source code could be checked out from Revgen branch of GIT repository available by url https://dslabgit.epfl.ch/git/s2e/s2e.git.
As regards to RevGen tool mentioned by #bsa2000, this latest paper "A compiler level intermediate representation based binary analysis and rewriting system" has pointed out some limitations in S2E and Revinc.
I pull them out here.
shortcoming of dynamic translation:
S2E [16] and Revnic [14] present a method for dynamically translating
x86 to LLVM using QEMU. Unlike our approach, these methods convert
blocks of code to LLVM on the fly which limits the application of LLVM
analyses to only one block at a time.
IR incomplete:
Revnic [14] and RevGen [15] recover an IR by merging the translated
blocks, but the recovered IR is incomplete and is only valid for
current execution; consequently, various whole program analyses will
provide incomplete information.
no abstract stack or promoting information
Further, the translated code retains all the assumptions of the
original bi- nary about the stack layout. They do not provide any
methods for obtaining an abstract stack or promoting memory locations
to symbols, which are essential for the application of several
source-level analyses.
I doubt there will be universal solution (think about indirect branches, etc.), LLVM IR is much "higher level" than any assembler. Though it's possible to translate on per-BB basis. You might want to check llvm-qemu and libcpu projects among others.
Just post some references on translating ARM binary to LLVM IR:
disarm - arm binary to llvm ir disassembler
https://code.google.com/p/disarm/
However, I have not tried it, thus not sure about its quality and stability. Anyone else may post additional information about this project?
There is new project, being in some early phases, The libbeauty:
https://github.com/jcdutton/libbeauty
Article about project: Libbeauty: Another Reverse-Engineering Tool, 24 December 2013, Michael Larabel - http://www.phoronix.com/scan.php?page=news_item&px=MTU1MTU
It only supports subset of x86_64 as input now. One of the project goals - is to be able to compile the generated LLVM IR back to assembly to get the binary with same functionality.
I downloaded Lazarus, but have worked with Embarcadero Delphi IDE too. I have a question about building cross-platform Delphi applications.
How can I build them under win32 environment? I read the wiki from Lazarus site, that explains how to do it, but I still do not understand it. Is is possible to build and compile application under win32 environment for Linux and MacOS? If it is possible, can someone explain ste-by-step how to do it exactly.
EDIT:
Now is the time for talking about the new XE2 version of the Delphi IDE I think :)
Thanks
What you're asking for already exists in the lazarus wiki site, you need to read these articles.
Multiplatform Programming Guide
Cross compiling
Cross compiling for Win32 under Linux
How to Write Portable Code (nice doc from Marco van de Voort)
Buildfaq
While crosscompiling to a non windows target is possible (and not that hard), getting used to fpc/lazarus and crosscompiling in one first step is a bridge too far. This because Linux is not a very homogenous target and dealing with this variation requires some understanding how libraries and linking works on Linux. This defeats one-button downloadable cross-compile setups to "general" linux. I know, such one-button thingies that work out of the box for everyone would be great, but it is just not going to happen (or only forvery limited distribution-version combinations)
Crosscompiling with FPC is not extremely difficult or rocket science, but the amount of jargon and details can flabbergast uninitiated people, and without background knowledge it is hard to diagnose problems as a result of minor misconfigurations
I recommend to first familiarize yourself with Lazarus/FPC, and only then make the crosscompilation leap. (and the already mentioned buildfaq names some reasons).
Bottomline: install lazarus on Windows and start porting your app. If that succeeds, start using a linux install (or VM) to familiarize yourself with Linux, and Lazarus under it. You'll need a linux install anyway to test.
Only then start thinking about crosscompiling to speed up the process.
CodeTyphon is a powerful Lazarus/FPC one click easy installation package for cross platform native development. It already supports 4 CPU/OS hosts (Win32, Win64, Linux32, Linux64), and 16 CPU/OS targets (arm-Wince, arm-Linux, arm-Embedded, arm-gba, arm-nds, i386-Win32, i386-Linux, i386-FreeBSD, i386-Haiku, x86_64-Win64, x86_64-Linux, x86_64-FreeBSD, powerpc-Linux, powerpc64-Linux, sparc-Linux, sparc-Solaris). More are supported in Lazarus/FreePascal, but others are not yet integrated in CodeTyphon. Did I mention that it is free? One code to rule them all ;-)
The point is that you don't have to waste days for setting up your cross platform environment, since someone has already done the hard work for you.