IRC channel logs
2023-08-13.log
back to list of logs
<oriansj>as it is probably high time for M1 to gain a few super features over M0 <theruran>mihi: ah yeah, that's more info that I was missing <mihi>oriansj, when I may wish for super features in M1, I'd wish for a #DEFINEREC or similar which defines a word to multiple words which each are expanded again instead of passed verbatim. But I guess the downside is you cannot use those words in M2-Planet as that one needs to be buildable by M0... <oriansj>mihi: well we could use them in M2libc but not in the bootstrappable.c or in $arch/$OS/bootstrap.c files <matrix_bridge><Andrius Štikonas> Can't you already do that with two passes of M1? <mihi>stikonas, in theory you can. In practice you'd need to do lots of quoting since unfortunately running M1 output through M1 again is not idempotent. <mihi>so in my experience, in practice it is easier to have a bit of redundancy in M1 defs than having to quote everything to survive a second pass. But maybe I'm missing something easy :) <stikonas>well, some stuff is simple, just don't use labels starting with numbre <stikonas>mihi: by the way, what's the usecase for second expansion? <stikonas>do you want to do more of the arch independent M1? <mihi>getting M1 more arch indenpendent would be a nice side effect. I would have liked to make the M2 emitted code more similar between architectures: some constructs compile to a single DEFINE in one architecture and a plethora of them in otheres, making it harder to find bugs in the output in my opinion. <mihi>but of course, if in place, one could make M2 use same defines for more architectures more often. But as I said, that is moot point as M2 output needs to work with M0. <mihi>so feel free to scrap my idea <stikonas>mihi: in principle if properly done, multiple constructs is better <stikonas>i.e. there is only a small number of risc-v defines that I written down from ISA manual (just had to convert binary to hex) <stikonas>on the other hand, for x86 those defines are basically one big define for the whole assembly line <stikonas>so we only have those that are used in M1 defs file <stikonas>and if you add some new code, you often need to add new defines <oriansj>mihi: that idea is the same as the proposed M3 specializers <oriansj>basically M3 would be outputing only a single "perfect" architecture's assembly and separate programs (the specializers) would convert it from that to a single normal architecture (like x86, risc-v, etc) and apply archicture specific optimizations and transformations <oriansj>for example the perfect architecture could have infinite registers and the specializers could determine which values need to be in which registers to make things fast for the architecture in question. <stikonas>well, basically intermediate representation then <oriansj>basically start stealing good design ideas from gcc and clang. Build something good enough to build tcc (or GCC if one wants to shovel a bunch of work in) <oriansj>just ensure that it is buildable by M2-Planet and just have fun building a C compiler within the constraints <stikonas>oriansj: also it might be a good idea to steal some command line interface ideas from mescc <stikonas>i.e. it can create stuff like libc.a (just concatenated hex2 object files) <stikonas>but then it can link to those libraries with e.g -lc+tcc (automatically includes libc+tcc.a <oriansj>the original idea was to include binutils compatible assembly and object files <stikonas>oriansj: while that might be nice, it's probably not easy...