IRC channel logs

2023-08-12.log

back to list of logs

<oriansj>I have an idea for a feature in M1-macro but I wonder if anyone has a better refinement: #IFDEF blocks
<oriansj>The goal being we would no longer need libc-core.M1 and libc-full.M1
<oriansj>instead we have the __init_io() use asm("#DEFINE STDIO.C 1"); and then if that define is not found, the block of assembly in libc.M1 can be skipped entirely and we can stop being conerned of if the program uses stdio.h or not
<muurkha>hmm
<stikonas>oriansj: I guess makes sense...
<stikonas>and it shouldn't be too hard
<stikonas>but I guess only for C version of M1, not M0
<stikonas>oriansj: though maybe it makes sense to do it for the next release?
<stikonas>we'll probably want a new stage0-posix release soonish for riscv64 bootstrap
<theruran>why this recursive definition in the stage0-posix README?
<theruran>"M0 is an architecture specific version of M1 which will come later." ... "M1 is a cross-platform version of M0, along with being much more powerful and faster."
<theruran>and is there nothing written in M0 because `find . -name "*.M0"` returns nothing
<stikonas>theruran: feel free to update it, we have another description here https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst#8m0
<theruran>looks like M1 is barely mentioned: "and C version of M0 called M1. These are more capable than their platform specific hex counterparts and are fully cross-platform."
<stikonas>there isn't that much more to it though
<stikonas>it's purpose is exactly the same
<stikonas>it's just that C version has better error checking, better argument parsing and supports all features that individual arch specific versions of M0 support
<stikonas>so e.g. both x86 and riscv64 support is in M1
<stikonas>but M0_x86 can't assemble riscv64 assembly
<oriansj>stikonas: yeah, I'd probably get that feature in the next mescc-tools release but I probably want to think through details to make sure I don't introduce anything breaking backwards compatibility