Most options are interpretted or byte-code based and compiled just-in-time.Pros:Rapid developmentLarge range supported platformsGood tools (debuggers / profiling / code analysis)Garbage collectionRobust (stability / execeptions / error reporting)Cons:Not suitable for all applicationsLimited to functionality exposed in VM (no direct access to OS)Performance (such as graphics (OpenGL) & sound processing) – particularly on embedded platformsResource requirementsFavorite libraries like boost, libjpeg, lua, sqlite
No overhead / indirection by VMVM bugs are generally hard to workaround – can’t recompile librariesLess layers – less potential for bugsMost direct access to OS – they’re usually written in C/C++C++ is language you want to write in!Cons – no room here
Anything involving large amounts of data processingDJ app. Image effects – Instagram - morphing.Rendering of html / pdfs / flashImplementation of VMsGames – Physics / 3D scenes / ray tracing / Stereo pictures- C++ may be used for just part of an application
Choosing to use NSString vs.std::string or char*FileOutputStream vs. fopenEvery time you call a platform api your code is tied to systemObjective-C – initWithData / User defaults / CoreFoundation / Serialization methodsAndroid – Manifests / widespread use XML / Object persistenceWe should separate platform dependent and independent partsGood encapsulation (such as model-view-controller) is good for portabilityMake wrapper classes to encapsulate platform code
Each layer talks to next layer down. Layers below need no knowledge of layers aboveOnce these layers are separated, they can be compiled independently.VM based languages use platform independent Byte code. VM provides common API.
For C++, traditionally, can be done with libraries which are linked together.Using a standard library like libpng.We want intercept fopen because otherwise would have to vary “path” by platform(Or add profiling. Or add custom memory allocation routine for malloc).Don’t want to have to replace fopen() with my_fopen()How do we use custom fopen() ?
Replacing fopen means changing our C standard library used by our compilerWhen using gcc or llvm we can use newlib as our C standard library (libc.a & libm.a & …)http://wiki.osdev.org/Porting_NewlibNewlibcan be compiled „stand alone” –meaningwithoutany platform specificcde.Thisiscommonlydone for „bare-metal” / „bareboard” targetsAll you need to support a set of 17 system calls that act as ‘glue’ between newlib and the OS
Problem is we now have two libraries containing fopen – newlib & platforms – how to get the right one?Prelink application to newlib. This technique is commonly used to remove dependencies on 3rd party libraries by combining these dependencies into a single conglomerate libraryIt pulls in as many symbol definitions as it can (but doesn’t complain about undefined symbols)In XCode this is known as “Single-Object Prelink of static libraries”. Prelink is very fucking intimate thing for every particular platformWant to hide most symbols (such as our custom fopen) within library.Some symbols need to remain visible – such as the entry point for the applicationWe run “ld” again passing prelinked application library and platform library (loader).Platforms used this for are Sony PSP, Nintendo DS, LG TV (Linux based), etc.
Linking at runtime we can reuse a single application binary. No need to rebuild for new platform.Bugs in application library are platform independent (can be debugged on any system).Moving to new platform, new bugs can only be in platform layer.We’re effectively creating a virtual environment for our application.We can take complete control of memory heaps, file system & add profiling metrics.
Unlike many proprietary executable file formats, ELF is flexible and extensible, and it is not bound to any particular processor or architecture. This has allowed it to be adopted by many different operating systems on many different platforms. The ELF file format is also used as a generic object and executable format for binary images used with embedded processors like AVR.The Windows analogue is PE – Portable Executable....On Darwin it's Mach-Ohttp://www.symantec.com/connect/articles/dynamic-linking-linux-and-windows-part-onePosition Independent CodePosition independent code can be copied to any memory location without modification and then executed, unlike relocatable code which requires special processing by a runtime linker to make it suitable for execution at a given location.Global offset TableELF linkers support PIC Code through the GOT in each shared library. The GOT contains absolute addresses to all of the static data referenced in the program. The address of the GOT is normally stored in a register (EBX) which is a relative address from the code that references it.Procedure Linkage Table (PLT)Similar to how the GOT redirects any position-independent address calculations to absolute locations, the PLT redirects position-independent function calls to absolute locations.Apart from these two tables, the linker also refers to .dynsym, which contains all of the file's imported and exported symbols, .dynstr, which contains name strings for the symbols.
This is one of the key features of Marmalade SDK, which we work on creating.It has a slightly modified ELF format called S3E for the ARM architecture. It is compressed and includes meta-data for configuration.Loaders are provided for a wide range of mobile platforms (such as iOS, Android, Bada, Symbian). Applications are compiled once and then can be deployed to all these platforms.Access is provided to platform features: SMS, Camera, Location Services, Accelerometer, Sound recording, threads, etc. Applications query available features at runtime rather than #ifdef conditional programming.
Capabilities of C++Pros: Best performance (excepting assembly) Lower resource requirements Free from VM bugs Only constrained by platform (not VM) Your language!Cons:
Applications for C++Resource demanding applications Image and video editing Sound processing Document rendering Scripting engines Games
Code portabilityWhat makes code less portable? Use of platform specific APIs Platform’s methodologyCode for portability Focus use of platform APIs into less places Split platform dependent and independent code
Layer CakeApplication Code ->Common API ->Platform implementation ->Operating System
Substituting std lib functions LoadImage fopen _open fopen App Code newlib glue OS 17 system calls to support_exit isatty statclose kill timesenviron link unlinkexecve lseek waitfork open writefstat readgetpid sbrk
Prelinking LibrariesRelocatable link ld –rControl symbol visibilty -B reduceSecond link against platform library
Separate Binary Application library entirely platform independentLink to platform library at runtime?Virtualized environment without the overhead
Dynamic Code LoadingExecutable and Linkable Format (ELF) Binary
Embedded Execution Environment Marmalade SDK key feature Wide range of mobile platforms Access to platform features such as: SMS, Accelerometer & Gyro, Camera, Location services, threads, sound recording, etc.