Last week I "translated" one of my Masm programs into c++.
It is not better or worse but the exe file is much larger.
Probably not very well written.
Think I stay with Masm.
For those interested, here is the source compiled with dev-cpp.
My machine: Windows10 64b
strip off debug-info and size is 918 KB
and without static crt size is 902 KB
TimoVJL,
This is the first c++ program I ever wrote.
I haven't the slightest idea what you mean.
Check this in Dev-C++:
Project -> Project Options ... -> Compiler -> Linker -> Strip executable (-s) Yes
Ctrl+H opens Project Options.
and then size is something like 920 KB.
ok. Thanks
What is the size of your masm version?
James
50% smaller
What is more surprising is that the background.bmp alone accounts for 778KB, this is a real miracle :badgrin:
Quote from: clamicun on July 04, 2019, 07:06:42 AM
50% smaller
Quote from: AW on July 04, 2019, 03:21:30 PM
the background.bmp alone accounts for 778KB
Assembly rocks!
C++ exe 920 KB - 778KB = 142 KB real code
Masm exe 460 kB - 778KB = -318 KB real code
.rsrc 909312 bytes 888 KB
.rsrc + .rdata DF000h 913408 bytes 892 KB
Dump of file DateiManager.exe
File Type: EXECUTABLE IMAGE
Summary
1000 .CRT
1000 .bss
1000 .data
2000 .idata
1000 .pdata
1000 .rdata
DE000 .rsrc
5000 .text
1000 .tls
1000 .xdata
Thank you all,
the masm version doesn't use the bmp on the mainwindow.
That's the secret
isnt the right word you "discompiled" your masm code? :biggrin:
(like disassembler,but opposite C++ compiler)
modern C++ compiler has an advantage of not including functions/PROC that are never called and assembly has its advantages of make code small,could it be possible to have conditional assembly do the same thing make assembler code even smaller?
Absolutely, daydreamer! Why don't you test it and post an example?
Quote from: daydreamer on July 06, 2019, 04:24:09 AM
...not including functions/PROC that are never called...
If you make assembly programing in a modular way, assemblers don't include functions never called. :thumbsup:
uasm supports COMDAT with it's own way.
a smart linker don't include unused code.
Magnus,
The way it works with languages that make object modules that are placed in a library is that any module code that is called is added to the binary by the linker, if it is not called it does not get added. It is called "Linker Resolved Dependencies". If you make the effort to place every algorithm in a separate module, then you have the finest "granularity" and completely exclude unused code.
The tests I did awhile ago with VS 2017 indicated that all functions in #included .cpp source files were compiled and added to the exe. If all code was in a single file only those functions called were added.
Hutch:
I thought /Gy was applicable when creating object modules with VC++ for a library so I did not have to be as granular with the sources. ???
James
James,
You are talking to the wrong person here, I would not touch C++ with a barge pole. C is OK if written properly and I have seen decent C++ but a lot of it is crap.
msvc -Gy don't help with C++ classes, as they are like structs. Same problems are with SQLite 3, default functions are included.
Quote from: hutch-- on July 06, 2019, 12:29:05 PM
The way it works with languages that make object modules that are placed in a library is that any module code that is called is added to the binary by the linker, if it is not called it does not get added. It is called "Linker Resolved Dependencies". If you make the effort to place every algorithm in a separate module, then you have the finest "granularity" and completely exclude unused code.
I am doing it that as much as I can this last year,using IDE and separate source files and a main console test program
I go for similar kind of code in same module
since ml.exe 12.00 support -Gy , making libs from a one source is possible.
now we have to wait that uasm support it too.
Quote from: TimoVJL on July 07, 2019, 12:23:13 AM
since ml.exe 12.00 support -Gy , making libs from a one source is possible.
now we have to wait that uasm support it too.
UASM probably supports COMDAT because it is mentioned in the JWASM Help file . I never tested, so can't say more.
C++ is maybe more portability,but you can trust masm to use register eax,ebx or any register you want to be what you see is what you get,a C++ compiler may or may not use register keyword and if you use masm to write SIMD packed instructions you get vectors to run fast,otherwise you have to trust compiler vectorize it for you and get performance boost
my suggestion is you let C++ compiler output assembly listing and compare that against your masm assembly listing
C++ changes standard different years,while x86/x64 masm stays the same,except adding support for newer opcodes and support use of bigger registers using same old mnemonics,32 to 64bit,256 to 512 bit
Interestingly enough, ML64 also supports the -Gy switch so when I have some time to play with it, I will see what it does. This much, a library built the old way of one proc for each module, you don't have granularity problems. The -Gy switch may be a convenience but it will not make smaller code that a library written with one procedure for each mosule.
One thing I like about assembler is that once you get rid of a bug, it will not come back.
Meanwhile with c++ you just remain with a time bomb until the next compiler change breaks your code.
Or when someone tries to "modernize" perfectly good code. Specially when doing it with automatic tools like clang-tidy. Thank goodness for git.