IRC channel logs
2021-11-21.log
back to list of logs
<oriansj>stikonas: ok; so its just your best guess (which is probably right) <stikonas>yaeh, I hope it's right. But it's not a blind guess cause I had to make similar adjustemts to other M1 code when porting from rv64 to rv32 <stikonas>anyway, I'll probably leave it for some time and will try to finish M2 macro functions... <stikonas>I downloaded your tokenization diff but as you have said, it will need morre changes <oriansj>stikonas: yeah, the preprocessor will be the most heavily modified as previously we only assumed \n mattered but now we know C preprocessing is a whitespace sensitive grammer. <oriansj>which makes C even weirder being both whitespace sensitive and not whitespace sensitive at the same time. <stikonas>yes, although in reasonably independent sections... <stikonas>preprocessor can even be a separate program <oriansj>perhaps a hold-over from when the preprocessor was a separate program maybe? <stikonas>yeah, right now that diff just makes M2-Planet loop forever, but I guess that's expected <oriansj>makes me wonder if the mesoplanet plan might have been a better idea long term <stikonas>before it was integrated into M2-Planet? <oriansj>well right now every change with the preprocessor could break everything in a hard to debug way <stikonas>although we almost get the same thing with -E <oriansj>it is a separate program to extract out all of the preprocessor crap <oriansj>and dump easy to validate M2-Planet C code to use <stikonas>well, gcc also has cpp program which does preprocessing <oriansj>On one hand it solves a few potential bug cases in M2-Planet when bootstrapping <oriansj>as cc_macro is the place most likely to introduce sensitive bugs and cc_* tends to be kinda type deaf <stikonas>although, how much more macro changes do we expect after this? <oriansj>and I'm more than happy to grant push access to Mesoplanet to you if you want to use it <oriansj>as it could grow to be a full independent C preprocessor <oriansj>which would save me trouble on the M3 work too <stikonas>is that we can use more advanced C stuff <oriansj>more typedef support and can quickly leverage new M2-Planet functionality as we add it <stikonas>anyway, it's an idea definitely worth considering <oriansj>well right now macro support in M2-Planet is 17% of the entire codebase <oriansj>and that isn't even counting the extra lines in cc_reader that is needed to support storing the extra context data and cleaning it up after preprocessing <oriansj>which will definitely make a meaning performance improvement when bootstrapping as the first build of M2-Planet is with M0 and can be a bit slow <oriansj>And that is the slowest piece in the entire chain <fossy>i don't think performance optimizations in stage0-posix (except for maybe some other archs) have much use at this point <fossy>on i386/x86_64 at least the whole stage0-posix runs in like <1 minute <fossy>iirc on my pentium m machine it ran in <2 mins <oriansj>and honestly the only real advantage of a separate C preprocessor is #include support could be included (with a flag to disable it) while preserving the ability to work on bare-metal <oriansj>which would simplify M2-Planet's long file list to just the C output of M2-Mesoplanet <oriansj>and M2-Mesoplanet wouldn't need to have all files explicitly specified like M2-Planet does after we add #include support <oriansj>also yt already has push access to the repo and I am more than happy to give push access to stikonas (and you too fossy if you wanted) <oriansj>which when combined with the #ifdef and #undef can be used to support C's circular #includes which is entirely impossible with M2-Planet's -f file method <oriansj>to be honest the flag need only turn off #include support and if the output of a file with manual -f selection doesn't match what #include does, we can know it would only be an issue on bare metal bootstrapping. <stikonas[m]>Well, #include support would be nice. But yes maybe performance itself doesn't matter too much... <stikonas[m]>Hmm, another slightly orthogonal idea, is it worth having some command line flag in M2 to automatically launch other tools? <oriansj>M2-Mesoplanet spawns M2-Planet, blood-elf, M1 and hex2 unless given a flag to disable that <oriansj>So using M2-Mesoplanet will be much more like traditional C compilers and M2-Planet and the rest just work quietly behind the scene and the user need not see them <oriansj>That way the user experience can be improved on POSIX but the bare metal build process can still be preserved. <oriansj>and M2-Mesoplanet can leverage enviromental variables to know where to look for the library files <oriansj>something M2-Planet can not expect when bootstrapping <stikonas[m]>Hmm, but we then first need to move out M2-Planets improvements to mesoplanet <oriansj>but it should be a pretty close to 1:1 for all files except cc.c <stikonas>oriansj: so Mesoplanet is then not cc_* compatible? <stikonas>i.e. we don't need to keep stuff like // CONSTANT? <stikonas>or are we going to remove all preprocessor stuff from M2-Planet? <stikonas>in which case I guess we can still use stuff like += but not #define CONST const <oriansj>stikonas: nope only needs to be M2-Planet compatible <oriansj>we can strip down M2-Planet's C preprocessor functionality to what subset we like <stikonas>because we'll have to build Mesoplanet with M2-Planet... <stikonas>it looks like it's mostly stuff like #define TRUE 1, and arch-defs like #define X86 2 <stikonas>in principle they don't even have to be defines <oriansj>yep which are trivial to convert to CONSTANT <stikonas>oh, Mesoplanet still uses functions rather than M2libc... <oriansj>trivial to add a M2libc git submodule <stikonas>oriansj: didn't have much time to look at thing yet, but added M2libc <stikonas>and since I took cc_macro.c from M2-Planet, it should now incorporate latest status that we have in M2-Planet <stikonas>(cc.c might still need some updating since that one can't be fully replaced) <oriansj>I'll look into it and add a few more basic tests to get things started in the right direction <oriansj>also did we want to detect the architecture for native builds by default with M2-Mesoplanet? <stikonas>but I think we shouldn't rely on #ifdefs... <stikonas>actually, making them optional might work <oriansj>well for bare-metal I can do a cc-minimal.c which hard codes the setting and skips the loading of enviromental variables <stikonas>if we remove preprocessor support from M2-planet then first build of mesoplanet might not be able to do that <stikonas>yes, I think we can do something similar... <stikonas>it might be in some other file, doesn't have to be cc-minimal <oriansj>stikonas: looking up the native architecture is something we can copy from get_machine <oriansj>cc-minimal.c is just an example with a single hard-coded arch <stikonas>I thought about that too but has't thought trough, i.e. which option is better <oriansj>so that anyone can convert it when they do their bare-metal bootstrapping <oriansj>right now the only arch it needs to specify is knight-native <stikonas>actually, it doesn't even have to be a separate file <stikonas>I think M2-Planet will just ignore all the previous lines... <oriansj>well yeah #anything was just a line comment for M2-Planet previously <oriansj>and it was preserved in --bootstrap-mode <stikonas>i.e. #ifdef __i386__ \n arch=x86 #elif arch = default #endif would just work <stikonas>or maybe we'll just keep what we already have in M2-Planet <oriansj>well right now the only architecture specific behavior changes would be defining an architecture variable and a slightly different path when spawning <stikonas>so stuff like _i386 and spawning M1 --architecture $ARCH... <stikonas>oriansj: maybe we can have M2-Mesoplanet -E NOT spawn and spawn without -E? <stikonas>and in stage0-posix we might need to build hex2 and M1 first <stikonas>--bootstrap mode needs some simplified M2libc <stikonas>we can just build M2-Mesoplanet after hex2 and M1 <oriansj>and now M2-Mesoplanet detects local architecture and sets accordingly so we don't need to do --architecture anymore <oriansj>we can just use an enviromental variable later if we wish to support overrides <oriansj>and we probably want to create a temp file proper for spawning <oriansj>and we should probably be able to pass the M2libc path via an enviroment variable too and just assume ./M2libc otherwise <oriansj>say export M2LIBC_PATH=../foo/bar sort of thing