What should I feed into "nvdisasm --binary SM52 " command?

Hi all,
The nvidia documentation said “the input file is assumed to contain a raw instruction binary, that is, a sequence of binary instruction encodings as they occur in instruction memory”.
What dose this “raw instruction binary” actually mean?
Could anyone give me an example?
And how could I generate such kind of file?


The documentation states precisely what kind of file it is: A sequence of binary instructions, nothing else. This is in contrast to an object file, for example, which contains not just a sequence of binary instructions, but auxilliary information such as stating addresses of functions or global data, where such information may be used in linking of objects files into executable, for example. Like many other platforms, CUDA uses ELF format (https://en.wikipedia.org/wiki/Executable_and_Linkable_Format) for object files.

I am not aware of any part of the CUDA toolchain that produces a raw binary of this nature. The typical situation where a raw binary would occur is if you simply copy instruction memory contents and save it to a binary file. I highly doubt there is a need for this in the regular course of programming with CUDA. I have been using CUDA for as long as it has existed (about 13 years) and have not needed this functionality yet.

What prompted you to ask the question? I sense there could be an XY problem here.

Hi njuffa,
Thanks for your reply.
I tried to generate this kind of file myself with instructions dumped from cuobjdump (used a script convert hexadecimal code into binary, then wrote instructions to a file).
But I can only get the following lines,when fed generated file into nvdisasm.

.headerflags    @"EF_CUDA_SM52 EF_CUDA_PTX_SM(EF_CUDA_SM52)"

I’m sure I used instructions of SM52. So I opened this thread to check if I input a correct file.

Actually I don’t have a problem in front of me, I just want to know more about instructions of Maxwell architecture which I believe will help me to write more efficient kernels. :D


Given that cuobjdump --dump-sass already gives you a disassembly of the instructions, what more do you hope to gain from using nvdisasm? And why would you want to feed nvdisasm a raw binary instead of a proper .cubin object file produced by nvcc?

the way i learned sass is

  1. ptx manual: http://docs.nvidia.com/cuda/parallel-thread-execution/
  2. http://docs.nvidia.com/cuda/cuda-binary-utilities/#instruction-set-ref
  3. https://github.com/laanwj/decuda
  4. read wiki of asfermi project: https://github.com/hyqneuron/asfermi/wiki
  5. read manual of kepler sass: https://hpc.aliyun.com/doc/keplerAssemblerUserGuide
  6. there is also maxas, but its docs doesn’t describe commands: https://github.com/NervanaSystems/maxas


The tool chain doesn’t produce the binary file you are describing but you can get to the binary image of the kernel (which is what I suspect you want to do) thru the cupti tools. Just look at the sass_source_map example.