Microsoft's open source DirectX Shader Compiler describes the format of a new intermediate language (IL) for HLSL shaders called DXIL.
The documentation makes reference to a converter from the previous HLSL IL, called DXBC, to the new DXIL: https://github.com/Microsoft/DirectXShaderCompiler/blob/master/docs/DXIL.rst.
However, I am unable to find the referenced dxbc2dxil tool, or any other way to convert DXBC to DXIL. I have tried passing DXBC files to the various tools in the DirectX Shader Compiler project, but none have accepted plain DXBC as input.
Is there currently a way to obtain DXIL from old DXBC?
My understanding of this documentation is that Microsoft will take charge of only providing DXIR to the vendor's drivers in the future. The DXBC2DXIL is a Microsoft internal only module.
To my knowledge, nothing in the DirectX Shader Compiler repository has the capability to translate a DXBC IL to a DXIL.
See this project for a working hack: https://github.com/Nukem9/Dxbc2Dxil
They use "dxilconv.dll" from win10 to create an instance of the undocumented DXBC->DXIL converter.
Related
Where can I find vala binding for libgimp?
Or, can someone point me to clear (complete) instructions to get it from gimp source code? The instructions at https://wiki.gnome.org/Projects/Vala/Bindings are really too light for me.
There are no Vala bindings for GIMP at this time.
GIMP has had it "cross-process", "cross-language" procedure calling for long before gobject introspection (GIR) was in place, and that is exposed as the Procedural Database (PDB), which can be browsed at GIMP's help menu.
However, these PDB calls have never been re-written to take advantage of GIR, and can not be accessed in this way. There have been over the years several language bindings for GIMP using the PDB, all of it but for Python's and Script-fu had fallen unmaintained over the years. GIMP-Perl was long lived, and used to even be packaged in some Linux distributions. Other than that, there have been at least experimental bindings for Java and Ruby.
On the other hand, all image and pixel manipulation being made in current GIMP (the 2.9 development branch, soon to become GIMP 2.10) is made through GEGL (Generic Graphics Library). GEGL is a modern gobject library that can be used with gobject introspection bindings, and will work from Vala using the instructions on the page you linked in the question.
I want to know if I download the OpenCV2.4.10, is there the need of JavaCV 0.10 or not, because in the extracted folder of OpenCV2.4.10 inside \OpenCV\build\java there is a Jar file named opencv-2410.jar. I am using Java Language to use OpenCV library. But I also saw JavaCV which can be found at http://bytedeco.org website, when I downloaded all Jars, here I also found named opencv.jar file. Now I don't know what is the deference between them, in Java Language which one is better to use. If use OpenCV2.4.10 is need to JavaCV 0.10? and if use JavaCV 0.10 is need to OpenCV2.4.10? or both of them can be independent used? the If anyone know about this please tell me, Thanks in advance!!
OpenCV library is written in C/C++. Java wrappers are written so that, C/C++ code could be invoked with JNI. JavaCV( unofficial ) and OpenCV( official ) are completely independent java wrappers to use OpenCV from Java.
I suggest you use OpenCV downloaded from offical opencv.org website or from OpenCV github repo(1). Here java wrappers are auto generated during build and so all C/C++ OpenCV functions will have corresponding Java wrappers. This way, every new release or even development versions of OpenCV could be used from Java. This also helps with reading documentation as function parameters matches nearly.
JavaCV is a popular Java wrapper for OpenCV maintained by independent developer(s). It also add helper classes for easier usage. But here, wrappers are not auto generated and so you will need to wait for developers to update to newer versions.
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.
Can anybody tell me how to find or create a binding to OpenCV for GNAT?
I want to use Ada2005 to implement some program with OpenCV (1.0 or 2.X),
but I don't know how. Can anybody teach me how to do it?
Teaching you how to create a binding to a complex library is beyond the scope of StackOverflow, but you might start with this tutorial. Then study the relevant GNAT library sources, e.g. Ada.Numerics, and other existing Ada bindings. Among others, Ada 2005 Math Extensions and An Ada binding to the GNU GMP and MPFR Multiple Precision libraries are exemplary as well as accessible.
If you have Gnat Pro (and presumably a support contract from ACT), I think you can get a binding generator from them.
In the comments, Simon Wright pointed out that you can get this binding generator from GCC 4.6.0., which is the official (although sometimes a bit behind) GCC distribution. I generally suggest folks who aren't paying ACT customers get their compiler from GCC, rather than the GNAT GPL version from ACT.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Any way to use some Scala for iOS coding?
Would it be possible to use the Scala.NET implementation, and then MonoTouch to run Scala code on an iOS device?
I have not been able to find a page with binaries of Scala.NET that I can test, so the following are just general guidelines as to what you can do with MonoTouch and .NET languages.
MonoTouch can run any ECMA CIL that you feed to it. When you consider using a new language with Monotouch, there are two components that come into play:
Tooling for the IDE
Runtime for the language
The tooling for the IDE is the part responsible for starting the builds, providing intellisense and if you use Interface Builder, it creates a set of helper methods and properties to access the various outlets in your UI. As of today, we have only done the full implementation for C#. What this means for an arbitrary language is that you wont get the full integrated experience until someone does the work to integrate other languages.
This is not as bad as it sound, it just means that you need to give up on using XIB files from your language and you probably wont get syntax highlighting and intellisense. But if you are porting code from another language, you probably dont need it. This also means that you would probably have to build your assembly independently and just reference that from your C# project.
So you compile with FoobarCompiler your code into a .dll and then reference in your main C# project.
The language runtime component only matters for languages that generate calls into a set of supporting routines at runtime and those routines are not part of the base class libraries (BCL). C# makes a few of those calls, but they are part of the BCL.
If your compiler generates calls to a supporting runtime that is not part of the BCL, you need to rebuild your compiler runtime using the Mono Mobile Profile. This is required since most runtimes target a desktop edition of the BCL. There are many other API profiles available, like Silverlight, Mono Mobile, Compact Framework and Micro Framework.
Once you have your runtime compiled with our core assemblies, then you are done
If you had read the MonoTouch FAQ, you would have noticed that it currently supports only C# and no other CLR languages.
Binaries for the Scala.NET library and the compiler can be obtained via SVN, in the bin folder of the preview:
svn co http://lampsvn.epfl.ch/svn-repos/scala/scala-experimental/trunk/bootstrap
Bootstrapping has been an important step, and ongoing work will add support for missing features (CLR generics, etc). All that will be done.
For now we're testing Scala.NET on Microsoft implementations only, but we would like our compiler to be useful for as many profiles and runtime implementations as possible.
A survivor's report on using Scala.NET on XNA at http://www.srtsolutions.com/tag/scala
Miguel Garcia
http://lamp.epfl.ch/~magarcia/ScalaNET/