|what the C++ community thinks about the relationship between the C++ standard and assembly. |
Everyone here seems to have missed the point of this post.
@Athar thank you for contributing to the real topic, at least in part. Opening topic:
|I think we should at least have a new standard library for these low level functions so they can be across platform a little easier.|
|EDIT: My suggestion, if any, is that C++ standard should ether include rotation, endianness functions, and the like of more powerful/useful instructions. To accompany for the very much widely supported rotation instructions, like what GCC already has put into effect and then in that they can provide the alternative C++ ways of doing it without hardware support.|
@CodeMonkey Must I really need to point up to the opening topic again?
@Helios I am giving you and others information about the background of this topic.
|Unfortunately for you, the C++ committee's aim for portability is broader than that. Wise, in my opinion.|
This kind of reply helps no one. Another topic I could bring in is that C++ standard aims to fit all but a lot of the time it doesn't come close. Lets face it there is not much you can write with just the standard libraries that work on all platforms if you want to go farther then printing text to a console. An assembly standard would only fit into how general instructions are use and macro type stuff. Extensions and other instructions of different platforms would come and go accordingly, but so does everything else with C++ (WinAPI and the alike). I don't view this as a bad thing because obliviously adding something like that only brings C++ one step closer to something like Java. The only point I originally had in mind from this second option is would it/could it be a good thing to have inline assembly that would share a syntax inside of C++. Example:
// Something like this
mov eax, ebx
Yes its platform dependent but how many functions do we write in C++ that aren't (from a API level of course)?
By the way to point out that list you gave before only had half of it's size made out of real base instruction sets. Things like AVX, SSE are extensions not bases, ARM, RISC, and IA32 are bases. Also to some degree an assembler does replace typed instructions with the one binary code for the platform. Move and jump instructions vary but the name and syntax in the assembly stay the same.
|This kind of sub-micro-optimization is for the most part pointless at the C/++ level. If you're spending a considerable amount of time thinking about stuff like this, you're not using the right language.|
My reasoning for thinking about these things is explained I think in me saying I like low level programming. If I'm building a compiler I want to know exactly what it is doing only so to better optimize what binary it gives out. It also brings up that "little old thing" of how much do you trust your compiler to make the right choice for you. I understand that if you wanted it done completely right you are stuck with assembly. (This is going a little far off what I planed to gain from this discussion.) Compilers should be optimized to the point that from higher levels you shouldn't need to worry about it, but for a cutting edge programmer you cannot rely on compilers to catch up so quickly. Some of them take years. Also I haven't found many/any programming languages that offer the best of low level while jumping above like C/C++ with assembly can do.