I would like to see the instructions that are generated from my C/C++ code.
Does Dev-C++ have this feature or must i use a hex editor.
The reason i ask is because i am into ASM and would like to compare myself to this compiler.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A hex editor will indeed show you the 'machine code' but I imagine that you in fact want an assembler listing. Besides exe and object files contain information other than merely the raw machine code.
There are other options:
1) Use a disassembler. A disassembler will understand exe and object file formats and will correctly distinguish between code, data, and meta-data. However, associating the disassembly with teh source might be difficult.
2) Use a debugger and get it to show mixed source/assembler or just assembler. You can even inspect code memory in hex is you wish. However the built in Dev-C++ GDB wrapper does not make it easy to get at that functionality, and I suggest that you use teh MinGW Insight external debugger: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82725
> The reason i ask is because i am into ASM and would like to compare
> myself to this compiler.
For non-trivial code, when using the compiler optimisation options you might be hard pushed to even understand what the compiler generated since in many cases it will not even execute the code in the same order the source is written. The debugger and single stepping would help to understand what is going on, but don't expect stepping at the source level to make much sense - there is often no longer a simple one to one relationship between source and assembler blocks.
The kind of complex abstract execution analyses and heuristics that the optimiser applies can result in very convoluted code. Moreover the optimiser will take into account the entire compilation unit, wheras that is either very difficult for a human, or the module size is much smaller in any case reducing the potential for optimisation. It is easy to spot a few lines of assembler where you might have done better, unrolled a loop or not reinitialised a register because it already held the correct value; but on the whole because it can more easily take a more holistic view, the compiler will beat you. It might be easy to develop a specific case where some tiny code fragment is better hand codes, but the optimiser itself is optimised for non-trivial code bases, so may not perform well on trivial examples.
For this reason, assembler is generally only useful in very specific circumstances, and I would suggest that on a PC given the advanced sophistication of modern compilers, size of a useful application (as opposed to a trivial test case), the large available memory, and their sheer speed, these circumstances hardly ever apply. You must realise that you are only doing this for fun, it has no practical purpose and will certainly hinder your productivity. The efficient way to high performance is smart algorithm and data structure design, not assembler code. Take the holistic, broad view rather than sweating the small stuff. As Donald Knuth said "Premature optimization is the root of all evil".
Moreover a huge amount of expert processor knowledge is encoded into the optimiser, it will produce surprising results for reasons that may be hard to fathom. The best way to compare your assembler code to the compiler's performance is as a black box by performing benchmark timing tests on the code.
If you don't use optimisation, the code will be far easier to follow, but is then hardly a fair contest. It would be like hitting Usain Bolt in the nuts and then claiming you beat him in the 100 metres! Unoptimised code takes a very simple one source-line to one code block approach which makes it easy to follow but not optimal.
Note that the MinGW compiler distributed with Dev-C++ is based on the older GCC 3.x. The prime goal in teh transition from 2.x to 3.x was ISO C and C++ compliance. For the 3.x to 4.x swith however, the emphasis was on optimisation. So you may be using a compiler that is not state-of-the-art optimisation wise.
I would suggest that you study the subject of compiler optimisation first to get an idea of what you are up against, and the areas that as an assembler level programmer you may not have considered. Start here http://en.wikipedia.org/wiki/Compiler_optimisation (it is in fact a far more interesting subject that assembler programming!)
The point is when tweaking the code, the compiler encodes the experience of many man years of effort, and never gets tired, bored, or has an 'off' day. So I'll wager that in most cases you won't beat it, and even when you do it won't matter much - fast enough is fast enough, and memory is inexpensive and plentiful. Productivity is the real efficiency gain to be strived for.
Clifford.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great reply Clifford.
And yes, this is just for fun.
One thing i noticed back when using MS:VC6:DUMPBIN.EXE was that even the best compilers did not utilize all of the registers.
This was where i could squeak some performance out of using my asm code.
Thanks for your time and happy coding...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see the instructions that are generated from my C/C++ code.
Does Dev-C++ have this feature or must i use a hex editor.
The reason i ask is because i am into ASM and would like to compare myself to this compiler.
Utilising more registers may mean more registers to push and pop between function calls, so that in itself may be am 'optimisation' - perhaps?
> Does Dev-C++ have this feature or must i use a hex editor.
Dev-C++ does not directly provide that feature. However the compiler can be directed to generate readable assembler or mixed assembler/code. The technique is described in detail here: https://sourceforge.net/forum/forum.php?thread_id=1379841&forum_id=48211
A hex editor will indeed show you the 'machine code' but I imagine that you in fact want an assembler listing. Besides exe and object files contain information other than merely the raw machine code.
There are other options:
1) Use a disassembler. A disassembler will understand exe and object file formats and will correctly distinguish between code, data, and meta-data. However, associating the disassembly with teh source might be difficult.
2) Use a debugger and get it to show mixed source/assembler or just assembler. You can even inspect code memory in hex is you wish. However the built in Dev-C++ GDB wrapper does not make it easy to get at that functionality, and I suggest that you use teh MinGW Insight external debugger: https://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82725
> The reason i ask is because i am into ASM and would like to compare
> myself to this compiler.
For non-trivial code, when using the compiler optimisation options you might be hard pushed to even understand what the compiler generated since in many cases it will not even execute the code in the same order the source is written. The debugger and single stepping would help to understand what is going on, but don't expect stepping at the source level to make much sense - there is often no longer a simple one to one relationship between source and assembler blocks.
The kind of complex abstract execution analyses and heuristics that the optimiser applies can result in very convoluted code. Moreover the optimiser will take into account the entire compilation unit, wheras that is either very difficult for a human, or the module size is much smaller in any case reducing the potential for optimisation. It is easy to spot a few lines of assembler where you might have done better, unrolled a loop or not reinitialised a register because it already held the correct value; but on the whole because it can more easily take a more holistic view, the compiler will beat you. It might be easy to develop a specific case where some tiny code fragment is better hand codes, but the optimiser itself is optimised for non-trivial code bases, so may not perform well on trivial examples.
For this reason, assembler is generally only useful in very specific circumstances, and I would suggest that on a PC given the advanced sophistication of modern compilers, size of a useful application (as opposed to a trivial test case), the large available memory, and their sheer speed, these circumstances hardly ever apply. You must realise that you are only doing this for fun, it has no practical purpose and will certainly hinder your productivity. The efficient way to high performance is smart algorithm and data structure design, not assembler code. Take the holistic, broad view rather than sweating the small stuff. As Donald Knuth said "Premature optimization is the root of all evil".
Moreover a huge amount of expert processor knowledge is encoded into the optimiser, it will produce surprising results for reasons that may be hard to fathom. The best way to compare your assembler code to the compiler's performance is as a black box by performing benchmark timing tests on the code.
If you don't use optimisation, the code will be far easier to follow, but is then hardly a fair contest. It would be like hitting Usain Bolt in the nuts and then claiming you beat him in the 100 metres! Unoptimised code takes a very simple one source-line to one code block approach which makes it easy to follow but not optimal.
Note that the MinGW compiler distributed with Dev-C++ is based on the older GCC 3.x. The prime goal in teh transition from 2.x to 3.x was ISO C and C++ compliance. For the 3.x to 4.x swith however, the emphasis was on optimisation. So you may be using a compiler that is not state-of-the-art optimisation wise.
I would suggest that you study the subject of compiler optimisation first to get an idea of what you are up against, and the areas that as an assembler level programmer you may not have considered. Start here http://en.wikipedia.org/wiki/Compiler_optimisation (it is in fact a far more interesting subject that assembler programming!)
The point is when tweaking the code, the compiler encodes the experience of many man years of effort, and never gets tired, bored, or has an 'off' day. So I'll wager that in most cases you won't beat it, and even when you do it won't matter much - fast enough is fast enough, and memory is inexpensive and plentiful. Productivity is the real efficiency gain to be strived for.
Clifford.
Great reply Clifford.
And yes, this is just for fun.
One thing i noticed back when using MS:VC6:DUMPBIN.EXE was that even the best compilers did not utilize all of the registers.
This was where i could squeak some performance out of using my asm code.
Thanks for your time and happy coding...