IRC channel logs
2026-08-31.log
back to list of logs
<matrix_bridge><Andrius Štikonas> Risc-v userspace bootstrap is possible, we know how to get from hex to GCC <matrix_bridge><Andrius Štikonas> It's just lower level bootstraps, e.g. kernel arw not done <matrix_bridge><Andrius Štikonas> Some simple kernel, similar to fiwix and builder-hex0 <matrix_bridge><Andrius Štikonas> I guess kernel devwlopment requires a bit more skill <matrix_bridge><Andrius Štikonas> But it's not out of reach for a single skilled developer with quite a bit of spare time to write <ekaitz>good stikonas! we didn't stay awake for months just to hear the boostrapping is not clear <matrix_bridge><Jeremiah Orians> Hmm seedling supports setting the carry and direction bits but has no way to save/restore the status register. <matrix_bridge><Jeremiah Orians> Which means that you can’t use it to write interrupts. <matrix_bridge><Jeremiah Orians> Which given a 10.4KB seed (which is the same size as the stage0 LISP interpreter). And no implementation available in any other language except itself; it is a non-starter. <aggi>> risc-v ... it's not out of reach for a single skilled developer... etc. <aggi>that's why it's ironic given Nvidia supporting risc-v and their budget involved <aggi>sorry for the noise, it's sunday, was goofing off for a moment <aggi>and from a practical perspective, risc-v remains a bit challenging with kernel and hardware support <aggi>because, with regards to linux, in practice you will need a most recent kernel version for risc-v often, and with it latest C11 extensions <aggi>which complicates the C-bootstrap further (even tinycc hasn't got _all_ C11 features) <aggi>given all this, nvidia and the like may stuff their risc-v wherever sun isn't shining <attila_lendvai>Jeremiah, seedling has been shaped with very specific goals in mind, but it's melleable if other goals are desirable. <attila_lendvai>Jeremiah, but i'm also not convinced about forth and reverse polish. i believe i can fork Maru (a lisp) into a smaller thing that would be very much like a forth, but with sexp syntax, i.e. without the reverse polish mental tax. <matrix_bridge><Jeremiah Orians> You do realize if you make ( be push onto the execute stack and ) be pop; FORTH then gets a Lisp like syntax. <attila_lendvai>Jeremiah, my problem with forth is not the syntax per se, but the lack of named variables <matrix_bridge><Jeremiah Orians> But FORTH does have named variables and locals too <attila_lendvai>well, a big enough forth does. the seed in seedling is tiny, and it's not trivial how to add named variables without paying with too much complexity. there's a plan now, but its development is not in focus currently. <attila_lendvai>but then it'll still remain reverse polish, parens and variables aside <matrix_bridge><Jeremiah Orians> ( + m n ) and ( IF ( < A B ) ( THEN C ELSE D ) ) don’t look reverse polish <matrix_bridge><Jeremiah Orians> Despite being executed identically to A B < IF C ELSE D THEN <attila_lendvai>well, i'm not experienced with forths. i have only played with seedling. maybe i should dig deeper then before having an opinion... :) thanks! <attila_lendvai>BTW, is any forth-like used in the currently working bootstrap story? <matrix_bridge><Jeremiah Orians> Well, there is duskOS that gets to M2-Planet and the FORTH in stage0 which is under 4KB (but it is possible for a 510 byte FORTH root like boot sector FORTH to implement everything in FORTH) <matrix_bridge><Jeremiah Orians> The biggest problem with FORTHs is like the biggest problem with LISPs; they are easy to implement but a bunch of them are incompatible with each other and once you tap into their real power; it can easily result in code that other people can’t understand. <attila_lendvai>well, that's a general problem with abstractions: if you climb the ladder, then you convert the complexity that derives from a large cardinality into a different kind of complexity... and there are many ways to do it wrong, so that e.g. it turns into a branfuck for others who try to understand it, or that it doesn't decrease the human effort to deal with it... but it's not inherently so. <attila_lendvai>but if the freedom to introduce abstractions is limited, then that guarantees that cardinality-derived complexity will hinder human understanding of non-trivial systems <roconnor>My RISC-V (user space) lazy combinator interpreter (without a garbage collector) executable is also currently under 4KB at 3220 bytes. <roconnor>I'm not entirely sure how important smallness is really though. <roconnor>And while combinators are even less readable than Forth, it doesn't take long to climb out of combinator syntax into something more readable. <matrix_bridge><Jeremiah Orians> Well if size was the goal Octal would win (it can be implemented in only 14 instructions) but that is even worse than writing in hex <matrix_bridge><Jeremiah Orians> And even cc_* is a 14KB program. And one can do an impressively fast Lisp in 10KB <matrix_bridge><Jeremiah Orians> Although, I wonder if a pattern matching typed lisp without macros was an evolutionary path avoided for a reason. <roconnor>Isn't a pattern matching typed lisp without macros the same thing as Standard ML? <aggi>> even cc_* is a 14KB program <aggi>which, with the current live-bootstrap reference for x86 cannot compile kernel, or binutils/gas <aggi>then finally, all i see is three different practically relevant assemblers (as86, yasm, gas) none of which fits into a direct dependency chain for bootstrapping <aggi>> problem with FORTHs is like the biggest problem with LISPs; they are easy to implement but a bunch of them are incompatible with each other <aggi>then there's different opcode formats below, each vendor re-inventing the wheel <aggi>to memorize different mnemonics for <aggi>reminds me, besides FORTH and LISP in the early days BASIC interpreters were common <aggi>which is what TI-84 and similar systems ship with still <aggi>minor detail with those, Z80 and X86_16 are closely related <aggi>hence the transition from such calculator's assembly syntax to some IBM PC system got a flattened learning curve <aggi>and BASIC high level language available with either - don't know how many incompatible variants of those existed <aggi>there's some ANSI/ISO standard for it, BASIC i mean, didn't know <aggi>i doubt however it would be a suitable intermediate language to bootstrap a C-compiler with <aggi>given the fact feasibility of bootstrapping a C-compiler in assembly (cc_x86) was demonstrated, i prefer C over BASIC any day <aggi>and with pnut-cc feasibility of bootstrapping a C-compiler _without_ any further intermediate interpreter/language is possible <aggi>in this case, instead of any IL/interpreter it's merely a limited language feature-set to cc-x86 to implement a complete C-compiler itself in C <aggi>for that matter, too C-lang can be utilized with JiT-compilation (interpreting), which is what tinycc supports <aggi>seems to me, C just isn't a most favorable choice for an interactive/shell-type language (FORTH and LISP seem neither btw.) <roconnor>Actually, LOGO seems like it could make for an nice interactive shell-type language. <aggi>a deficiency of shell seems math expression, desirable with a TI-84 type computer <aggi>from a practical perspective, the combination of assembler+C+shell seems reasonable, each doing what those were designed for <aggi>however, a TI-84 hasn't got a keyboard, so you can't type C with it <attila_lendvai>i'm super annoyed by shell, the language... it may have historical relevance or usefulness, but today... i say, god kills a kitten every time someone opens a new.sh file and adds more than 5 lines! :) <ekaitz>attila_lendvai: some dude thought the same, created python and now we have to deal with it too <attila_lendvai>ekaitz, heh, fair enough... :) i don't know what's the right way, but interacting with shell programs is a painful experience for me, and has been for the entire 4 decades i'm programming.