Author Topic: if you are forced to use only C/C++ on a project...  (Read 1126 times)

daydreamer

  • Member
  • ****
  • Posts: 942
  • watch Chebyshev on the backside of the Moon
if you are forced to use only C/C++ on a project...
« on: August 22, 2019, 12:15:19 AM »
Hi
what should you do if you are forced to use only C/C++ code on a project and must produce readable code without assembly and other advanced functions
and you need it to perform better
should you choose a different and better compiler?(tested to produce faster code on same source with fastest settings)
and if so why just that?
and use knowledge from assembly to make things faster

I think I want to test clang

Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
Gone serverside programming p:  :D

TimoVJL

  • Member
  • ***
  • Posts: 476
Re: if you are forced to use only C/C++ on a project...
« Reply #1 on: August 22, 2019, 12:55:01 AM »
If you want to have a same source file for 32/64 bit, C is for it.
gcc and clang have inline assembler support for x64.
clang is a free option, but without CRT and without standard include files and libraries, but have support for MS PDB.
gcc don't have support for MS PDB.

FORCED ?, better to use best compiler/tools for the project.

May the source be with you

Vortex

  • Member
  • *****
  • Posts: 2030
Re: if you are forced to use only C/C++ on a project...
« Reply #2 on: August 22, 2019, 04:16:28 AM »
Also, MinGW64 supports inline assembly.

AW

  • Member
  • *****
  • Posts: 2435
  • Let's Make ASM Great Again!
Re: if you are forced to use only C/C++ on a project...
« Reply #3 on: August 22, 2019, 11:56:51 AM »
My take on this is that when we need to use ASM with C or any other high-level language, it is almost always better to use a separate ASM module. The main reason is that, except for very basic things, such as reversing or rotating bits, inline ASM is cumbersome when compared to full fledged ASM. Sure, it will require a call to the module while inline does not, but does it really weight that much in the final computation? Probably not.

Some people believe that C can replace ASM in every instance. It can not, intrinsics are a panacea. When using vector instructions or looking for extreme performance rotines like memory move, better use real ASM.

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6756
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: if you are forced to use only C/C++ on a project...
« Reply #4 on: August 22, 2019, 05:14:38 PM »
Every tool has its place, a C compiler can produce very good code in skilled hands but it can also produce garbage when not well written. The main bugbear with C/C++ are its runtime libraries, an experienced C programmer knows how to navigate the available range where an amateur will produce bloated garbage.

Now if you write in MASM, who cares.  :rofl:
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

TimoVJL

  • Member
  • ***
  • Posts: 476
Re: if you are forced to use only C/C++ on a project...
« Reply #5 on: August 22, 2019, 09:47:52 PM »
C/C++ users should know, that masm32 have a msvcrt.lib for msvcrt.dll without VC startup routines.
Now we just have to learn to use them, so we can share simple examples without VC CRT, for example that vcruntime140.dll, what isn't part of Windows OS.

For ANSI console program:
Code: [Select]
#pragma comment(lib, "msvcrt.lib")
#if _MSC_VER >= 17
# ifdef _WIN64
#  pragma comment(linker,"/subsystem:console,5.2")
# else
#  pragma comment(linker,"/subsystem:console,5.1")
# endif
#endif
void __cdecl mainCRTStartup(void)
{
__declspec(dllimport) int __cdecl __getmainargs(int*, char***, char***, int, void*);
__declspec(dllimport) void __cdecl exit(int status);
int __cdecl main(int argc, char **argv);

int    argc;
char** argv;
char** env;
int    si = 0;

__getmainargs(&argc,&argv,&env,0,&si);
exit(main(argc,argv));
}
May the source be with you

daydreamer

  • Member
  • ****
  • Posts: 942
  • watch Chebyshev on the backside of the Moon
Re: if you are forced to use only C/C++ on a project...
« Reply #6 on: August 23, 2019, 07:24:18 PM »
thanks everyone for your answers,I read clang has both cl and gcc compability mode
its nice to be able to use inline asm also in 64bit mode,also good to use clang because it seems to produce faster code
AW
I want to make a library of this:
working on a 4xsincostanarcsinarccos PROC,which I want to add jumptable and ifs,so you can choose one or several parts of it
also read about C++ argument against inline asm,it can break compilers optimizating on the rest of the code,dont know if its truth in it


Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
Gone serverside programming p:  :D

jcfuller

  • Member
  • **
  • Posts: 182
Re: if you are forced to use only C/C++ on a project...
« Reply #7 on: August 23, 2019, 07:46:33 PM »
C/C++ users should know, that masm32 have a msvcrt.lib for msvcrt.dll without VC startup routines.
Now we just have to learn to use them, so we can share simple examples without VC CRT, for example that vcruntime140.dll, what isn't part of Windows OS.
Problem is msvcrt.dll is not c99 compliant.
You need to fine a way to access ucrtbase.dll which vc has used since VS2015 I believe.
Not sure how Pelles does it?
This link describes one problem:
https://www.oxygenbasic.org/forum/index.php?topic=1947.0

