Help with asm

[trancexx]

There is nothing wrong with knowing assembly. Since all the code eventually gets, or already is transformed to that, it's desirable to be known, as far as I'm concerned.

On the other hand it requires different level of mind (set), so it's understandable that many people don't want to know it. Usually it's just above them.

Enjoy higher levels.

[Shaggi]

I think assembly is usually the easiest to understand / comprehend, compared to higher level languages. I need to know the inner workings of something, before i trust it / use it.

Looking through your own programs compiled teaches you how your usual constructs gets implemented, and if you study it a bit, you easily learn to optimize your stuff / know what constructs to avoid.

[Valik]

I think assembly is usually the easiest to understand / comprehend, compared to higher level languages.

This is false for most people. The higher level concepts are easier to learn for most people. Also as mentioned the higher concepts transfer between languages.

I need to know the inner workings of something, before i trust it / use it.

So does that mean you understand how the processor, RAM, graphics card, monitor, et cetera work in technical detail? You know how the power is generated at the electric company? How the fuel the power company uses it manufactured, transported, et cetera? How deep does your rabbit hole go?

Looking through your own programs compiled teaches you how your usual constructs gets implemented, and if you study it a bit, you easily learn to optimize your stuff / know what constructs to avoid.

This is absolutely the wrong approach. If you write wonky C++ (for example) just because of certain output you are doing a couple things wrong. First, you're probably writing bad C++ code. It's the compiler's job to massage that into something useful, not yours. Second, you're writing code that is likely non-portable between compilers which will likely produce different output. Third, your wonky constructs designed to massage compiler output are going to be very difficult for others to deal with.

[Shaggi]

This is false for most people. The higher level concepts are easier to learn for most people. Also as mentioned the higher concepts transfer between languages.

Maybe, but it seems i work backwords in this context. Each of the finite amount keywords in asm do what they say.

Mov reg, const number

For me, it doesn't really get simpler. What actually happens here is what it says: Move a value to a register. cmp something and jxx somewhere. Its logical and comprehendable.

So does that mean you understand how the processor, RAM, graphics card, monitor, et cetera work in technical detail? You know how the power is generated at the electric company? How the fuel the power company uses it manufactured, transported, et cetera? How deep does your rabbit hole go?

As deep as it affects me. But i do infact research these things because they are what driving me to learn more. Im very curious by nature. So i thank myself for that, i guess.

At a small age, i studied computers and i always wondered how that shit worked. How those transistors actually create a logical flow depending on input and carries. This desire for logical constructs solely led me to start programming for fun.

When i write a c++ program, i dont read up on the graphics engine api that shows my text output, because it doesn't affect my program. Therefore, i also do not visit the nearest electric company, because it doesn't matter. But if i write a game / graphic engine, you can be sure as hell i research that, so my code becomes the best and quickest.

This is absolutely the wrong approach. If you write wonky C++ (for example) just because of certain output you are doing a couple things wrong. First, you're probably writing bad C++ code. It's the compiler's job to massage that into something useful, not yours. Second, you're writing code that is likely non-portable between compilers which will likely produce different output. Third, your wonky constructs designed to massage compiler output are going to be very difficult for others to deal with.

Wonky constructs is a weird term, i would rather call it optimizing - which is what it is. Nobody cares if you write safe code, thats slow as hell. If i write code that others use, or code, that needs to be portable, i do that, definately. But in any other instance i write code for a platform and optimize it, because thats what it's written for.

Most compilers do this, but sometimes you need to specify something yourself. Why do you think all popular compilers for c++ (and delphi and a lot of other languages) gives you the __asm keyword? So you can write the implementation yourself.

Some programmers might think chaining a bunch of if - else statements looks good, and while it does the job, a clever programmer with some asm knowledge will know that a switch statement compiles to a much more effecient jumptable. But this requires to analyze the output of the compiler. The same goes for inline functions in tight loops which was added in c++. Somebody, not knowing asm, doesn't know that calling a function has significant overhead if the function only contains a small amount of code. This doesn't break on platform change, but is a huge optimizing improvement.

e: to add a last example, some time ago multiplication instructions on cpu's were ridiculously slow. Thus, programmers started to use bitshifts for division and multiplication as they would in many instances use a lot less cpu cycles.

Edited December 11, 2011 by Shaggi

[MvGulik]

so my code becomes the best and quickest

Seems to me you still got a lot to learn. Although because its not directly related to technical stuff you probably skipped those parts. ("as it did not effect you (yet)", I imagine.)

[Ascend4nt]

Interesting how this thread has jumped all over the place. Everyone seems to have strong opinions on what is right and wrong. The latest comments from Shaggi are something I can somewhat associate with.

