Author Topic: c++ versus masm  (Read 845 times)

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6582
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: c++ versus masm
« Reply #15 on: July 06, 2019, 12:29:05 PM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

jcfuller

  • Member
  • **
  • Posts: 182
Re: c++ versus masm
« Reply #16 on: July 06, 2019, 07:59:39 PM »
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

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6582
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: c++ versus masm
« Reply #17 on: July 06, 2019, 08:36:30 PM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

TimoVJL

  • Member
  • ***
  • Posts: 407
Re: c++ versus masm
« Reply #18 on: July 06, 2019, 09:37:33 PM »
msvc -Gy don't help with C++ classes, as they are like structs. Same problems are with SQLite 3, default functions are included.
May the source be with you

daydreamer

  • Member
  • ****
  • Posts: 893
  • watch Chebyshev on the backside of the Moon
Re: c++ versus masm
« Reply #19 on: July 06, 2019, 11:35:41 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


Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
what cpu handle "press any key"? any cpu of course(from C#) :D

TimoVJL

  • Member
  • ***
  • Posts: 407
Re: c++ versus masm
« Reply #20 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.
May the source be with you

AW

  • Member
  • *****
  • Posts: 2230
  • Let's Make ASM Great Again!
Re: c++ versus masm
« Reply #21 on: July 07, 2019, 01:09:27 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.

daydreamer

  • Member
  • ****
  • Posts: 893
  • watch Chebyshev on the backside of the Moon
Re: c++ versus masm
« Reply #22 on: July 11, 2019, 08:47:43 PM »
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
Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
what cpu handle "press any key"? any cpu of course(from C#) :D

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6582
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: c++ versus masm
« Reply #23 on: July 11, 2019, 10:37:14 PM »
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.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

xanatose

  • Member
  • ***
  • Posts: 385
Re: c++ versus masm
« Reply #24 on: August 20, 2019, 03:15:24 AM »
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.