Google Benchmark compilation issues.

[chuggafan]

I plan on using GBenchmark for the testing of the alternate memcpys (It's a really good microbenchmark library), it turns out it: a. requires c++17 b. Doesn't compile! c. Has an enormous amount of false warnings.

This leads me to believe that the functionality for determining if a value is used or not is extremely broken, Now, the counter.cc file has to be modified to take in rdtsc and we should probably get that "oasm informs occ about what assembly instructions can use what and can color what" stuff working so that we can either do some form of intrinsics (I'm still thinking of how these need to be implemented) or assembly functions (That way we don't have to make a pre-coloring table for every instruction which is a lot of work to do in multiple places). Whatever you want, I think we can do something similar to sqlite3.c where it just does a naked function rdtsc and then a ret (since rdtsc already sets up EDX:EAX):

  #elif defined(_MSC_VER)

  __declspec(naked) __inline sqlite_uint64 __cdecl sqlite3Hwtime(void){
     __asm {
        rdtsc
        ret       ; return value at EDX:EAX
     }
  }

  #endif

Edit: I forgot to realize I needed to add some minor instructions to compile, the workaround for getting cmake to compile C++17 orangec code at https://github.com/LADSoft/OrangeC/issues/1096#issuecomment-2919274433 is required

[chuggafan]

Ya'know, I also forgot to dump the output file with the issue. Whoops

output.txt

[LADSoft]

so in #1081 I thought I fixed this, I had added colorizing at the statement level (not the individual operand level) which seemed to work and then made a change to disable inlining functions that have assembly language in them when you had problems with that. So I'm not sure what you need me to be working on in relation to this?

As far as compiling C++ code yeah I've been trying to address various issues by compiling covscript and will continue to do that. I'm not currently planning on deviating and working on other stuff because I'm still trying to get to a point where I can release and even without all the detours I've been making recently that seems a long way off. However, that work on covscript isn't going anywhere fast, and it has also resulted in breaking a lot of other things, so it will be a while before I can get out from underneath it and start queing in changes for other programs that don't compile 100%.

[chuggafan]

so in https://github.com/LADSoft/OrangeC/issues/1081 I thought I fixed this, I had added colorizing at the statement level (not the individual operand level) which seemed to work and then made a change to disable inlining functions that have assembly language in them when you had problems with that. So I'm not sure what you need me to be working on in relation to this?

I'm unsure, I haven't tested yet (I have to add our own custom shim to the system), I'll take a look at the assembly output of some similar functions over the weekend. I'm definitely still in this "I want to think about intrinsics long term but I'm still being dumb about it and not thinking with everything else going on" mode.

Also, thanks for the effort on this C++17.

[LADSoft]

Also, thanks for the effort on this C++17.

thank you for saying this. Just seems like so much of what I do just goes into the void... I've been working on covscript some more, there was a really complex issue that took me over a week to diagnose but of course the fix was incredibly simple lol... back on track with it now though....

[chuggafan]

Yhea, open source is a thankless task.

I'm keeping my memcpy code waiting for this so I can do some neat microbenchmarking using a known library instead of trying to hand-roll whatever google is doing.

I've been also lazy on the omake linux stuff because I know debugging it is going to be a pain, and instrumenting EVERY SINGLE FUNCTION in omake is just a very annoying task that I have to do to debug what in the universe is going on there.

[LADSoft]

FWIW I have a compile mode that instruments every single function... meant to be used with my simple profiler but I've used it for more generic debugging too.... not that that helps you here though....

im deep in a rabbit hole with covscript... every time I get past one issue there is something else more sinister... and I'm deep into the code at this point so it takes several minutes to compile enough to do a test and get information about the issues... so going slow.... just for fun I've tested it with some of the existing code base and the myriads of changes I've made seem to have broken other stuff as well....