IRC channel logs

<muurkha>right, but even if riscv64 had the same syscall numbers as amd64, or if you had a libc, it wouldn't help much; it wouldn't allow you to run unmodified RV64 machine code on amd64 or vice versa

<muurkha>what allows you to write code and run it on both platforms is writing it in C instead of assembly, then compiling it with C compilers for each platform

<muurkha>libc and syscalls are not really relevant to that, except in the sense that libc is what is responsible for allowing you to call open() or write() instead of writing some inline assembly with a syscall instruction in it

<stikonas[m]>Very true. Though libc allows to only write platform dependent call once and not in each application

<muurkha>yeah, I guess that's true

<emilytrau[m]>`Can somebody please explain to me why it's called blood-elf? I've figured out all the other bizzare names (kaem, M2-Planet, MES) but this one still eludes me.`

<emilytrau[m]> https://github.com/NixOS/nixpkgs/pull/227914#discussion_r1185772170

<janneke>ACTION always assumed it had something to do with dwarfs

<[exa]>${BLOOD_FLAG} ftw

<stikonas[m]>emilytrau: are you going to fetch makefiles from master or from fixed commit?

<emilytrau[m]>fixed commit

<stikonas[m]>OK I think that's fine then

<stikonas[m]>If we rework coeeutils, e.g. use gash utils later

<stikonas[m]>You could still fetch an older commit

<emilytrau[m]>ya ya ^_^

<stikonas[m]>fossy: are you also fine with merging that coreutils PR?

<fossy>stikonas[m]: yes, I am ok with that

<fossy>stikonas[m]: can you once-over the CI thing in case i missed anything obvious?

<fossy>ill do gcc 13 this weekedn

<stikonas[m]>fossy: probably too busy until next week...

<fossy>no worries :)

<stikonas[m]>fossy: there might be another way to speed up sysc

<stikonas[m]>CFLAGS="-O0" might make compilation much faster (almost tcc level fast)

<stikonas[m]>Though binaries might be slower

<oriansj>probie: actually that is the very situation which we have builder-hex0 for. And it is in hex0 so it is so tightly connected to the host architecture that libc details don't matter.

<oriansj>muurkha: well the FORTH code itself might be portable across architectures and even the FORTH object code in some very special cases but the actual bits running on the processors by definition have to be different even for add r1, r2 (which does work on x86, AMD64, armv7l, aarch64, riscv32 and riscv64 if you use an assembler smart enough)

<oriansj>emilytrau[m]: it is called blood-elf because it kills the dwarf (stub) problem we had. [Because our ouput files needed generated dwarf stubs needed for objdump -d to get function names, which is what blood-elf produces]

<aggi>no, gcc compilation is much slower than tcc, even with -O0

<janneke>stikonas[m]: is there a chance that mescc's risc-v code could work with an older release of mescc-tools (for now?)

<janneke>or was it a mistake?

<muurkha>emilytrau[m]: also there is a playable race in World of Warcraft called the "Blood Elf": https://wowpedia.fandom.com/wiki/Blood_elf

<stikonas[m]>It might with small modifications

<stikonas[m]>But 64 bit m2 planet is broken

<stikonas[m]>So you'll need to mix and match tools and compiler...

<janneke>yeah, guess that's too tricksy

<stikonas[m]>janneke: you can always so 0.25.1 release with riscv later if you want amd64 stuff sooner

<stikonas[m]>Though we first need new stage0-posix release

<gforce_de1977>emilytrau[m] - the naming is really funny here: "explanation" is here, but should go ontop - https://github.com/oriansj/mescc-tools/blob/master/blood-elf.c#L567

IRC channel logs

2023-05-05.log