James

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6756
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: if you are forced to use only C/C++ on a project...
« Reply #8 on: August 23, 2019, 07:53:13 PM »
There is in fact a good reason for the MASM32/64 versions of MSVCRT, the DLL is part of the system so its functions have been available for a very long time. The VC initialisations are no real use in assembler and are easy enough to code in any case so they are not part of those two import libraries. You can go the path of having to add DLLs for C compilers but surely it defeats the purpose of making stand alone executable files unless you want to create your own DLLs which is a design choice, not a runtime DLL.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

TimoVJL

  • Member
  • ***
  • Posts: 476
Re: if you are forced to use only C/C++ on a project...
« Reply #9 on: August 23, 2019, 08:16:28 PM »
Pelles C don't use ucrtbase.dll

ucrt isn't ready yet, it don't have printf, but VC have inline code for it and an additional library for it.

PellesC test with ucrt
Code: [Select]
int main(int argc, char **argv);

void __cdecl mainCRTStartup(void)
{
//_initialize_narrow_environment();
char* pcml[] = {0,_get_narrow_winmain_command_line()};
stdin  = __acrt_iob_func(0);
stdout = __acrt_iob_func(1);
stderr = __acrt_iob_func(2);

exit(main(0, pcml));
}
May the source be with you

AW

  • Member
  • *****
  • Posts: 2435
  • Let's Make ASM Great Again!
Re: if you are forced to use only C/C++ on a project...
« Reply #10 on: August 23, 2019, 08:36:48 PM »
C/C++ programmers, always pray for users to have all redistributables. What runs behind the scenes is a real mess, even experts have trouble understanding it.

But most of this discussion is indeed useless for Masm programmers that produce Masm standalone applications. Fortunately, msvcrt.dll provides everything needed. Things sometimes become tricky when mixing C/C++ and ASM, but the general rule is to use the same libraries/DLLs already used in the high-level part (C/C++).


daydreamer

  • Member
  • ****
  • Posts: 942
  • watch Chebyshev on the backside of the Moon
Re: if you are forced to use only C/C++ on a project...
« Reply #11 on: August 23, 2019, 08:37:04 PM »
but there is both cons and pros with DLL's,isnt one problem if you use big arrays,you get an additional memcopy between dll library and main program of those?

Quote from Flashdance
Nick  :  When you give up your dream, you die
*wears a flameproof asbestos suit*
Gone serverside programming p:  :D

AW

  • Member
  • *****
  • Posts: 2435
  • Let's Make ASM Great Again!
Re: if you are forced to use only C/C++ on a project...
« Reply #12 on: August 23, 2019, 08:46:51 PM »
but there is both cons and pros with DLL's,isnt one problem if you use big arrays,you get an additional memcopy between dll library and main program of those?

I don't think I understand what you mean, but the DLL once loaded is in the same memory space as the main program, no additional memcopy is needed.

jj2007

  • Member
  • *****
  • Posts: 9794
  • Assembler is fun ;-)
    • MasmBasic
Re: if you are forced to use only C/C++ on a project...
« Reply #13 on: August 23, 2019, 09:25:18 PM »
Problem is msvcrt.dll is not c99 compliant.

James,

Excuse my ignorance, but what exactly is the problem there?

Quote
I received an email pointing out a problem with the time functions which I verified.
Output using vs2019 on Win 10 and gcc on Linux:
Code:
Code: [Select]
Mon Aug  5 14:52:11 2019
Today is Monday, August 05.
The time is 02:52 PM.
ISO week day is 2019W321.
Output from NUWEN and my bc9/TCLib:
Code:
Code: [Select]
Mon Aug 05 15:18:27 2019
Today is Monday, August 05.
The time is 03:18 PM.

TimoVJL

  • Member
  • ***
  • Posts: 476
Re: if you are forced to use only C/C++ on a project...
« Reply #14 on: August 23, 2019, 10:21:46 PM »
Someone has found one way to crash msvcrt.dll printf strftime :rofl:
Code: [Select]
Pelles C
Fri Aug 23 14:57:32 2019
Today is Friday, August 23.
The time is 02:57 PM.
ISO week day is 2019W345.

msvcrt.dll
Fri Aug 23 15:01:31 2019
Today is Friday, August 23.
The time is 03:01 PM.

ucrtbase.dll
Fri Aug 23 15:02:52 2019
Today is Friday, August 23.
The time is 03:02 PM.
ISO week day is 2019W345.
Problem is msvcrt.dll is not c99 compliant.
Of course it isn't, as M$ started to conform C99 somewhere 2012, it just took so long.
« Last Edit: August 23, 2019, 11:40:18 PM by TimoVJL »
May the source be with you