Why no 'Visual Assembler"?

  • Thread starter Thread starter Peter Anthony
  • Start date Start date
P

Peter Anthony

There are times it would be good to be able to write assembly code to
integrate with other VS languages, such as VS C++ .NET. For example, I might
want to write a REALLY fast algorithm that does CALCULATIONS only and
bypasses any overhead imposed by the compiler.

Is inline assembly still possible? Wouldn't a Visual Assembler language make
some sense (although the 'visual' is only to imply compatibility and
seemless integration into other Visual languages)?
 
Peter Anthony said:
There are times it would be good to be able to write assembly code to
integrate with other VS languages, such as VS C++ .NET. For example, I
might want to write a REALLY fast algorithm that does CALCULATIONS only
and bypasses any overhead imposed by the compiler.

Is inline assembly still possible? Wouldn't a Visual Assembler language
make some sense (although the 'visual' is only to imply compatibility and
seemless integration into other Visual languages)?
Click to expand...

I'm pretty sure x86 inline assembler is still alive and kicking in the
latest VC++, although I seem to remember that x86_64 might not be. I'd also
think that inline assembly now recognizes more instructions than ever
before.

However, you're better off writing very simple C code (register transfer
style) and let the optimizer run, it will probably generate better machine
code than you. Humans can keep track of register spills pretty effectively
but when you add pipelining, branch prediction, cache associativity, and a
whole bunch of other factors, instruction costs are not constant and there's
no way a programmer can optimize them all in a reasonable amount of time.
 
I'm pretty sure x86 inline assembler is still alive and kicking in the
latest VC++, although I seem to remember that x86_64 might not be. I'd also
think that inline assembly now recognizes more instructions than ever
before.

However, you're better off writing very simple C code (register transfer
style) and let the optimizer run, it will probably generate better machine
code than you. Humans can keep track of register spills pretty effectively
but when you add pipelining, branch prediction, cache associativity, and a
whole bunch of other factors, instruction costs are not constant and there's
no way a programmer can optimize them all in a reasonable amount of time.
Click to expand...
It is also often true that spending the same time working on the
design of the program data flow and algorithms yields far better
improvements that trying to hand craft assembler code.

Besides, "real men" don't need Visual tools. Edlin is good enough for
us!
 
Larry Smith said:
True, but vim is good enough, and it's not really any less arcane.
Click to expand...

I was a fan of "Brief" myself many moons ago but I understand there's a Vim
plugin that can emulate it.
 
Peter Anthony wrote:
:: There are times it would be good to be able to write assembly code
:: to integrate with other VS languages, such as VS C++ .NET. For
:: example, I might want to write a REALLY fast algorithm that does
:: CALCULATIONS only and bypasses any overhead imposed by the
:: compiler.
::
:: Is inline assembly still possible? Wouldn't a Visual Assembler
:: language make some sense (although the 'visual' is only to imply
:: compatibility and seemless integration into other Visual
:: languages)?

If you have the full package - Professional Edition - VS does include
an assembler. Just add a .asm file to your project and compile!

It is just that hardly anybody uses it, because it is *extremely* hard
to outsmart the compiler. If you can shave more than one or two asm
instructions from a compiled function, you are at the Guru level !


Bo Persson
 
Bo Persson said:
Peter Anthony wrote:
:: There are times it would be good to be able to write assembly code
:: to integrate with other VS languages, such as VS C++ .NET. For
:: example, I might want to write a REALLY fast algorithm that does
:: CALCULATIONS only and bypasses any overhead imposed by the
:: compiler.
::
:: Is inline assembly still possible? Wouldn't a Visual Assembler
:: language make some sense (although the 'visual' is only to imply
:: compatibility and seemless integration into other Visual
:: languages)?

If you have the full package - Professional Edition - VS does include an
assembler. Just add a .asm file to your project and compile!

It is just that hardly anybody uses it, because it is *extremely* hard to
outsmart the compiler. If you can shave more than one or two asm
instructions from a compiled function, you are at the Guru level !
Click to expand...

It's easy to shave *instructions*. But fewer instructions doesn't mean
smaller or faster code. And while the size of each instruction can be
known, the speed is dependent on far too many factors to consider by hand.
 
Peter said:
There are times it would be good to be able to write assembly code to
integrate with other VS languages, such as VS C++ .NET. For example, I might
want to write a REALLY fast algorithm that does CALCULATIONS only and
bypasses any overhead imposed by the compiler.

Is inline assembly still possible? Wouldn't a Visual Assembler language make
some sense (although the 'visual' is only to imply compatibility and
seemless integration into other Visual languages)?
Click to expand...

Roughly speaking, you want something like:

int main() {
//c++ code

__asm {
//inline assembly code
}
}


Check out the msdn pages on it, for something authoritative:
http://msdn2.microsoft.com/en-us/library/45yd4tzz.aspx
 
Tamas Demjen said:
Theoretically we only need a keyboard with two buttons: 0 and 1, and we
could enter machine code directly that way.
Click to expand...

Any telegraph operator will tell you that a single button is sufficient
(thanks to Samuel Morse).
 
You could make a program like,

int main()
{
asm mov eax,2
asm mov ebx,4
asm add eax,ebx
asm cmp eax,5
asm je ok
no:
ok:

return 0;
}
 
Back
Top