In the Vulkan SDK there are two different tools that allow to compile HLSL to SPIR-V: dxc and glslangValidator.
Why do we need two? What are the differences? How do I decide which one to use?
For HLSL shaders you should use DXC. DXC is Microsoft's official shader compiler and it's support for HLSL is far more complete than the one in glslangValidator. glslangValidator is mainly used for GLSL and has very limited HLSL support.
Related
I saw the two projects are quite related, but what are the differences between them? The official webpage doesn't tell much about it.
I know that ABI (Application Binary Interface) is used to provide low-level binary interface among different platforms. So is libc++abi used to provide different implementations for different platforms, and general interface for libc++?
Would be better go give some specific example, e.g. what are included in libc++abi and what in libc++.
Thanks.
The Application Binary Interface, or ABI for short, is intended to provide certain low level functions from which to build the C++ standard library. It is a supporting library that is a separate component from the actual standard library. Along with libcxxabi, you may also come across Pathscale's libcxxrt or GCC's libsupcxx.
On the other hand, libc++ is an implementation of the C++ standard library that can be built using either of the 3 mentioned ABIs.
In ISIS design tool there are many options of compilers, as well as microcontroller families and their variants with which we can perform compilation and simulation in the Proteus IDE.
However, although it is possible to install other compilers that are not configured by default, there is no option for many other compilers, such as for example the PIC32 from Microchip.
Is there any way to do that ?
I am a bit confused since you mentioned binary image in the question title and talks about compilation in the body.
Proteus does support loading pre compiled images in hex of elf format.
I'd like to know if there are other compilers than gcc and clang that provide something like an -march=native option, and if so, what that option is. I already understand from another question (Automatically building for best available platform in visual c++ (equivalent to gcc's -march=native)) that Microsoft's compilers do not have that option (unless it's implied in the option that activates the SSE2 instruction set, up to and excluding AVX and higher at least).
The use case is simple: provide a cmake set-up and thus the user with an option to activate and build with support for all the "intrinsics" his or her CPU supports. We currently have detection logic for the actual intrinsics we target (e.g. SSE4.2 and/or PCLMUL on x86) but that logic will probably get very complex when more platforms and compilers have to be taken into consideration. Simplifying them could lead to situations where the compiler starts to use unsupported instruction sets outside of the intended places protected by runtime checks.
Currently, the Microsoft Visual C++ compiler doesn't provide equivalent flags to march=native. You'll have to figure out the appropriate flags manually or using a script before building the code.
Regarding the Intel C++ compiler, the xHost and QxHost flags have basically the same purpose.
There are lots of oop languages, but I couldn't find any that has conveniences like garbage collection, but compiles natively to machine code. Sort of like between C and java/c#. One interesting language I found was Vala, but that's limited to the GNOME platform and is not that well-known
Go is probably closest.
But why on earth do you want it natively compiled anyway?
JIT compilation of portable bytecode has proved to be an extremely effective strategy. It compiles down to native code at runtime (so you get up to the performance of native code after the first few iterations) and it avoids the issues of having to build and manage platform-specific compiled binaries.
Are you thinking about C++? That is in high usage and can be compiled on nearly any (major) platform.
In the case you want to use an oo language that compiles down to native code you will "always" have to use header files and stuff as the elf format doesn't support oo (There is no class information in elf).In case you want to use classes from external libs you need to make the compiler aware somehow about the fact that there are classes, functions, etc. that are declared outside of your project. In C++ this is solved by the use of header files. So that's, I think, a major drawback in native object oriented languages. To resolve that issue a few tweaks would need to be made to elf/loader/linker in order to support the kind of features (like "linking" against "classes") you might expect. Even though mechanism for garbage collection could be implemented even in native languages. But that seems no good for os implementation.
There are C++ libs to do that for userspace apps like:
Boehm collector
Smart pointers
Suppose I have a software and I want to make cross-plataform plugins. You compile the plugin for a virtual machine, and any platform running my software would be able to run this code.
I am wondering if it is possible to use LLVM interpreter and bytecode for this purpose. Also, I am wondering if does make sense using LLVM for this purpose instead of something else, i.e. is it what LLVM was made for?
I'm not sure that LLVM was designed for it. However, I doubt there is anything that hasn't been done using LLVM1
Other virtual-machines based script engines are specifically created for the job:
LUA is very popular
Wikipedia lists some other Extension/embeddable languages under the Scripting language entry
If you're looking for embeddable virtual machines:
IKVM supports embedding JVM and CLR in a bridged mode (interoperable)
Parrot supports embedding (and includes a Python interpreter; mind you, you can just run python bytecode images)
Perl has similar architecture and supports embedding
Javascript supports embedding (not sure about the architecture of v8, but I guess it would use a virtual machine)
Mono's CLR engine supports embedding: http://www.mono-project.com/Embedding_Mono
1 including compiling c++ information to javascript to run in your browser...
There is VMIR (https://github.com/andoma/vmir) which is a LLVM bitcode interpreter / JIT engine that's intended to be embedded into other apps.
Disclaimer: I'm the author of it and it's still work-in-progress but works reasonable well.
In theory, there exist a limited subset of LLVM IR which can be portable across various platforms. You shall not specify alignments, you shall not bitcast pointers to integral types, you must avoid intrinsics, etc. Which means - you can't immediately use a code generated by a stock C compiler (llvm-gcc, Clang, whatever), unless you specify a limited target for it and implement sanitising LLVM passes. Another issue is that the bitcode format from different LLVM versions is not guaranteed to be compatible.
In practice, I would not go there. Mono is a reasonably small, embeddable, fast VM, and all the .NET stack of tools is available for it. VM itself is pretty low-level (as long as you do not care about the verifyability).
LLVM includes an interpreter, so if you can build this interpreter for your target platforms, you can then evaluate LLVM bitcode on the fly.
It's apparently not so fast though.
In their classic discussion (that you do not want to miss if you're a fan of open source, LLVM, compilers) about LLVM vs libJIT, that has happened long before LLVM became famous and established, the author of libJIT Rhys Weatherley raised this particular issue, he stated that LLVM is not suitable to be embedded, while Chris Lattner, the author of LLVM stated that otherwise, it is modular and you can use it in any possible fashion including embedding only the parts you need.