<xentrac>I feel like the latter two categories may vary somewhat depending on what kinds of guarantees your kernel provides you <OriansJ`>Hagfish: fair but I prefer to think of it more of how can we find just 1 more person to help with the M3 or mes-m2 work <OriansJ`>MesCC goes even further and actually implements standard libraries as opposed to just essential C functions like M2-Planet does. <OriansJ`>fossy: ideally a kernel we can put on alot of different hardware platforms, that provides a standard file system like ext2 and just enough functionality to run GCC building Linux. <OriansJ`>xentrac: well most BSDs have a linux syscall binary compatibility layer and a bootstrap kernel only needs to include a subset of linux syscalls. So seperate libraries for kernels might not be needed (or atleast until someone cares enough to create a bug report and test that we fixed it) <OriansJ`>At this point, besides a handful of patches that janneke did to get TCC buildable by MesCC and the code I wrote to just parse ELF headers; no work has yet been done on M3. <xentrac>but I was talking about the degree to which your kernel interface might interact with architecture-dependent functions like longjmp() that don't necessarily interact with the system call interface <xentrac>longjmp() in particular burned me relatively badly because MacOS implemented it as siglongjmp(), slowing down my program by a factor of about 30 <yanmaani>OriansJ`: Concretely, what can you do do help with the M3 or mes-M2 work? <bauen1>fossy: regarding your thoughts on the arduino, that doesn't cover attacks against bugs in the code or prevent against inserting malicious input <bauen1>but it does make subverting the code bloody hard <bauen1>my kernel sadly hasn't seen much progress <bauen1>i did finish elf64 loading and setting up a stack with envp, argv, argc, ... <bauen1>so i can now run a simple hello world statically linked to musl <bauen1>i think i'll do a bit of code cleanup too before i start hooking up syscalls <OriansJ`>xentrac: fair but speed isn't a primary concern, so much as correctness, simplicity and maintainability. <bauen1>if it can run tcc then i could use it to compile my kernel and userspace with it <xentrac>OriansJ`: perhaps for some of the people who would want yanmaani's libc, speed is important <OriansJ`>yanmaani: I am going to assume you meant what could yanmaani possibly do to help M3 or mes-m2; well one could either work on improving macro support in mes-m2 or help with the creation of a binutils compatible assembler buildable in M2-Planet or converting TCC's C abuse into something simpler that M2-Planet can compile but while preserving its functionality. (This can be done on a per file basis) <OriansJ`>bauen1: well it only takes a little more effort than supporting TCC to be able to run GCC and thus be able to compile the world <OriansJ`>we can't do everything good and amazing, software requires tradeoffs. So it is far better for us to be honest and say "hey this is what is most important to us" <xentrac>OriansJ`: sure. and it's helpful to have a narrow focus <OriansJ`>because at the end of the day, we all are going to die eventually and if no one understands what we did; then this would have all been for nothing. <xentrac>up to yanmaani to decide what they prioritize <xentrac>certainly speed is minimally important for bootstrapping compilers! <rain1>i like a compiler that can bootstrap itself fast <OriansJ`>but it possible as a byproduct of having a simple design. <OriansJ`>rain1: 1M/sec for M2-Planet (when built by GCC -O3) <OriansJ`>rain1: well mes-m2 is an order of magnitude faster than mes.c <OriansJ`>but I really need to fix the macro support to better match guile and finally be able to interpret xentrac's scheme compiler in scheme properly <OriansJ`>now part of me wants to do the full and proper scheme syntax-case in C, so we can finally bootstrap guile's syntax.pp but on the other hand doing that instead of the M3 work would delay me a good bit. <OriansJ`>but the tasks become much bigger going forward, as having a proper minimal C with structs converts the problem to just one of brute force as opposed to figuring out the clever way to parse C in a trivial manner to allow a reasonable assembly implementation. <OriansJ`>I mean with M2-Planet and mes-m2 bootstrapped from hex0 in mescc-tools-seed. We are literally at the verge of being both done and years away from done at the same time. <OriansJ`>It is "just make mes-m2 run MesCC" or go the long way with M3 because scheme bootstrapping is a macro infested hell hole with more missing steps than a one legged tango dancer. <OriansJ`>The longer one spends in assembly, the less lisp makes sense. yes syntax-case is powerful but you know what is really powerful? code people don't need to spend 3 months decompiling in their head to figure out what the hell you are trying to do. <OriansJ`>the problem is the power of lisp is also its greatest weakness. <rain1>the hygienic macro space is rather complex <rain1>i don't know if the scope sets theory has helped make it simpler <xentrac>Well, I've definitely had the experience of not understanding how to use a Lisp construct until I understand how it's implemented. <rain1>it has clarified the theory of hygienic macros but implementation is still really hard <xentrac>But I think the fact that the theory is clear and simple makes it a lot easier to use once you do understand it. <OriansJ`>rain1: and we would need to do it in M2-Planet C <OriansJ`>I can do alot of scheme primitives with ease but syntax-case is alot that has to be done in a single step <OriansJ`>as there are no half-steps to getting it working <xentrac>I think I suggested before implementing syntax-case in a language with syntactic closures. <OriansJ`>xentrac: so bootstrap another language to solve the scheme bootstrap problem? <xentrac>I think syntactic closures are dramatically easier to implement than syntax-case (or even syntax-rules), and powerful enough to make the implementation of syntax-case itself tractable. <xentrac>Not a whole other language, just a slightly larger subset of Scheme. <rain1>I agree that syntactic closures are the simplest way to get hygiene, it's a nice system <OriansJ`>xentrac: I can't build it unless I have a solid idea of what needs to be done <xentrac>You could also implement syntax-case very carefully in an unhygienic macro system, which is trivial to get working <rain1>the benefit of the scope sets stuff is that it lets you pause evaluation and resume it, and move stuff across module boundaries and things. Nothing that we need to just compile some code once. <OriansJ`>if mes-m2 just needs to become a seed-scheme to enable a proper scheme written in scheme to do the job, so be it but I am not the man who would be able to do everything. I would need scheme programmers to take the scheme half and give me well defined functionality I would need to implement in mes-m2 <OriansJ`>Look, I have done the work on providing a bootstrap from nothing to a rather complete C and I am willing to do the steps to get the scheme bootstrap started but honestly someone else needs to be responsible for the scheme bootstrap work in scheme. <OriansJ`>look janneke spent the last few years growing mes.c with mescc and guix is only getting more and more dependent upon guile. fixing that is a huge task, especially since there is no visible evidence that the scheme bootstrap is ever going to get easier. <OriansJ`>in all honesty, it is starting to look like bootstrapping scheme is going to be a harder task than bootstrapping GCC <OriansJ`>M2-Planet's C tokenization is simpler than mes-m2's s-expression tokenization <OriansJ`>and I poured way more time into mes-m2's tokenization to try to make it simpler. <OriansJ`>I guess, one could say I am begging scheme developers for the love of god to care about bootstrapping their own language enough to help me help them. <rain1>guile is one of very few that cares about the bootstrap <rain1>it's such a neglected thing in compilers <rain1>which is mad because everybody has to do it at some point to get running code <stikonas>well, many people use binary-only distros, so they automatically appreciate bootstrappability less <stikonas>if you use source based distro, it's so much more apparent <rain1>but the compiler authors - do they think of themselves as stage magicians? <rain1>remove all the scaffolding and let people wonder how this binary possibly came to be <stikonas>somehow they all think that you have to write compiler in its own language or its useless <rain1>yeah that seems to be the thing <rekado_>there’s a cost attached to keeping the bootstrap around <rekado_>and building a compiler in the target language is a way to quickly build a “serious” program together with the language <rekado_>so there’s an incentive to get to self-hosting as soon as possible while also avoiding to keep intermediates around (which is the most obvious choice for bootstrapping when one has not planned ahead) <V>stikonas: yeah, unfortunately. so many people I've talked to think that bootstrapping their compiler in itself is the most important thing & I'm constantly dying inside <V>For all my language projects I'm absolutely keeping a very direct path from C; if I end up writing something appropriate to replace C I'm *still* keeping a C implementation because it's just that important ***stikonas_ is now known as stikonas
<xentrac>well, it's pragmatically a very useful thing when what you want is to get your language running, not to have reproducible builds for it <V>if you want to get your language running, you have a perfectly working C compiler :)