Including assembly
It's not obsolete, but it's not nearly as common (or useful) as it used to be. Still, some operations, like use of processor specific SIMD facilities are as or more likely to be implemented in assembly rather than using things like compiler intrinsics.
Depends what type of projects you mean. If you mean games, then I'd say it's pretty much dead (not entirely, but very nearly). Very very occasionally you might have to hand tune something in a runtime critical loop, but that only really happens if your compiler is a bit crap, and normally only within the last few weeks of the development process when you are trying to eek out a few more fps.
Typically though, you're more likely to examine the asm output of the compiler, then modify your C++ code until it gives you a more optimal output. That case scenario is however less common than you think, because there aren't too many programmers out there who have the skills to outperform a decent compiler (Though there are plenty of people who think they do!), and normally a profiler will highlight hotspots in your code that are normally trivial to fix without resorting to asm.
Typically though, you're more likely to examine the asm output of the compiler, then modify your C++ code until it gives you a more optimal output. That case scenario is however less common than you think, because there aren't too many programmers out there who have the skills to outperform a decent compiler (Though there are plenty of people who think they do!), and normally a profiler will highlight hotspots in your code that are normally trivial to fix without resorting to asm.
Writing in assembler is rare these days, but there are times when it is essential, mostly when new platform architectures appear. It's often the case that the development tools lag behind new hardware, so at times like this, the only real way to make use of the hardware is in assembler.
It's also a very useful skill to be able to read assembler when debugging. Also, having knowledge of how things work 'under the hood' will enable you to write more efficiently in higher level languages such as C++.
It's also a very useful skill to be able to read assembler when debugging. Also, having knowledge of how things work 'under the hood' will enable you to write more efficiently in higher level languages such as C++.
For most applications, it is hardly ever used. But, it is always used when a hardware product 1st boots up. Think of a PSP, when you power it on, the bring-up code is written in assembly. It has to setup the hardware, and the memory. It must assign the stack pointer, and at a point where the processor is in a known state, the memory is in a known state, and the registers are in a known state, then it can jump to a starting point, ofen named main().
Quote:Original post by BeerNutts
For most applications, it is hardly ever used. But, it is always used when a hardware product 1st boots up. Think of a PSP, when you power it on, the bring-up code is written in assembly. It has to setup the hardware, and the memory. It must assign the stack pointer, and at a point where the processor is in a known state, the memory is in a known state, and the registers are in a known state, then it can jump to a starting point, ofen named main().
that's simply wrong. assembler/assembly has nothing to do with inital booting. It is simply one step away from writing machine code in binary. It is a language like any other, with the caveat that it is literally instructing the computer what to do one instruction at a time compared to 'higher level languages' which have generalised commands which can translate into many instructions at machine code level. Really everything is written in assembly... it's just that usually the assembly code is wrapped-up into a more coherent and workable set of instructions within a higher level language.
Assembly/Assembler = binary instructions translated into pneumonics that make half-sense in english.
I think that makes sense.
Quote:Original post by nb
that's simply wrong. assembler/assembly has nothing to do with inital booting.
...
Assembly/Assembler = binary instructions translated into pneumonics that make half-sense in english.
I think that makes sense.
You think that do you? Pneumonics indeed. [grin]
Seriously though, he was right about setup code. Most higher level languages, including C, require some backing data structures and routines that simply cannot be implemented in those languages themselves, because they haven't been set up yet at that point.
Having played with x64 builds recently, whenever I come across an assembler routine in a third party library I feel the urge to utter a stream of curses at the developer. It's really a no-brainer compiling nearly all C/C++ code to x64, but as soon as assembler code is involved, things get complicated.
Luckily, none of the popular libraries (eg. audiere, boost, bullet, freeimage, freetype, loki, lua, ogre, python, sigc++, tinyxml, zlib) incorporate any assembly language code.
-Markus-
Luckily, none of the popular libraries (eg. audiere, boost, bullet, freeimage, freetype, loki, lua, ogre, python, sigc++, tinyxml, zlib) incorporate any assembly language code.
-Markus-
Quote:Original post by Cygon
Luckily, none of the popular libraries (eg. audiere, boost, bullet, freeimage, freetype, loki, lua, ogre, python, sigc++, tinyxml, zlib) incorporate any assembly language code.
Actually, boost does use a bit of assembly.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
