We already have:
- Visual Basic
- Visual C++
- Visual C#
Why there is no Visual Assembly? Is it worth making it?
|
We already have:
Why there is no Visual Assembly? Is it worth making it? |
|||||||||||||||||||||
|
|
In the big picture, If N is the number of people writing direct assembly code, then 0*N is a good approximation of the number of those folks who care about a visual way of doing it. You could do it (Auto generated code / debug trace support / Intellisense!) - I doubt you will find users enough to support the system. MS got into the whole Visual * thing to enable easier programming. Assembly and easy don't go well together. In terms of debugger support etc., these already exist. |
|||||||
|
|
You can program in assembly in Visual Studio .NET IDE. |
|||
|
|
|
Well, there isn't really any point in it existing. First off, the Visual * family uses the .NET runtime for operation (C++ can be an exception I believe). Assembly is at the lowest level for programming. It is a direct representation of the opcodes of a processor. there isn't a point running assembly using the .NET runtime because the .NET runtime has a slower execution speed than true low-level assembly, and so would assembly run on the .NET runtime. |
|||||||||||||
|
|
The Visual family still has plenty of unmanaged code in it's make up so isn't pure .Net as yet and in that guise an IDE with some of the capabilities of Visual Studio but for x86 assembly language development isn't completely absurd. The thought of it have drag-and-drop development is somewhat challenging. I've not used C++ in VS for some time but I'd expect that it probably still has the |
|||
|
|
|
To be honest, I can't see why anyone would want Visual assembler. Lack of demand would be a good reason not to do it. However, if someone went and did some market research to discover it was a desirable product, then maybe the idea could be revisited if the demand was worth the effort. Personally if I was in the mood for writing assembly code, I think I'd do it directly and forget about using a Visual product for it. In fact - I may lack the imagination - I really can't see how you'd do it. |
|||
|
|
|
No point. The .NET JIT will almost certainly compile "hotspots" in your code down to far more efficient assembly than you could possibly write. In fact, I would wager that in 99% of the cases where it matters, the .NET JIT would generate better assembly than the people who wrote the .NET JIT could write. The reasons for this are that
Since a good JIT will probably out-perform the majority of hand-written assembly while retaining portability for the programmer (as opposed to the JIT writers, who would have to write an implementation for each architecture/os combination), the only reason to still use assembly is in kernel development etc., or if you absolutely need to squeeze the very last bit of performance out of your code and have benchmarked and proven that a JITted high-level language version of the code just won't cut it. Note that most existing JITs will not quite outperform well-tuned hand-written assembly (they'll get pretty close though), but it's quite likely that in the (near) future, they will. EDIT: To see exactly what can be accomplished by a good JIT even in a traditionally slow language like JavaScript, check out http://bellard.org/jslinux/ . It's an x86 emulator running Linux written entirely in JavaScript. You'll need Firefox 4.0+ for it to work since it uses the JS typed array specification which is only available in Firefox (it's available in Chrome too, but the latest Chrome seems to have introduced bug(s) that prevent the emulator from working correctly). |
||||
|
|
|
If there was a need for Visual Assembly in the market, someone would have already made a commercial suite, another smart guy would have made an OSS clone and another three or four similar, altough half-baked products would have emerged. That's why no Visual Assembly. |
|||||||||
|
|
Also there is GSS Visual Assembler for MASM32 and TASM, includes integrated debugger. |
|||||
|