[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added Version|unspecified |D2 --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #14 from Manu turkey...@gmail.com --- Awesome work, super useful stuff. Thanks again! :) Any chance on the other dustmite suggestion? :P --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Rainer Schuetze r.sagita...@gmx.de --- Released in https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.41 Thanks for the nice idea! --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #11 from Rainer Schuetze r.sagita...@gmx.de --- Oh yeah, and the other thing was that every time I hit Compile and Disassemble, it prompts me if I want to reload the file. That's a bit annoying. Yeah, I noticed that, too, though it does not seem to happen every time. I'll have to figure out how to avoid that... I think I've solved this, see https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.41-beta4 --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #12 from Manu turkey...@gmail.com --- Confirm fixed. This is awesome :) --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #10 from Rainer Schuetze r.sagita...@gmx.de --- You can assign a hotkey to the command in the global keybord settings of VS. Search for VisualD.CompileAndDisasm. I have not predefined hotkeys to avoid breaking other people assignments. You can assign Ctrl+F7 just as well, though that might break compiling C++ files. Background compilation might be possible, but I avoided that for now to not cause spurious delays during editing due to the compilation. There will also be many failing builds. Oh yeah, and the other thing was that every time I hit Compile and Disassemble, it prompts me if I want to reload the file. That's a bit annoying. Yeah, I noticed that, too, though it does not seem to happen every time. I'll have to figure out how to avoid that... --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #8 from Manu turkey...@gmail.com --- Okay, I've played with this for a bit. A few little things immediately jump out at me: * Compile and Disassemble doesn't seem to have a hotkey. * There's no convenient way to refresh the view. On the second point, I think there are 2 good options: Either VisualD silently rebuilds the source file in the background actively while you edit, and when compilation is successful, update the disassembly view with the new code. (realtime interactive!) Alternatively, a simpler solution would be to automatically update the disassembly when the user rebuilds the source file manually (Ctrl-F7). I guess a 3rd option would be to assign a hotkey, and the user can just press that again. I'd have to say I'd be more excited by either of the first 2 though, since I have habit formed around Ctrl-F7 to test for compile errors as I'm typing, and updating the disassembly at the same time would be kinda nice. --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #9 from Manu turkey...@gmail.com --- Oh yeah, and the other thing was that every time I hit Compile and Disassemble, it prompts me if I want to reload the file. That's a bit annoying. --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #6 from Manu turkey...@gmail.com --- (In reply to Rainer Schuetze from comment #5) While DMD output would of course be useful, I'm not sure there's as much value analysing DMD output because it's a pretty average codegen anyway. I doubt many people would optimise for DMD? Unfortunately, Win32 support seems pretty incomplete with both LDC and GDC, but my main D project Visual D is a plugin into a 32-bit application, so has to be built with dmd. Also, work on the GC will also be measured with dmd first, and preciseness is most important for 32-bit applications, so optimizing against it is also necessary, though sometimes frustrating. As a result, I implemented support for OMF and CV8, too. You might want to give it a try: https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.41-beta3 Oh wow, that was fast! :) I'm checking out now. So, does that mean only 32bit is supported, or is 64bit supported too? DMD-Win64, MSVC-LDC, both (general COFF support)? Documentation is here: http://rainers.github.io/visuald/visuald/CompileCommands.html --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #7 from Manu turkey...@gmail.com --- Sorry, stupid question, I read the docs. Very fine work! Thanks again! --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #5 from Rainer Schuetze r.sagita...@gmx.de --- While DMD output would of course be useful, I'm not sure there's as much value analysing DMD output because it's a pretty average codegen anyway. I doubt many people would optimise for DMD? Unfortunately, Win32 support seems pretty incomplete with both LDC and GDC, but my main D project Visual D is a plugin into a 32-bit application, so has to be built with dmd. Also, work on the GC will also be measured with dmd first, and preciseness is most important for 32-bit applications, so optimizing against it is also necessary, though sometimes frustrating. As a result, I implemented support for OMF and CV8, too. You might want to give it a try: https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.41-beta3 Documentation is here: http://rainers.github.io/visuald/visuald/CompileCommands.html --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de --- My current idea is to abuse the Code Definition Window to show assembly instead. The assembly would be a file produced by compiling and dumping the file after saving it (or maybe after some new command invoked by a hotkey). The caret location inside the dump file would update according to a line number change in the editor. Short of source, at very least, there needs to be symbol names at the header of blocks of code. There are, but I'd like to avoid having to figure the actual mangled D symbol from the source (though feasable). Using debug line numbers seems better for navigating larger functions. Do the GNU tools make this easier? The objdump tools that come with GDC or LDC don't produce really helpful results (and don't work on OMF and MS-COFF). When compiling to assembly, GDC adds location information which could be used, LDC does not (I might be missing some command-line switch, though). DMD can't build to asm anyway, so dumping an object file will be necessary anyway. Maybe I can rip some code from cv2pdb, it can read line number information from executables with CV4 and DWARF debug information. I'll have to add CV8 support for Win64 though. --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #4 from Manu turkey...@gmail.com --- (In reply to Rainer Schuetze from comment #3) My current idea is to abuse the Code Definition Window to show assembly instead. The assembly would be a file produced by compiling and dumping the file after saving it (or maybe after some new command invoked by a hotkey). The caret location inside the dump file would update according to a line number change in the editor. This sounds like an awesome start! Short of source, at very least, there needs to be symbol names at the header of blocks of code. There are, but I'd like to avoid having to figure the actual mangled D symbol from the source (though feasable). Using debug line numbers seems better for navigating larger functions. Seems very reasonable, probably better. If the caret is able to follow the cursor in the editor window, then we'll have a really useful tool I think. Do the GNU tools make this easier? The objdump tools that come with GDC or LDC don't produce really helpful results (and don't work on OMF and MS-COFF). When compiling to assembly, GDC adds location information which could be used, LDC does not (I might be missing some command-line switch, though). DMD can't build to asm anyway, so dumping an object file will be necessary anyway. So... as I see it, with the DMD compiler landscape as it is, the most important compiler in this case is LDC. If you're doing performance work for Windows, I think it's fairly safe to say you're using LDC, since it's the only compiler that can link against other VS code, and produces high-performance output. While DMD output would ofcourse be useful, I'm not sure there's as much value analysing DMD output because it's a pretty average codegen anyway. I doubt many people would optimise for DMD? The real money is on analysing the output from LDC, since for optimised builds, I think that's the compiler that will typically be used for Windows codegen, no? Maybe I can rip some code from cv2pdb, it can read line number information from executables with CV4 and DWARF debug information. I'll have to add CV8 support for Win64 though. That sounds like a lot of work. I kinda hoped this would be a relatively simple feature with tools already available, the trouble being to integrate it into the VS UI/menu. But yeah, I think you can clearly see the problem space, and it sounds like you have some personal interest in this too, so I'll leave it to your good judgement from here. I'm super excited you're interested in this idea! :) Thanks again! --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de --- Interesting idea. That would really be helpful for immediately seeing what the optimizer is able/unable to do. I use the Compile and Debug command sometimes with unittests and option -main, though that still needs you to set a breakpoint somewhere and wait for the debugger to start. Getting the disassembly of an object file with obj2asm/dumpbin is possible, but syncing with the source needs to read debug information. This can be rather annoying. --
[Issue 14497] Disassembly view
https://issues.dlang.org/show_bug.cgi?id=14497 --- Comment #2 from Manu turkey...@gmail.com --- Yeah, requiring that the program link is annoying, and if the program is big (mine are), then the build times can get long, and iteration is slow. Short of source, at very least, there needs to be symbol names at the header of blocks of code. It must be easier to populate the assembly with symbol name headers than full source? As long as you can identify the start and end of the function you're interested in, that will give an 80% solution satisfying the majority if simple cases. Do the GNU tools make this easier? I imagine there must be tools in the GCC/Clang (GDC/LDC?) suite that do the full job? It might be easier to start there? Also be useful in that you could disassemble non-x86 arch-es too. --
