X86 and AMD64 are the most important architectures for many computing environments (desktop, servers, and supercomputers). Obviously a JIT compiler should support both of them to gain acceptance.
Until recently, the SPARC architecture was the logical next step for a compiler, specially on high-end servers markets. But now that Sun is dead, things are not clear.
Oracle doesn't seem to be really interested in it, and some big projects are dropping support for that architecture (Ubuntu for example). But on the other hand, the OpenSPARC initiative intended to open source recent processors is quite promising, meaning that a lot of manufacturers could implement and use SPARC for free in the near future.
So, is SPARC still a good choice as the next target architecture for a JIT compiler? Or is it better to choose another one (POWER, ARM, MIPS, ...)?
I don't know any more than you about SPARC's future. I hope it has one; it's been tragic how many good architectures have died out while x86 has kept going.
But i would suggest you look at ARM as a target. It isn't present in big server hardware, but it's huge in the mobile market, and powers all sorts of interesting little boxes, like my NAS, my ADSL router, and so on.
Your next target architecture should definitely be ARM - power consumption in large datacenters is a huge issue and the next big thing will be trying to reduce that by using low-power CPUs; see Facebook's first attempt on this.
Related
Is it possible to run OpenCL on a system designed by a user on a SoC prototyping board? To be more specific, I have a ZedBoard (Xilinx Zynq) that has Dual ARM cores and a Programmable Logic (PL) Area. If I design a simple system of my own that has a video processing accelerator implemented in the logic area, an ARM core and an AXI interconnect, what do I have to do to provide OpenCL support for this simple system? (In this simple system, the ARM core could be the "Host" and the video processing accelerator could be the "device").
I am a student and I have only some basic knowledge about OpenCL. I have researched about my question and have only ended up confusing myself. What are the things that have to be done to provide OpenCL support for a SoC? I understand that this may be a big project, but I need a guideline where to start and how to proceed.
what do I have to do to provide OpenCL support for this simple system?
Implement a OpenCL platform that makes either use of your ARM CPU or the FPGA (or both). I'd say that is pretty much impossible for you; ARM would surely offer one for the CPU if it was easy (and they definitely have the financial means to employ capable engineers/computer scientists), and implementing accelerators on an FPGA requires in-depth knowledge of FPGA development, as well as compiler theory and experience in systems design. I don't want to sound mean, but you seem to have none of these three.
You asked where to get started; I recommend just writing a first accelerator that e.g. adds up a vector of numbers; as soon as you have that, you will have a clearer idea of your task.
If you want to have a look at a reference: The Ettus USRP E310 is a zynq-based SDR device. Ettus has a technology called RFNoC, which allows users to write their own blocks to push data through. Notice that this took quite a few engineers and quite some time to get started. Notice further that it's much easier than implementing something that converts OpenCL to FPGA implementations.
If you have access to the Xilinx tools: Vivado HLS 15.1 System Edition should compile OpenCL kernels. This will also be included in the SDAccel tool suite.
Source: UG973: Vivado Design Suite User Guide Release Notes, Installation,and Licensing
An alternative might be switching to Altera. They provide some good examples for the Altera Cyclone V SoC which is comparable to Xilinx Zynq devices (also includes ARM Cortex-A9) :
AlteraSDK for OpenCL
I am also a student and my current project is also going on a similar direction, i have successfully installed a version of opencl called POCL on the zedboard, it successfully detects the arm cpu of the zedboard. To install pocl, you need llvm and a horde of other things as well. but basic steps to get pocl up on the zedboard are given below:-
Installing pocl:
http://www.hosseinabady.com/install-pocl-opencl
running example:
http://www.hosseinabady.com/embedded-system-by-examples/opencl_embedded_system/opencl-vector-addition
Lots of dependency: can resolved easily
but LLVM make sure you install 3.4 version for pocl 0.9
Steps to install llvm
https://github.com/pacs-course/pacs/wiki/Instructions-to-install-clang-3.1-on-ubuntu-12.04.1-and-12.10
POCL 0.9 is successfully working for me, as you do the installation you will face many other missing dependencies like hwloc, mesa libraries, open gl/cl headers icd loaders i hope you can resolve them as its a very big list to put up in stack overflow.
In order to detect your fpga as an open cl device, thats not going to be a trivial thing to do, you can refer to this link question i posted on github
https://github.com/pocl/pocl/issues/285
and also a research paper published by hosseinbady found on the publications link on the pocl website
http://pocl.sourceforge.net/publications.html
hope this helps you
Try the ARM OpenCL SDK. The Zedboard has an ARM A9 CPU, this should have a NEON SIMD vector unit http://www.arm.com/products/processors/technologies/neon.php which can run OpenCL. See http://www.arm.com/products/multimedia/mali-technologies/opencl-for-neon.php.
The Zedboard isn't listed as an OpenCL conformant platform https://www.khronos.org/conformance/adopters/conformant-products#opencl.
So there is a chance the ARM driver will not work.
Good luck!
If still relevant, try this paper OpenCL on ZYNQ [PDF]
Also note that Zynq-7000 is listed on https://www.khronos.org/conformance/adopters/conformant-products#opencl ( OpenCL_1_0 ), hence the compatibility.
I am starting to create a QT application with sqlite for a hand held device. My Project Manager asks me to select an operating system (embedded linux) for the device (we are not considering android).
As in Desktop, are there many embedded-Linux distributions for devices?
If so, Which embedded linux I should consider?
You have multiple choices, but I will suggest the easier and - in my opinion - better two.
Buildroot - is a set of makefiles that lets you create your custom embedded distribution. Can take care of building the Linux
kernel, the toolchain and a barebox or U-Boot bootloader, too. Easily expandable and
with a practically zero learning curve. You have a fully working
system in a matter of hours.
Yocto - a fully fledged (and complicated) build system. Suggested over Buildroot when you need a LOT of packages/components
and may need flexibility in expanding the system directly on
premises. What you can do substantially depends on the "layers" (sets of rules for building things) available: you combine layers together to obtain your system. Has a steep learning curve but is used and directly
supported by multiple vendors (e.g.: Atmel, TI).
Anyway, unless you have more than good reasons, I strongly suggest the former.
There are several Linux distros to be used with ARM. Maybe you should consider Fedora ARM https://fedoraproject.org/wiki/Architectures/ARM
This is a difficult question to answer not knowing more about the project requirements (not just software requirements, but also non-functional ones as well) and capabilities of the platform.
Angstrom (based on OpenEmbedded) is another possibility for Linux.
I would challenge the assumption that the operating system must be Linux. Why? If time-to-market or having commercial support are important, you might be better off with commercial embedded or RT operations systems such as VxWorks or QNX.
There are also professionally supported Linux distros such as Montavista
Whilst free linux distros are, well, free, you are generally on your own and your team's time isn't free.
You can use Qt for embedded device , it’s fast and compatible with many hardwares and if your hardware is not supported, porting it to a new hardware is not so hard
plus it has special rendering system
I want to study and compare executable file structure of elf, SPARC and PA-RISC.
To perform the studies I want to install OpenSolaris on an Intel machine (Core2Duo).
But I got a basic doubt will it work at all ?
I know SPARC has its own assembly - grew in suspicion if it will work or is valid thought at all.
I was aiming to write some programs disassemble them and with some help of tools study the file structures.
I don't have any clue how to perform all this for HP-UX (PA-RISC); dont know any free OS for PA-RISC.
You won't be able to run Sparc or PA-RISC executables on an intel processor. However, if all you want to do is to analyse the structure of these executables, all you need is suitable development tools.
I haven't checked, but I suspect OpenSolaris comes with development tools capable of analysing Solaris/sparc executables out of the box. But even other toolchains can do that. For example, GNU binutils (specifically the BFD library they use) support many architectures, including Sparc and PA-RISC. (If you use GNU binutils, make sure you get a full version, perhaps labeled as “for cross-compilation”, e.g. binutils-multiarch on Debian or Ubuntu)
SPARC:
I have never installed OpenSolaris on anything. You might consider trying NetBSD: it runs SPARC machines at least as well as Solaris did, and it uses ELF format executables. The source code is freely available for study, too.
You will need to understand the ELF file format. I don't recall any particular document standing out back in the days when I wanted to understand ELF, and it looks like Google can offer a large number of web sites that will explain ELF. My advice on ELF is to write a program to read the ELF headers, and then dump them out in a readable text format, even though many such programs already exist.
You will also need a SPARC disassembler that understands ELF. I wrote one a long time ago, it will probably work reasonably well today. http://www.stratigery.com/elf_dis.tar.Z
You can download PDFs about SPARC here: http://www.sparc.com/specificationsDocuments.html I recommend the SPARC V8 and V9 architecture manuals.
PA-RISC:
This is a very odd architecture, with very little in the way of documentation. I believe that PA-RISC was Apollo Computer's (R.I.P) RISC architecture, then HP bought Apollo in 1990 or 1991. The stack grows down and the heap grows up, where just about everything else has it the other way around. It also has a segment register, but one that works differently than x86 segmentation.
HP is really the only place to find anything about PA-RISC.
There are ports for PA-RISC architectures of Linux, NetBSD and OpenBSD.
You cannot run code compiled for Sparc or PA-RISC on an x86 system, unless you use a full-fledge emulator. Qemu can emulate a Sparc-based machine, with enough accuracy for running a Linux operating system on it (but it will not be fast: Qemu must interpret all Sparc opcodes one by one, and this has a heavy overhead, so a fast PC from 2011 may perhaps yield the performance of a Sparc workstation from 1996). There is an ongoing project for adding PA-RISC support to Qemu but it does not seem to have reach any non-trivial level of usability yet.
Here's a candid admission first -- that I know zilch about RTOS or Embedded programming, so folks who know better may help me frame the query more appropriately.
What would be the minimal FOSS RTOS (or any OS for that matter) with support for TCP/IP, SSL, USB and some basic file-system for low-end ARM devices like Cortex-M3's ?
Have not ruled out something like ARM9/ARM7TDMI, so an RTOS that has "optional" MMU support, may be a major plus. We are at present dabbling with few uncertainities like precise processor, MMU/no-MMU, running completely head-less (no display), however I wanted to start a little ramp-up.
Would gladly answer counter questions to clarify the requirement.
I believe that eCOS has support for all you need and is scalable.
Alternatively you could build from a self-selected kit of parts; choosing independent RTOS, filesystem, USB, etc. From different sources, and integrating them yourself.
Prety straight forward, are the Intel compilers worth getting? I do mostly systems level and desktop work so I figure I might benefti. Can anyone with some more experience shed some light?
If you are on Windows, they do provide a nice speed boost over other compilers on Intel processors. There is a known behavior where they pick a very slow code path with non-Intel processors (AMD, VIA), and antitrust probes surrounding the issue.
If you use the thread building blocks or other features, you also risk tying your code to the Intel compiler long term as the functionality doesn't exist elsewhere.
GCC 4.5 on Linux is nearly on-par with the Intel compiler. There is no clear winner on that platform.
In the small experience I've had with intel compilers (C only), I would say their are vastly superior. Specifically the OpenMP library was much much faster than the open source version. "Worth it" depends on your situation though, they are expensive, but they are better IMO.
From the benchmarks I've seen, it does look like using the Intel specific compilers provide some performance/multithreading benefit over their Open Source alternatives.
if floating number precision is important to you then use Visual studio compiler and not intel compiler.
32 bit vs 64 bit application Can give you different result on calculation with Intel compiler. (checked).
Visual studio compiler result on 32 bit vs 64 bit will be same.
If you're comparing the numerical behavior of ICL vs. MSVC++ you must take into account the different behavior of the /fp: settings.
ICL /fp:source (less aggressive than default) is equivalent to MSVC /fp:fast (more aggressive than default).
Microsoft doesn't perform any of the optimizations which are enabled by ICL default. These include simd reductions (which usually improve accuracy, but by an unpredictable margin). ICL also violates the standard about parens by default. There still seems to be a controversy about whether to fix that by better performing means than /fp:source.