Encoder does not compile on MacOS 10.15.3 due to lack of std::popcount

[Aeroform-se]

Hi!

I'm trying to compile the encoder using make on MacOS 10.15.3 (also tried 10.13.1). Make simply errors out with "./framebuffer.hpp:260:27: error: no member named 'popcount' in namespace 'std'; did you mean '__popcount'?".

I tried updating to Make 4.3 (from the 3.81 shipped with MacOS). Unfortunately it did not help.

Could you perhaps share a precompiled version of the encoder?

Thanks (this project is beyond cool!)

[Aeroform-se]

Solved!

To compile with Make: Edit "ruler.hpp", "framebuffer.hpp" and "compressor.hpp" to:

Include "builtin.h" (see https://github.com/nemequ/portable-snippets/tree/master/builtin for details)

define PSNIP_BUILTIN_EMULATE_NATIVE

and also replace "std::popcount" with "__builtin_popcount" in the same files.

It now compiles and runs fine!

[fstark]

Sorry, I haven't see your defect report sooner.

As std::popcount is standard C++20, I guess your compiler is too old. Is it a C++20 compiant compiler?

It compiles fine on my Mac 11.4, with

Apple clang version 12.0.5 (clang-1205.0.22.9)
Target: x86_64-apple-darwin20.5.0
Thread model: posix
 InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Can you give me your version of the compiler?

If too old, I can workaround the lack of native popcount in a more standard way (in fact that's what the code used to do), by either using another C++ feature:

std::bitset<32> b{ v };
return b.count();

or computing it "by hand":

int mypopcount( int n ) {
    int count = 0;
    while (n) {
        count ++;
        n &= n-1;
    }
    return count;
}

as modern compiler will substitue the right SSE4/BMI instruction : https://godbolt.org/z/WvEjWh9oK

Let me know, and have fun in the meantime.

[fstark]

Added a fallback for std::popcount that should run fine on non-std C++20 compilers. Please let me know if stock source code compiles fine now.

[Aeroform-se]

With the fallback it now compiles fine with the below versions, thanks!

for your previous question:

I simply tried to compile with "make" in MacOS terminal as per the instructions. I've never compiled anything or written a single line of C so really not an expert here haha. I tried updating make, but looking now it might have been I have to update clang separately? This is the versions I have now (shipped with MacOs 10.15.3 that didn't compile):

make -v GNU Make 4.3 (updated from 3.81 in trouble shooting) Built for x86_64-apple-darwin19.6.0 Copyright (C) 1988-2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

clang -v Apple clang version 11.0.0 (clang-1100.0.33.17) Target: x86_64-apple-darwin19.3.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin

[fstark]

The Makefile is so trivial, it could probably run with a make from 1990. It is the compiler.

std::popcount is a late C++ addition, and Apple often even diverge from the linux version (because godbolt is telling me that std::popcount works on clang-11.0.0 : https://godbolt.org/z/Kj35E7EKr ).

Don't update clang on OSX, it is not worth the pain. For now, I'll just try not to use bleeding edge features (but I can't guarantee). At worse, I'll build a binary.

Have fun, and don't hesitate to tell me how it goes -- or submit bugs / enhancement requests !

(I mean, any issue you have, even seemingly trivial things like documentation or weird surprises, are interesting.).

[fstark]

(Unsure how to contact you)

Beware, new player is INCOMPATIBLE with existing flims. You will need to re-encode your old flims with the new version to be able to play. This should not happen again anytime soon. Let me know if this is too much of a burden.

[Aeroform-se]

Thank you for letting me know! Do you have any list of changes? The ”old” player works perfectly for me so might just stick to that one. Can also report it works just fine under a 68040 upgrade with no issues whatsoever!

[fstark]

Can also report it works just fine under a 68040 upgrade with no issues whatsoever!

Not a surprise, but good to know anyway!

FYI, there is a list of changes a) in the commits, b) hidden as a 'STR#' resource in the resource fork. I don't think they are easy to follow, though.

The core reason for which I had to change the format is "complicated". I want to get MacFlim working on older macs and in environments where real-time is not too important (ie: having silent flims playing as demos, even if they are not at the "right" speed. Silent flims are much more resilient to I/O issues).

So, in the version you have, the encoder tells the player a lot of details on how to allocate and use memory for playback. This is gone, and, while the player is much more complicated internally, it now supports for the Mac XL (ie: the Lisa 2), the Mac 512K (with non-scsi hard drive), and pave the way for a work in progress on getting (silent) flims to play via ethershare (fingers crossed) and maybe memory-constrained floppy play for the 128K (one can dream). It also have optimized playback on the Macintosh Portable via specific assembly routines.

I also added a version number, so hopefully I should be able to support this format for a long time.

Anyway, just making sure you don't git update the encoder and get into issues. I would suggest you to update, but, if you have created custom flims or if it is difficult to transfer flims to your hardware, you may want to be careful and/or wait a bit.

There is no change that impacts "standard" SE/30 playback, so if that's what you do, you don't miss anything by delaying update ( there is no SE/30 specific player improvment planned, but, as no-one entered any issue, I guess it is just perfect :-) ). Beware that flims on the website are now incompatible with your version, though.

Have flun!