how to force dev-c to generate asm from c++?
Open Source C & C++ IDE for Windows
Brought to you by:
claplace
Menu
▾
▴
sorry I m a novice of dev-c++.
the main task is - to create short dlls for main programm made under MS Visual Studio 2005.
dlls should implement some abstract classes(interfaces) and have two factory functions - create_instance and delete_instance.
when I ve created this dll - it is too big. about 850 kb and it seems gets all runtime system there.
to inspect - what references in my files drag this huge code? i need to view the asm output of c++ code of my dll.
but how?
I m not too experienced in GCC, but know the -S option of compiler.
But I do not want to use command-line tools, and want to make it inside IDE.
Thanks.
Alex.
> There's plenty wrong in the world, but that is not high on the priority list - sorry.
If the C compiler lcc (or any assembler for that matter) can create a Hello World console program in ~3kb and even a basic compiler called PowerBasic can do the same in ~7kb I don't see any reason why Bloodshed DevCpp's seeming best is 263kb? That by many peoples definition is bloatware.
And no it doesnt matter that it "only constitutes about three hundredths of a US cents worth of drive space", disk space itself is generally an irelevant these days but there are still many reasons why some programs and DLLs need to be as small as possible, and just in terms of bandwidth if I'm distributing a 263kb DevCpp exe instead of a 3kb lcc exe that does the same job then that's 870% more bandwidth that i'm paying for/that's clogging up my download pipes, not to mention will take longer for people on slower connections to download, whereas I want to get my product to them as quickly and efficiently as possible.
>>I don't see any reason why Bloodshed DevCpp's seeming best is 263kb?
Dev-C++ is not a compiler. Dev-C++ has no direct control over code generation. It uses GCC as a toolchain - this is a separate project. You can use any GCC compiler you wish - it is packaged with MinGW/GCC. You may get better results by updating the toolchain from www.mingw.org.
You may not see any reason, but I guess then you did not read the links I posted giving the reason! If 263kb is the best you managed, you really did not read the links (or at least follow their advice). It should be much smaller. LCC only supports C; to compare fairly you must use the C library, use C compilation (which makes only a little difference in itself), remove debug, and strip the executable. Admittedly you won't get to 3kb but that would be missing the point, the overhead is, as I said, fixed, so for a non-trivial application the quality of code generation becomes a more significant factor, and then story may be completely different. How really cares how big a "Hello World" is!?
Comparing C with BASIC is not a good comparison. printf() provides a huge amount of functionality not used by "Hello World".
In short, comparing code size performance on a trivial example is entirely unrepresentative and pointless. You cannot base a sound argument upon such observations.
Dave, might it is better to install freeware MS Visual C++ express edition?
For my tasks (Win32 programming, dlls) this is most effective.
Compiler cannot bloat code so much. Compiler is stupid and generates a target machine code from your text. But linker can collect a lot of library modules and symbolic info into you final exec file.
Try to open your exec with some binary/text editor and look into. It seems bloating is from not stripped symbols of libraries.
I have not installed dev-c++ now, but my problem was eliminated via set to true linker option - strip exec. and dll was reduced from 480(like your)kb to 40-50.
Alex.
I am confused. Why are you using both VC++ and Dev-C++ when you could use one or the other. Do you understand that A DLL with a C++ class interface written in one compiler is unlikely to work with an executable written using a different compiler. You can only reliably use interfaces with C linkage between compilers.
I don't think seeing the generated code is necessarily the solution to discovering the reason for the size. There are a number of factors that make MinGW/GCC C++ code large. To minimize size make sure you build with debugging switched off and stripping switched on. Even then if you have used the C++ standard library, due to the way it is implemented and licensing issues that prevent it being implemented as a DLL your code will always be large. 850kb is not that large in any practical sense.
If you still feel you need it, the assembler output can be generated as described here: https://sourceforge.net/forum/forum.php?thread_id=1379841&forum_id=48211
Clifford
Thanks Clifford.
The reason to get DevCC, was to test if virtual tables for pure abstract class of Microsoft VS are equal to MinGV compiler. Since this feature is not standard - there is a veeeery small chance for it.
I simply wanted to test it and might get a MS Express Edition to make a dll'ing job.
Main system is huge and written in MsVS, but I have not licensed(unlicensed) copy of VisStudio 2005 and have not fast channel to get cracked MsVS :)
Naturally, if virtual tables of two systems differ in some regular way(for example methods have different offset in VMT), there is a chance to call virt. method, via some tricks, I believe.
Also I m looking for free light-weight C++ system for some personal projects.
So I downloaded the DevC++ to test it.
So you don't have an illegal version of VC++ because you don't have bandwidth - not because it is illegal or anything....hmmmm! Even with teh smily that is not even funny. As software developers ourselves, we should not even contemplate stealing the work of others even if it is Microsoft. Besides, if you can do what you need in Dev-C++ you can certainly do it in MS VC++ 2005 Express Edition - legally - you may want to download and install the Win32 PSDK (instructions on the Express Edition Start Page link).
The compatibility or otherwise of "virtual tables for pure abstract class" is not really your problem - both compilers use different name mangling schemes, so the symbol names of one will not match those of the other. That is why you have to use C linkage, which the precludes the use of classes, function overloading, and default parameter values in the public interfaces (in fact anything that is not legal in C).
Clifford
So you don't have an illegal version of VC++ because you don't have bandwidth - not because it is illegal or anything....hmmmm!
pls. do not blame me, because most of people are reasy to pay reasonable price for usefull product.
So. For my current(very special) task VisualStudio is not proper choice because it is huge, 99.9 percent of features are not useful, and eats a lot of memory and disk capacity. simple economic thinking hints that only veeery extravagant person will buy this to solve the task.
I think this is a problem of mr Gates - sell suitable things with reasonable price to satisfy client needs.
Market is free...but a bit monopolistic, isn it? :)
You are missing the point - it's free! (If you don't need the enterprise level features of the paid for version).
Moreover at about US$0.30 per Gb disk space is hardly an issue. I just checked and the runtime memory footprint for VC++Express is about 23Mb (about one third that of Firefox, and a little less that that of Internet Explorer). Since XP runs like a dog on less that 256Mb of RAM and you'd be hard pressed to buy a computer with that little today, I imagine that you have enough. I have Express editions of VC++ and C# and combined they total 774Mb. The PSDK is a further 900Mb.
So get real, using legal software need not cost a penny over your existing investment in hardware.
Clifford
Clifford,thanks.
I downloaded Express Edition, adds there a PSDK, following instructions, and it seems - all is working. At least dll is created and have 48kb of size.
Alex.
Now you can apologise to that nice Mr Gates for getting him so wrong. ;-)
Oh and returning to your original problem. Inspecting the assembler code is a really dumb way to determine what is taking the space in your code. Just get the linker to output a map file, or if you have not stripped the executable, use the nm.exe utility to generate a map file of the executable.
Why do you think 850kb is too big in any case, given my earlier point, that constitutes about three hundredths of a US cents worth of drive space - you are sweating the small stuff.
Clifford
CLifford. Something is wrong in this world, if 2 screens of pure code, lead to 840 kb dll. What externals this code uses - that question was before me.
it seems only wihdows.h file was included, new and delete operators were used, and decoration for dllmain function.
I m not too expirienced in win32 programming, but have strong experience in compilers developement and developement of programming systems. So have understanding what code size is reasonable for a task of some complexity.
And I m sure current prices of disk storage, are not meaningfull for a guestion.
I think Dev C++ should have more suitable way do inspect the asm output of compilation of a source. One click way.
Sorry, I m from Moscow, Russia, and my english is not fluent.
Did you read the thread I linked to earlier. The simple way is to use the Insight debugger. It still won't solve your problem however, just generate a map file - you don't need to wade through assembler output! Post the build log so we can see what compiler/linker options you have set. Did you disable debug and enable stripping as suggested.
The cost and resources of a modern computer are indeed relevant - there are two ways of solving any problem:
1) Fixing it,
2) Changing your perception of it.
You have not given one reason why 850kb is actually a problem.
Also have you read any of the several FAQ's on this subject?
http://www.mingw.org/mingwfaq.shtml#faq-cpp-size
http://www.bloodshed.net/faq.html#6
http://www14.brinkster.com/aditsu/dev-cpp-faq.html#largeexe
If it still really irks you, there are other compilers!
I found a reason of big size. It is from "strip executable" set to false.
If strip is false - the default dll code(generated by Dev-C++ script) is about 845 kb.
If strip is true - the same code is 55.5 kb.
:)
debugging is off.
I suggested switching stripping on in the first response. Why do I bother if no one listens!?
Because it still benefits those of us who monitor the forum and actually read your words of wisdom. :)
it is better to talk why default set of DevC++ options generate 850 kb of code of empty dll.
Because during development by default you typically want to be able to debug your code at the source level - you cannot do that if you strip out the symbol information. If it did that by default, you'd be complaining about that instead! It is no use blaming the tool for your own incompetence.
The information stripped is just symbol information, it does NOT affect the run-time memory footprint; so trying to look at the assembler code would not have helped - the data stripped is NOT code.
You made the classic mistake of inventing a solution that you did not know how to implement and then asked how to implement it! What you should have done is explained your root problem and asked for solutions - because your solution was not in fact a solution at all, it was merely a reflection of your incorrect perception of what was happening. What you should have asked was simply "Why are these files so large?", but instead you asked "How can I see the assembler code?".
Clifford
...BTW the symbol table overhead is largely fixed. You could add a thousand lines of code and it would not get much bigger, so for a non-trivial application if is far less of a concern.
in the case I have, we need plenty of small dll's, as small as possible.
this is the simulation engine, each dll implenents some abstract model, and makes it concrete.
instead of dark and brutal option - "stip exe?", I prefer the common term - put symbolic info into executable?...or smth similar.
The naming of the option is nothing to do with Dev-C++, the tool-chain is GNU, Dev-C++ is just an IDE. I think you are really nit-picking no just to justify your own ignorance.
>> Something is wrong in this world, if 2 screens of pure code, lead to 840 kb dll
There's plenty wrong in the world, but that is not high on the priority list - sorry.