| 16 Apr 2025 |
Tristan Ross | Sort of | 02:19:50 |
Tristan Ross | Most things should work. | 02:19:58 |
rosssmyth | I don't particularly care about most things though | 02:20:08 |
Tristan Ross | But if you find an issue with Zig, lmk since I maintain it. | 02:20:13 |
rosssmyth | I've not tried using Zig as a C compiler in about two years because of the mess I had triying to use it before, | 02:20:39 |
Tristan Ross | Yeah, though it's hard to know what the cases are without knowing what the cases are. So for now, we've stuck with a best effort thing. | 02:20:43 |
rosssmyth | https://github.com/NixOS/nixpkgs/issues/395349 | 02:20:58 |
Tristan Ross | Ok, you could try it now lol. A lot has changed in two years. | 02:21:05 |
rosssmyth | This is the arm-none-eabi | 02:21:08 |
Tristan Ross | Yeah, I'll have to look into this when I have time. | 02:21:34 |
Tristan Ross | Also, LLVM doesn't really use arch-os-abi. That actually might cause problems. | 02:22:03 |
Tristan Ross | arch-vendor-os-abi is a better way of doing it. | 02:22:13 |
rosssmyth | yes | 02:22:19 |
rosssmyth | I am glad LLVM tries to be mostly sane | 02:22:29 |
rosssmyth | Looks like Zig forwards the triples to the Clang backend now days. Which is great. I remember the blog post Andrew Kelly wrote about it being a drop-in replacement for Clang for cross-compilation and it just wasn't true at all when the blog post was written because the triples were so different | 02:23:44 |
Tristan Ross | Tbf, there's always going to be edge cases that aren't always going to be checked. | 02:24:34 |
rosssmyth | The edge case was...all of windows | 02:24:45 |
Tristan Ross | Oh | 02:27:33 |
| lazyLambda set a profile picture. | 03:24:14 |
| - joined the room. | 11:46:48 |
| 17 Apr 2025 |
| axel joined the room. | 18:02:30 |
FliegendeWurst | Are there really platforms where the byte order is different for floats and integers? | 19:09:55 |
FliegendeWurst | * Are there really platforms where the byte order is different for floats and integers?
I'm wondering, because I found this check: https://github.com/john30/ebusd/blob/25.1/CMakeLists.txt#L139-L165
But could not find any platform on godbolt that would trigger the other case. | 19:15:46 |
rosssmyth | For IEEE floats, no. | 19:38:59 |
rosssmyth | I think PDP had a funny thing where this was not true, but that was also before IEEE floats | 19:39:34 |
rosssmyth | * I think PDP had a funny thing where this was not always true, but that was also before IEEE floats | 19:39:50 |
rosssmyth | LLVM makes a lot of assumptions about the fp environment, so I would be surprised if llvm even supported such a thing. | 19:41:27 |
rosssmyth | * LLVM makes a lot of implicit assumptions about the fp environment, so I would be surprised if llvm even supported such a thing. | 19:43:28 |
trofi | Checking gcc source tree for case of WORDS_BIG_ENDIAN != FLOAT_WORDS_BIG_ENDIAN git grep -P '#define (FLOAT_)?WORDS_BIG_ENDIAN' https://bpa.st/raw/NKQQ I think I only see pdp11:
gcc/config/pdp11/pdp11.h:#define WORDS_BIG_ENDIAN 1
gcc/config/pdp11/pdp11.h:#define FLOAT_WORDS_BIG_ENDIAN 0
| 21:28:05 |
trofi | (and it's one of two targets(along with mmix) that explicitly defines FLOAT_WORDS_BIG_ENDIAN, mmix probably does it out of redundancy) | 21:30:35 |