<dddddd>cooperation from some kernel would be great, but it's not necessary <dddddd>M2-Planet compatible from scratch makes some sense too <OriansJ>fossy: don't forget to do "make kaem" when testing <OriansJ>dddddd: to a degree but it wouldn't be the first program to be converted to be built via M2-Planet <dddddd>who updates mescc-tools at savannah.nongnu? <dddddd>ok, I'll mirror your repo meanwhile <OriansJ>the savannah repo is the official; the github is for quick merges and pull requests <OriansJ>(I am far more willing to have a broken commit on github than on savannah) ***fosslinux is now known as fossy
<OriansJ`>I'll be updating mescc-tools-seed shortly ***OriansJ` is now known as OriansJ
<OriansJ>I guess it is time for mescc-tools-seed to have some test answers <OriansJ>now make clean test-amd64 and make clean test-x86 will do what is expected <OriansJ>people please take the time to check if mescc-tools-seed tests pass locally for you <fossy>parsing strings in m2 planet is hella annoying <fossy>here I was thinking that I had working variable substitution but noo not if its in the middle of a token <janneke>yeah, i have great expectations for gash <OriansJ>fossy: well M2-Planet lacks alot of string handling functions because I was able to engineer my way around having them. <OriansJ>now I can help you make some string primitives that help you if you would like <fossy>OriansJ: and well m2 planet isnt really made for string parsing <OriansJ>fossy: ummm, that is basically the heart of what a C compiler is <fossy>I just need to be more careful with edge cases <OriansJ>well one can always add restrictions to catch such cases. <fossy>which c compilers are developed around strings? <OriansJ>what do you think "if" "while" "asm" and "goto" are? <OriansJ>strings that when matched case the state machine to perform specific generation of assembly <fossy>oh, right, I get what you mean <OriansJ>also you know you can create a custom struct for the storage of shell variables right? <fossy>yes, havent done that yet because I havent needed it <OriansJ>then only have to handle string generation at one place and the string assignment at another. <fossy>but I think that is a good idea in the long run <fossy>would make the code rather cleaner <OriansJ>think far less about code, far more about what data structures map well to the problem space <fossy>I have never thought enough about the high level overview of a program <OriansJ>with the right data structures, the code become simple to understand and reason about. Remember the goal isn't efficiency but clarity <OriansJ>fossy: for every project that isn't super computing <OriansJ>Code is for humans to read and for computers to incidentally execute <OriansJ>If the code is clean and simple, it is easy to make fast <OriansJ>M2-Planet (built via gcc) can compile over 100KLOC/s <OriansJ>No fancy tricks, no crazy optimizations; just clean code doing simple things with a clean data structure <fossy>Like using a linked list for tokens <OriansJ>there are faster data structures, more efficient sort implementations, etc but by keeping everything simple it makes future conversions possible and easy. <OriansJ>understanding of what you are doing and why is key to writing the code that will do the right thing. <OriansJ>the first rule about art is you must know the rules before you can break the rules. <fossy>I think my dad has a physical copy of it, the cover looks vagualy familiar <OriansJ>K&R C covers alot of the rules one needs to know about C <OriansJ>take the time to absorb why they write code that way <fossy>And pausing to do the exercises (it has those right), one would assume <OriansJ>or just writing code for yourself to get a feel for it <OriansJ>good code is like poetry; profound, moving and deceptively simple. <OriansJ>Being clever is one's greatest enemy because debugging is twice as hard as programming. <fossy>I often get frustrated with my not so poetic code <fossy>I want my code to look good the first time <fossy>But I know thats not going to happen <fossy>Its not how anything works, youre right <OriansJ>nothing you make will be perfect but did doesn't mean what you make can't be beautiful <OriansJ>you will learn in time and with effort your code can become more beautiful than mine <OriansJ>remember to keep striving for better and you'll get much farther than you can dream. <OriansJ>The hard part is when you are starting in a field where you have natural taste/talent. Because you are better at spotting your own failings and it takes longer to get to the skill level where you start to feel good about your own work. <OriansJ>well I am trying to figure out the correct way to preserve lexical scope in mes-m2 but also allow future references <rain1>i didn't realize that m2 could have lexical scope <rain1>that seems like an advanced feature for so low on the stack <rain1>oh i must have meen thinking of m1 <OriansJ>fortunately M2-Planet enables one to largely ignore everything about M1 and hex2 while working <OriansJ>as cc_* and up all support lexical scoping by default <OriansJ>M1 and below down have a function construct so the very concept of scoping is non-applicable. <rain1>I think the way i handled future references was to process the code twice, once to just create a list of top level definition names and then second time to evaluate them with an environment that bound them all to #f <OriansJ>It resolves the forward reference problem in a very ugly way <OriansJ>I just realized I've been working on bootstrapping guix since 2016-05-01 (when I announced on #guix that I completed the initial hex program for AMD64 and was working on exec_enable in hex); although discussions about reducing guix began around 2016-03-21. janneke I guess I wish I had more to show for nearly 4 years of work. <deesix>OriansJ, you have a lot to show, worked hard and made many sacrifices for it. Indeed, you push yourself a lot; be gentle to yourself (: <deesix>This is not a competition IMHO and there's only the hurry you impose (which feel too much sometimes, to be honest) <deesix>Now, if one have to met some deadline that's another history. But it's not the case AFAIU. <deesix>So, just have fun and create that poetry you talked about earlier, which takes time. <OriansJ>half of that time was wasted on dead ends; which taught me a valuable lesson [why C won: It is just better for building foundations] <dddddd>I guess it's not wasted then. (sorry for the nick jumping) <OriansJ>well, perhaps it is best thought of the lessons you least want to learn are the ones you spend the most time and pain learning <OriansJ>hmmm, I might have cracked it (nested lambda forward references) <OriansJ>It is a little messy but it passes the previously pasted test <OriansJ>I guess it is finally time for me to add assq, assv and assoc to mes-m2's scheme primitives <OriansJ>It isn't an ideal solution (because I haven't figured one out yet) but it doesn't break any of the tests and is still lexically scoped (except when it punts looking for a variable outside of the lexical scope) <OriansJ>I need input on scheme validity of the following s-expression: ((lambda a (cons a a)) 4 5 6 7) <OriansJ>as I thought the only valid lambda expressions are (define (foo a) (cons a a)) and (define foo (lambda (a) (cons a a))) <OriansJ>well yes, guile does kinda do that in a weird way <OriansJ>but it just doesn't appear valid in r7rs as far as I can tell <dddddd>MIT/GNU Scheme, chicken and racket versions I have around are fine with that s-expression too. <OriansJ>and mes.scm also appears to use it as well <dddddd>No idea about standarization, sorry. <dddddd>r7rs 4.1.4. Procedures has 3 options for formals. I'd say that's the second one. <OriansJ>that is the least schemey of the set ***hannes_ is now known as hannes
<dddddd>M1.scm now knows about one of the KNIGHT special cases (@ is just another char; it has no special meaning, unlike other archs). Let's see what's going on in "hexify string". <OriansJ>well in M1 for KNIGHT !@$%& are just passed as is because they are just displacements <OriansJ>hence why '00 00 00 01' instead of %1 is used in M2-Planet <OriansJ>in cc_core.c:444 (primary_expr_number) <dddddd>True, I didn't explain well. No prefix is special (@ is just a default of the implementation). <OriansJ>as KNIGHT only supports 16bit immediates <OriansJ>(I could fix that in the base architecture if there was a real need but I haven't yet found a good reason for it yet) <OriansJ>mostly because then I'd probably have to support LOADUI8 R0 !1; LOADI32 R0 %1 and LOADUI256 R14 ?1 and end up having to redo M0 for knight <dddddd>Thanks for the context, always helpful. <OriansJ>as there are primitives in the original knight what I didn't include in the VM, simply because I wanted to simplify the implementation (like the pack and unpack instructions) <OriansJ>There was one that I was tempted to include but wasn't sure if it was worth the effort CMPSET.? R0 R1 R2 IMMEDIATE <OriansJ>Which would have compared R1 and R2 (if .E if equal, .NE if not equal, etc) and if the condition was true set R0 to the signed value of the immediate <OriansJ>basically x86's SET? instructions on steroids <OriansJ>changing line 1880 of Ur-scheme from (lambda cmd (cond to (lambda (cmd) (cond gets mes-m2 all the way to the assert-equal statements <OriansJ>So less than 400 lines left to get working <OriansJ>now just to figure out what is causing the ERROR: not equal (#f #\\f) <OriansJ>minor correction to the previous (lambda cmd (... It is (lambda (. cmd) (... <OriansJ>which fixes the previous error message <OriansJ>and mes-m2 now gets all the way to: = received non-integer <OriansJ>which doesn't make any sense; as that uses equal? and mes-m2's equal? doesn't leverage = at all <fossy>OriansJ: there is so much for you to show for 4 years of work <fossy>stage0 mescc tools seed mes m2 m2 planet <fossy>you've made the first modern c compiler in assembly, designed and programmed pretty much all of the lower stages of the bootstrap, the hardest part of it all IMHO <OriansJ>I just can't get 2KLOC scheme programs to run <OriansJ>as debugging interpreters is so much harder than compilers <fossy>Of course they are, thats unfortunately the nature of them <OriansJ>I've started to wonder why scheme interpreters are such a mess regardless what language they are written in <OriansJ>I mean literally a proper scheme parser in haskell takes 5 pages of code <OriansJ>and I am trying to shove it into 250 lines for a reader and 330lines for a tokenizer in a primitive subset of C here; <fossy>OriansJ: last night when you said 20:25 <OriansJ> also you know you can create a custom struct for the storage of shell variables right? | you can't pass the actual struct to execve as argv right, you need a function that simply converts it to a char**, correct? <bauen1>what's this about a c compiler written in assembly ? (i want a link ;) ) <OriansJ>fossy: well execve only accepts const char *, const char * [], const char *[] and struct pt_regs <OriansJ>bauen1: I wrote like 4 of them in a speed run a couple weeks ago <OriansJ>bauen1: and they all can be bootstrapped from nothing (357bytes to be precise) <bauen1>what kind of c can they compiler ? <bauen1>as far as i read about this project stage0 eventually compiles tinycc = <fossy>bauen1: a very small subset of C. <OriansJ>oh by the way, it is a cross-platform C compiler <fossy>cc_* family -> M2-Planet (written in the cc_* subset, cross-platform) -> Mes-M2 (WIP -- a scheme interpreter) -> MesCC (C compiler in Scheme) -> TinyCC <fossy>From there to the GNU triplet of GCC, Glibc and Binutils <bauen1>i'll have to keep an eye on this <OriansJ>everything above mes-m2 (minus slow-utils) is done <OriansJ>and everything below mes-m2 is also done <bauen1>i'm currently writing a unix-clone kernel with the goal of having self-hosting (in a few years lol) with only sh, make and tinycc <bauen1>so maybe i'll eventually bootstrap that from "nothing" <fossy>OriansJ: as kaem grows it will obviously need to be splitted into multiple files to keep it readable; hence, opinions on moving it back to a seperate repository? <OriansJ>would you be interested in collaboration? <bauen1>fossy: i'm still at the stage of virtual file system without any userspace done <fossy>OriansJ: do you have an opinion either way? <bauen1>the previous version did have a userspace and could run tinycc so i'll get there eventually <fossy>bauen1: do you have a link as of yet? <fossy>we don't currently have a solution to the kernel bootstrap problem <bauen1>no userspace as in: no multitasking / process support and no elf loading <fossy>atm everything runs on top of a 70MB+ linux blob <OriansJ>we just need a POSIX good enough to run a single script <fossy>bauen1: is this code anywhere yet? <fossy>oops, i already asked that sorry <bauen1>OriansJ: a list of the syscalls you would require would be nice \o/ <bauen1>the staging branch of rewrite nr. 3 has x86_64 and i686 support along with the first vfs parts (currently only local) <OriansJ>bauen1: read, write, open, close, fork, execve, brk and the rest we could remove the need for to a degree <bauen1>myunix version 2 is a real mess in terms of code-style and everything else <bauen1>(the reason staging is mostly local atm is that i push every commit seperately and wait for ci so every commit at the very least compiles but gitlab-ci normally only runs on HEAD) <bauen1>yes, that version is good enough to run tinycc <bauen1>but it has too many bugs and code-quality issues (and a few design issues) <bauen1>so i hope to achive feature-parity with the rewrite in a few months <OriansJ>bauen1: with a handful of minor restrictions, you might be buildable via M2-Planet <OriansJ>which we are planning to bootstrap from bare metal <OriansJ>which would enable us to collectively solve the posix bootstrap problem too <bauen1>keep in mind that i worked on that when i was 15 and it's mostly copy-pasta and "educated guesswork" <bauen1>fossy: which restrictions on __attribute__ ? <bauen1>i only really need __attribute__((packed)) but if the compiler doesn't attempt to optimise it could be ignored <fossy>bauen1: m2 planet does not have __attribute__ <fossy>the compiler does not do any optimizations pretty much <OriansJ>So the binary will be very unoptimized but bootstrappable <OriansJ>we also would be willing to help the transistion if you are open to it bauen1 ***janneke_ is now known as janneke
<bauen1>sure, let me get it self-hosting first <OriansJ>(we also don't need anything fancy with the file system fat32 or ext2 is fine) <bauen1>i'm happy if if my tar read-only filesystem driver works, filesystems are a mess :/ <OriansJ>bauen1: I am more than happy to help <bauen1>technically you could also get around that by taring up and just writing the tar file to a block device ... <theruran>janneke: I've got a single XFAIL on 'make check' of gash and a FAIL on 'make check-spec' too. (latest master clone.) is that expected? <janneke>theruran: one XFAIL is expected (eXpected Failures are always expected :-) <theruran>FAIL: oil/spec/loop.test.sh - I can share the log if you're interested <janneke>theruran: i haven't really worked on gash for some months, being focussed on gash-utils; i get two failures even -- but a mail to gash-devel@nongnu.org is always appreciated <theruran>janneke: OK - I will look at it further then. thanks! <janneke>theruran: thank you for reaching out!