Back when I was first learning C (coming from GWBasic of all things), I just could not grasp how the fundamental data types and some concepts of the C language worked, without getting a clearer view of how things are implemented at the basic level. C and C++ are not high-level languages as many would have us believe (intermediate language is more appropriate). They are fundamentally tied to low level aspects of computer architectures and have never completely abstracted any of it. An analysis of data types, pointers (especially the early differentiation between near/far pointers), bit operations, allowances for inline assembly, and other aspects of the language is clear enough evidence of its close ties to the basic elements of computer architectures.

So, for me I had to actually learn Assembly before I could understand C (and later C++). Perhaps most people can pick up C/C++ without knowing what's happening 'under the hood', but its doubtful that anyone using these languages would not be exposed to at least some core-level implementation details. Still, Assembly code is never really required except for optimizations and for certain low level things. Even then however, there are compiler intrinsics in certain compilers that allow one to embed typical assembly instructions in C/C++ without actually writing out the instructions using the 'asm' keyword (Visual C++ gives things like 'rep movsb', 'rdtsc', 'cpuid', 'rotl' and other instructions via these intrinsic functions).

As far as optimizing C/C++ by examining Assembly output, this isn't an entirely bad idea, just mostly unnecessary. However, there are certain ways of reordering function execution that seem to yield consistent results across compilers. Things like conditionals and loops can be optimized if you understand how the logic and branching would normally work. Also, for me one benefit is I can see when things don't work as I would expect them to. For example I assumed using 'static_cast' to go from 'char' to 'unsigned int' would work using a zero-extend move, but the cast used a sign-extend move to make the byte into an int, causing some unexpected results. That's just one example, but there have been other cases where examining the output helped me to better understand how things are implemented, and at times helped me write better C++ code which cut down on unnecessary instructions. And this is even taking into account the way different compilers can produce code.. what I'm talking about is things that, due to C/C++ implementation rules, would commonly produce extra code or waste memory.

Anyway, this is just my experience. I stick to C++ as much as I can these days, and rarely dip into Assembly.

[Shaggi]

Seems to me you still got a lot to learn. Although because its not directly related to technical stuff you probably skipped those parts. ("as it did not effect you (yet)", I imagine.)

That was not attempting to be arrogant, understand it more like a driving force that makes you better (: understanding what really happens.) That is for me programming abc. My code is neither the best nor the quickest, however i continue to study it so it someday might be. I dont see anything wrong in that, and yes i have a lot to learn as have many on these boards.

@Ascend4nt

Interesting post, i agree with you. I did not intend to say that people should write the implementation themselves, but i do think that understanding it helps you write better code.

[MvGulik]

@Shaggi

Roger. And yes, there is nothing wrong with studying that which interest you.

(But again I'm not sure about your other goal ... swinging between "The best" versus "The best you/I can be" ... "The Best" beeing a mighty big goal. )

[Shaggi]

It maybe was worded a bit bad. I dont aim for beeing the best, however i aim at being better than i am atm.

[jchd]

Granted, getting better is a nice goal.

I look at attempts of achieving "top notch" optimization as now essentially useless. It was possible at some time to perform register coloring, loop unrolling and such optimizations "by hand". Today's CPUs and architectures are way too complex and varied for a human brain to apply effective optimizations on anything but very very small code sources.

Even a small critical routine you want/need to optimize is now out of reach in practice. The result you'll get will highly depend on the exact processor running your handcrafted code. What you believe is a smart optimization will break the low-level MIPS pipeline in a different processor. You can't even make two piles: AMD and Intel. Subtle or large changes in different series or successive CPUs from a given brand can give highly varying result on integer, cache, branching prediction, rearrangement, pipeline, FP. So unless you target a very precise hardware, you can't squeaze the best speed from seemingly comparable stock platforms.

Even understanding _all_ the published fine details that needs mastering for a given platform is a daunting task, if not plain impossible. Algorithms for low-level instructions rearrangement are not publicized and they play a significant role in speed, for a selected instruction mix based on criterions you don't know.

That said, there's another point I think you miss. Compilers are also getting much better and the best ones are able to select better optimizations when informed they target a specific platform, using cryptic options and online directives. They do that routinely and evolve as new processor architectures appear.

Then there's another, more important, point. If we start talking at a non-trivial portion of code and talk about, say, a complete significant library, then another very simple yet highly effective approach allows important speed gains. Preprocess the whole lot of individual files and compile the huge resulting source in one go.

That's because good compilers (here I mean e.g. GCC & Intel C[++] compilers) are able to detect incredible very large scale optimizations on complex code that you couldn't even consider watching at once.

For instance, the SQLite C source sees average increase of 5 to 10% in speed when compiled in the "amalgamated" form (single huge source) compared to separate compilation for the same platform and compile options. That can even reach 15% on some embedded platforms! This sort of "fish-eye" view and deep analysis on 10K or 100K lines of code at a time is out of question for any human brain.

I certainly don't mean that learning and questionning is bad. It's just not getting rewarding and/or effective enough to try to reach "code heaven" by mere brain means, thanks to advances in hardware (faster processors, unlimited memory) and compilers' sophistication.

[MvGulik]

... CPU Biodiversity ...