What are compiled simulators and Instruction Set Interpreter based Simulators? What is the difference between them?
Compiled simulators simply compile the code with the host machine's compilers and run it natively on the host. Instruction set interpreters simulate the code running on the actual machine, and the code is exactly the same as the real code -- compiled with the same compilers.
The iOS simulators are compiled simulators -- they simply compile the code with an x86 compiler instead of an ARM compiler. Thus it doesn't simulate everything, e.g., NEON instructions.
Related
I am trying to build a cross platform (vista, xp, mac, Linux).
I need to put the application in the USB drive formatted in FAT-32 and it should run on any OS computers.
Planning to use Java/JavaFx to do it.
Any advice how we can run on the multiple platforms.
Hi, Can anyone advice use of uber-jar for the above requirment. Would that be good fit.
A few things to take into consideration:
The USB must be formatted with a filesystem compatible with all the OS you need to work with.
A Java application would be able to run on any OS that is able to run Java, but each OS needs a different Java runtime. There's a Java runtime for Linux, one for Windows, one for OSX, etc.
My suggestion would be to define which OS you want to support and create launcher scripts for each one of them on the root of the USB. For instance you would have at least a couple like: myapp.cmd (for Windows), myapp.sh (for Linux), etc.
Additionally you may want to have different Java Runtimes in the same USB, so with the launcher scripts you execute your Java application running it with the corresponding JRE in the USB filesystem.
A twist in the launcher script would be to somehow check if the OS has already a JRE available (Like checking for a variable JAVA_HOME in the environment, or checking the output of "java -version") and act accordingly (although, running a Java application from your own JRE would be safer).
I'm a newbie in OpenCL.
Now I'm trying to compile one of the NVIDIA OPENCL SDK CODE SAMPLES named "OpenCL Bandwidth Test" linked here (https://developer.nvidia.com/opencl).
In this sample, a file named "oclBandwidthTest.cpp" is included.
And this file consults "oclUtils.h" and "shrQATest.h", so I added these two files path in makefile.
But when I try to compile it it still says "undefined reference to 'shrLog' 'shrLogEx' 'oclErrorString'" ... (too many).
I must do it until tomorrow but from last friday I'm still bound it.
I'm working on Ubuntu 12.04, I already installed SDK 4.2 and device driver.
Let me know what I must include (header file or library) in makefile.
II.B. Linux Installation Instructions
The OpenCL SDK samples in the NVIDIA GPU Computing SDK require a GPU with CUDA Compute
Architecture to run properly. For a complete list of CUDA-Architecture compute-enabled GPUs,
see the list online at: http://www.nvidia.com/object/cuda_learn_products.html
The OpenCL applications in the NVIDIA GPU Computing SDK require version 258.19 of the NVIDIA
Display Driver or later to run on 32 bit or 64 bit Linux. This required driver is made available to
registered developers at: https://nvdeveloper.nvidia.com/login.asp?action=login
Please make sure to read the Driver Installation Hints Document before you
install the driver: http://www.nvidia.com/object/driver_installation_hints.html
Uninstall any previous versions of the NVIDIA GPU Computing SDK
Install the NVIDIA GPU Computing SDK by running the installer provided for your OS.
The default installation folder for the OpenCL SDK is:
Linux
$(HOME)/NVIDIA_GPU_Computing_SDK/
In the following we will refer to the path that the SDK is installed into as .
Build the 32-bit or 64-bit (match the installation OS), release and debug
configurations, of the entire set of SDK projects and utility dependencies.
a. Go to /OpenCL
b. Build:
release configuration by typing "make".
debug configuration by typing "make dbg=1".
Running make at the top level first builds the shared and common utility libraries used by
the SDK samples (these libraries are simply for convenience and are not part of the OpenCL
distribution and are not required for your own OpenCL programs). Make then builds each
of the projects in the SDK.
Run the examples from the release or debug directory located in
/OpenCL/bin/linux/[release|debug].
Most of the SDK applications output messages to a console window that are of interest from the
standpoint of understanding basic OpenCL program flow, and several of the applications generate
graphics output in a separate OpenGL window.
Many of the SDK applications present some timing information useful for obtaining an
overall perspective of program structure and flow and the time required for setup and execution of
significant functions. The SDK example code, however, has generally been simplified for instructional
purposes and is not optimized. Advanced optimization techniques are beyond the scope of this SDK, and
any timing information presented by the samples is not intended for such usage as benchmarking.
All of the applications additionally log all the console information to a session log file in the
same directory as the executables. Those files are named clearly after the name of the sample app,
but with a .txt extension.
For convenience, the Makefile in /OpenCL can be used to execute all
SDK samples sequentially by typing "make runall" or "make dbg=1 runall".
I am involved in development of a large cross platform project that build for Windows, Linux, and Mac OS X. The build for the software is configured with CMake.
The CMake scripts have been designed to configure successfully for Visual Studio on Windows, and Makefiles are currently used for building on Linux and Mac OS X.
Pretty much all of the development for the project so far has been done with people working on Windows, and a little bit of work on Linux. I am interested in developing for the project using Xcode 4.6 on a Macintosh running Mac OS X 10.7, and I have encountering problems as the CMake files do not seem to configure properly for that development environment.
For non-windows platforms many custom commands have been written to try to configure things such as copying needed files or setting environments that are needed for certain operations such as running unit tests during the build process.
It seems that because Xcode is an integrated development environment simliar to Visual Studio is has this concept of a build configuration, and when software gets build output files in up in a directory path that includes that configuration concept (i.e. many build files end up in a path that ends with folder named something like Debug, Release, etc.)
CMake is supposed to have support for dealing with this build configuration concept and the mechanism utilized work well for Visual Studio. That do no seem to work for Xcode. For example our build engineers have design CMake scripts so that for Windows, many path and whatnot are configured using the CMAKE_CFG_INTDIR value which helps to qualify the build configuration.
The use of CMAKE_CFG_INTDIR is not working for Xcode as the script for Macintosh were written with Makefiles in mind which don't really have the build configuration concept. The use of CMAKE_CFG_INTDIR within custom commands used to configure things fails on the Macintosh as the value resolves to $(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME). This values are not define when the custom commands are run, so values are not set properly and build operations fail.
It is unclear what is needed so that the system can successfully configure for Xcode. Searching on the Internet so far has not yielded insight into what should be used to make sure that build configuration can be successful. What resources are available that would help in figuring out how to configure this project to build with Xcode?
If you're talking about custom commands set using add_custom_command, then you should prefer "generator expressions" to avoid issues regarding per-configuration build directories. From the docs for add_custom_command:
Arguments to COMMAND may use "generator expressions" with the syntax "$<...>". Generator expressions are evaluated during build system generation to produce information specific to each build configuration.
For example, the build directory for a target called "MyExe" could be referred to as $<TARGET_FILE_DIR:MyExe>
Generator expressions are available in a few CMake commands, not just add_custom_command.
If you have more specific problems, it's maybe worth asking further question(s) with the relevant details.
First of all, I'm very new to programming.
I have a build a program using Xcode 4 on Snow Leopard.
Architecture of the project is set to "Standard (32/64-bit intel)"
Afterwards I have exported the executable file to a UNIX computer for running.
ssh to that computer
Typing ./programname in the terminal (Of the UNIX computer) gives the following response:
Exec format error. Wrong Architecture.
The program runs just fine on my Mac laptop.
When you compile a program it will (*) be compiled for a specific platform and a specific operating system. It will also most likely be compiled against a specific set of libraries. Usually those parameters are exactly those of the computer doing the compilation (the other cases are called cross-compilation).
In other words: compiling a program on a Mac will produce a binary that runs only on a Mac (unless, again, you're doing cross-compilation). Your UNIX system (which UNIX, by the way?) has a different operating system, different libraries and probably even a different CPU architetcture.
Somewhat related: Apples advertised (or used to advertise) Mac OS X as a UNIX. While Mac OS X is certainly a UNIX-class operating system, that doesn't mean that it's binary compatible with every other UNIX-class OS out there.
* almost always, with the exception of systems designed to avoid this (e.g. Java)
Programs compiled by XCode will only run under MacOS X. Unless the "UNIX computer" in step 2 is running MacOS, the program will not be able to run.
I want to use #include statements in my OpenCL kernels but it appears Apple's OpenCL compiler caches kernels, so if you change the contents of an included file but not the file doing the including, the program will not change between runs.
I've coded up an example which illustrates this:
http://github.com/enjalot/adventures_in_opencl/tree/master/experiments/inc/
If you compile and run, it should work fine. Then if you comment out the struct definition in inc.cl it will still run just fine (or change anything in lvl2.cl)
Using the NVIDIA compiler on Ubuntu you get the expected behavior.
So is there someway to force clBuildProgram to recompile the kernel?
I got an answer from the perfoptimization-dev#apple.com mailing list
sudo killall cvmsServ
Doesn't seem very graceful, but oh well