inline Asm in c++ 3

[Sidro]

HI,
This is regard to win32 console C++.
In C++, we can use inline ASM. It looks something like this,
---------------------
_asm
{ mov eax,4
add ecx,5
ect...
}
----------------------

Because Im doing Assembly in c++ using inline ASM, Is the speed of an Inline ASM (execution) as fast as the real Masm? It seemed so convenient to do it in C++. Just wondering if there was any differences. Thanks in advance.

 

[Salem]

Why are you writing ASM in C++ ?


--

 

[Sidro]

hi people,

Sigh...
From time to time, I run into these pesky bugs that just annoys the hell out of me with their moronic, duh, questions. I think others may feel the same way as I do. Instead of just answering and concentrating only on whats being asked, they divert attention away.

>"Why are you writing ASM in C++ ?"

My reason--> It seemed so convenient to do it in C++. Just wondering if there was any differences.

btw, I cut and paste that from my original posting just for you,Salem. You should feel special. I don't usually do this for anyone.

Please folks, only answer questions thats being asked, or if you have something to contribute. Otherwise, do me a favor and just read on. Save Tek-tips some webspace.

 

[Salem]

Yes, there are huge disadvantages to writing your assembler in C++.

1. Your code is no longer portable. You're locked in to one compiler for one processor.
2. Your code takes longer to write
3. Your code takes longer to debug
4. Fewer people can understand your code
5. Your compiler may not be able to optimise the rest of the code in that function.
6. Writing assembler for modern pipelined processors is trickier than you think.

The reason I asked was to try and get you to answer with some statement like "to improve performance".
If you had said that, I would have given you a nice long essay on why that was a bad idea.

--

 

[mingis]

I'm no longer asm-programmer for years, but I hope you can use MSVC IDE for assembler projects if you like. Salem's arguments were not for "asm against inline asm", they were regarding "C++ against asm" . Speed of inline asm pieces of code should be the same, as they would be compiled with MASM - compiler can do nothing to make assembler code slower. Nevertheless, if you doubt in speed of inline asm applications or posibility to share your code with other assembler programmers, it seems there is a possibility to use a real MASM compiler in MSVC projects. Search for MSDN article "Using the Development Studio or Visual Workbench with MASM", Article ID: Q106399. I don't know, whether it really works, you will understand it better. Debugging possibilities will be probably lost in this case.

 

[Sidro]

hi Mingis,

> Salem's arguments were not for "asm against inline asm", they were regarding "C++ against asm" .

Thats what I thought too. I appreciate what he'd done and all that. Unfortunately, it was unless for me, because its not what Ive asked.

Anyway, the program im coding will only be for personal use, so I dont think Ill have to worry about sharing and readability issues. Thanks for the answer and infos.

 

[lionelhill]

Sidro, just a comment, but everything Salem said is quite true, so I personally wouldn't be too hard on him (words like moronic seem a bit harsh). If a pedestrian asks the way to the railway station and you say "that way", knowing that the nearest station is 150km away, you are answering the question they asked, but not helping them. I think salem was just trying to establish that inline asm was really the right tool for what you were doing, and in the balance of probabilities of people in general, it quite possibly isn't.

Salem, I think you're perhaps a little over-harsh on inline assembler too. Although I agree not many people write assembler as well as does a good C-compiler, and of course it's not portable, there are odd occasions where it just seems a good idea (which is presumably why the compiler-writers thought to add it!)
I've used it frequently with my ancient dos-version of pascal, and not because borland did a bad job of writing their compiler.

One example: I'm reading a long binary file containing huge batches of longints in Mac/Motorola byte order, but I'm programming for IBM PC. Therefore I need to do loads of swapping of bytes. Of course I can write that in C or Pascal or anything, and I'll end up with something that turns into a lot of mov instructions, quite efficient.
But worse, I might not want to include several lines of byte swapping in every function that needs to look at these data, so I might write a function that returns the byte-swapped longint. So now every time I need to do this my poor processor has to handle a call (maybe a far call), set up a stack frame, and do a whole batch of movs. But the task could have been accomplished by a single inline bswap. One cycle.
Now the downsides. Lack of portability. True, but my code with the byte-swapping still depended on the byte-order used by the machine, so it wasn't portable anyway! It might have compiled OK on a mac, but it would have produced the wrong answers!
Readability: True, but is bswap so difficult?

Having said that I have also wasted a (big) lot of time writing GUI code in assembler because I started doing low-level graphics in assembler (justifiable) and got carried away, failing to notice the point at which it would have been a very good idea to change to high level language. The thing that finally made me face up to my stupidity was when I couldn't get a bit of assembler to work reliably, raising questions about what I was doing in assembler anyway.

 

[PerFnurt]

Salem, somethimes you can actually trust that a programmer knows what he is doing, and have his reasons for doing what he does.

> "to improve performance"....on why that was a bad idea.

I'm sometimes using snippets of inline ASM to improve performance (measurable improvements). I'd be quite surprised if you could tell wether thats a good or a bad idea, since you hane no idea what the projects been about.

"Generalization is always bad" (pun intended)


/Per

_{"It was a work of art, flawless, sublime. A triumph equaled only by its monumental failure."}

 

[Salem]

There's simply too many things on the optimisation list of things to do before you get to "write bits in assembler" stage.

Unless you're a truly exceptional ASM programmer already, and know a really neat way of solving a particular problem, you're not going to average much more than say 10% over what the compiler can manage.

If you're short by 1000%, then you'd better start using a profiler and looking at your algorithms. No amount of ASM will ever rescue your bubble sort from being outclassed by quick sort.

Of course, the first thing you need is a finished program with real world data and a profiler, because prior to that, its all just guess work.

--