1. 26
  1.  

  2. 3

    This was complied via WASM rather than a direct LLVM back-end. I’m curious how much overhead that added.

    1. 4

      LLVM generated the WASM binary, but yeah, not the PEF binary, that was CodeWarrior.

      The “WASM-to-C” approach (e.g wasm2c and w2c2) has low overhead, for CoreMark (C) using w2c2 it was roughly ~5-10% when I last measured it, I don’t know what it is for Rust code.

      1. 2

        Especially when all the pieces are likely to exist - see what was done for Swift.

      2. 2

        My first thought was “does LLVM support m68k?” and my second thought was “oh no” because I saw the wasm tag. ;)

        Making a wasm->c compiler is a very clever way of enabling a whole bunch more targets for anything that can target wasm.

        1. 2

          LLVM supports m68k, but MacOS 9 does not. :)

          1. 2

            What do you mean? 68K apps run fine in Mac OS 9. Unless you mean that Mac OS 9 won’t boot on a 68K Mac, which is true.

            1. 2

              I’m also not sure what was meant, but it’s worth noting that it isn’t sufficient for LLVM to support the architecture, it also needs to support the platform to understand various bits of the ABI. LLVM dropped support for PowerPC Mac targets recently (and never supported Classic MacOS), even though it does support PowerPC with other operating systems.

              1. 1

                The 32-bit AIX target has an identical ABI to the classic Mac OS, so a lot of the work on the compiler-side is done. You’d just want other pieces like PEF support, bindings, etc…

                1. 1

                  In particular on the ABI side, my understanding is that classic Mac PPC has it’s own custom executable format not supported by PPC, so it’s definitely easier to use an existing Mac C toolchain than implementing a custom linker script to support that.

              2. 1

                It’s PPC? I forgot.