IRC channel logs

<matrix_bridge><gtker> Stikonas, oriansj: cc_* can only use bootstrappable.c/h from M2libc, right?

<matrix_bridge><Andrius Štikonas> gtker: yes

<oriansj>it is quite limited by design (makes it fast to port and easy to reason about but dog slow in terms of generated output)

<matrix_bridge><Andrius Štikonas> gtker: while you are here, at some point we tried to look at prefix/postfix ++/--. It might be that we were hitting similar kind of corner cases as you when you looked at pointer arithmetic.

<matrix_bridge><gtker> Andrius Štikonas: Yeah, I'm dreading having to implement it because I'm pretty sure it's going to be painful. At the very least a post/prefix operator as a statement would be equivalent to "a += 1" so that's going to be easy but when it's mixed with all kinds of expressions I predict pain

<matrix_bridge><gtker> oriansj: Has it been ported to the assembly languages or do they use the C code?

<matrix_bridge><Andrius Štikonas> Exactly... All those corner cases are painful in M2-Planet

<matrix_bridge><Andrius Štikonas> cc_* are all written in assembly

<matrix_bridge><Andrius Štikonas> Hence, we want it really simple

<matrix_bridge><gtker> But when compiling M2-Planet with cc_* we can use the expanded stdlib?

<matrix_bridge><Andrius Štikonas> No

<matrix_bridge><gtker> Do we use an assembly version of bootstrappable.c?

<matrix_bridge><Andrius Štikonas> No, there isn't

<matrix_bridge><Andrius Štikonas> bootstrappable.c is C with inline assembly

<matrix_bridge><Andrius Štikonas> Or is it bootstrap.c ... I might be mixing them up

<matrix_bridge><Andrius Štikonas> Anyway cc_* is written in assembly, so no C lib needed

<matrix_bridge><Andrius Štikonas> We use it to build M2

<matrix_bridge><Andrius Štikonas> That uses simple libc

<matrix_bridge><Andrius Štikonas> We actually need simple libc until we replace M0 with M1

<matrix_bridge><Andrius Štikonas> After that we can use full M2libc

<matrix_bridge><gtker> So we could use the full libc to build M2-Planet?

<matrix_bridge><gtker> Is M2 the same as M2-Planet? 🤔

<matrix_bridge><Andrius Štikonas> Well, we build M2-Planet twice

<matrix_bridge><Andrius Štikonas> First with cc_* and assembly tools

<matrix_bridge><Andrius Štikonas> In stage0-posix this is outputted to M2 binary

<matrix_bridge><Andrius Štikonas> The we migrate to fully C toolchain

<matrix_bridge><Andrius Štikonas> (Also build blood-elf for some minimal debug info)

<matrix_bridge><Andrius Štikonas> And use M2 binary to rebuild M2-Planet

<matrix_bridge><Andrius Štikonas> New binary is called M2-Planet

<matrix_bridge><gtker> Ah, OK, that makes sense

<matrix_bridge><Andrius Štikonas> M2 is slower

<matrix_bridge><Andrius Štikonas> Since it was built with just minimal bootstrap c library

<matrix_bridge><Andrius Štikonas> No buffering in I/O and other goodies...

<matrix_bridge><gtker> But they have the same features?

<oriansj>gtker: it is built from the same source code and minus some subtle behavior differences, M2 and M2-Planet should produce idential outputs

<oriansj>(which are exceptionally rare but can occur and are a bitch to find)

<stikonas>oriansj: by the way, with that unxz thing, turns out riscv32 is also not working, I just didn't see segfault because it existed with non-zero exit status before segfault (but after unpacking .tar file). So something is wrong on both rv32 and rv64 :(

IRC channel logs

2025-02-17.log