IRC channel logs

2022-04-05.log

back to list of logs

<littlebobeep>stikonas: thanks for the SVG, but how did you get guix graph to recognize all the stage0 stuff when those are not in guix?
<stikonas>littlebobeep: that graph has nothing to do with guix
<stikonas> https://github.com/oriansj/talk-notes/blob/master/live-bootstrap.dot
<stikonas>it's manually created
<stikonas>and hence the further we get to in live-bootstrap, the less accurate dependencies are
<stikonas>(too many arrows and we don't really know all of them anyway)
<littlebobeep>muurkha: what is ς-calculus never heard of that
<muurkha>Abadi and Cardelli's object calculus
<muurkha>it's very nearly as simple as the λ-calculus but has a couple of advantages
<muurkha>one is that it works much better than the various typed λ calculi for static typing of object-oriented languages, which is what Abadi and Cardelli designed it for, but which I care very little about
<muurkha>the other is that it's enormously easier to read and write programs in, which I do care about
***genr8eofl_ is now known as genr8eofl
<littlebobeep>stikonas[m]: You said risc-v ASM can only handle 31 bit numbers, this is also true on RISCV64-bit?
<littlebobeep>stikonas[m]: Why do you say we do not know all the arrows in dep graph?
<oriansj>unmatched-paren: the answer to the question "what is M2-Moon" is a scheme compiler written in Assembly
<littlebobeep>muurkha: Abadi, Martin; Cardelli, Luca (9 August 1996). A Theory of Objects
<oriansj>it was dropped when janneke and I started working together to get Mes.c buildable by M2-Planet
<oriansj>ultimately it would have been 10x bigger than cc_* and would have been a nightmare to debug.
<littlebobeep>muurkha: http://library.lol/main/2A40A401B831E4416029EA8535AA0E9A
<oriansj>turns out the assumed core of lisp actually is much more than originally presented.
<littlebobeep>oriansj: So going directly from ASM to LISP is not good, it is easier to go to C first then LISP?
<oriansj>littlebobeep: well to put it in simple terms. a toy lisp in assembly like you can find in stage0 that weights in only 10,320bytes took about a month to write. cc_x86 weighing in at 16,386bytes was done in less than 24 hours
<littlebobeep>Hmm I don't understand why cc_x86 takes so much less time given it is more LOC
<oriansj>1) the only tricky part in cc_x86 is the reader functions and we can write a trivial debug function allowing one to get it sorted in an hour
<oriansj>2) Compilers have less runtime failure modes than interpreters
<oriansj>3) debugging garbage collection in assembly
<oriansj>4) seriously 3 just eats time
<oriansj>5) 90% of cc_* is just calling match and in_set and branching to the next bit while just building a list of strings
<littlebobeep>okay interesting I have not studied cc_x86 source yet
<oriansj>it is rather simple: take a file and generate a list of tokens. Then walk that list in a state machine and appending to a string list until you read the end of the tokens. Then just the list to the output file and you are done
<oriansj>for those not familiar with assembly, there is a C code version which is rather simple to parse
<littlebobeep>okay but the C version is not used for bootstrapping, right?
<oriansj>littlebobeep: it isn't needed
<oriansj>it is just there for educational purposes
<oriansj>and not used, except by developers needing more insight in to how cc_* works
<littlebobeep>okay great thank you... then I still feel the need to look at the ASM code if I depend on that to bootstrap I guess
<littlebobeep>oriansj: How did you create this .dot file: https://github.com/oriansj/talk-notes/blob/master/live-bootstrap.dot
<littlebobeep>I am familiar with guix graph which calls graphviz but I don't know how to make such an image without that command
<oriansj>littlebobeep: I wrote it by hand
<oriansj>the build to pdf process is just: cat Current\ bootstrap\ map.dot | dot -Tpdf > foo.pdf
<littlebobeep>wow okay... how do you track all those dependencies >_<
<littlebobeep>stikonas[m] mentioned that it was incomplete
<oriansj>littlebobeep: well you just read the kaem scripts
<oriansj>it takes time and is done manually so it inevitably falls behind as fossy and stikonas are doing real work and I just haven't updated to reflect where they are now
<muurkha>littlebobeep: yes, that's the book. I wish I had an open-source source to point at
<littlebobeep>muurkha: What you mean "open-source source", are you saying because the book is copyrighted?
<muurkha>littlebobeep: RISC-V assembly can handle 32-bit and 64-bit numbers, it's just the `li` pseudo-instruction that expands to `lui ...; addi ...` that can't quite handle the full 32-bit space
<muurkha>I wrote a toy something-like-a-Lisp in September, with a 1-kilobyte executable: http://canonical.org/~kragen/sw/dev3/qfitzah.s
<muurkha>test program in http://canonical.org/~kragen/sw/dev3/example.qf1
<muurkha>yeah, the book is not free for me to share with you
<muurkha>I probably spent a week or two on it
<muurkha>but oriansj was only able to write a C compiler in 24 hours because he's about a 100× better programmer than I am, most people couldn't do it in a month I think
<muurkha>Qfitzah is not really a Lisp in the sense of being based on car, cdr, cons, eq, cond, null, and function calling, although it does use S-expression syntax
<muurkha>but my thought was that it might be possible to get higher-order programming and parametric polymorphism like Lisp, but also pattern matching, ad-hoc polymorphism with dynamic method dispatch, and even multiple dispatch, in a language that was *simpler* than the Ur-Lisp
<muurkha>and that might be a nicer language to write compilers in than C or Lisp (or, especially, Forth)
<muurkha>I might finish it at some point, we'll see
<littlebobeep>muurkha: It's okay i downloaded it from libgen :P
<muurkha>the language interpreter I wrote based on the ς-calculus is http://canonical.org/~kragen/sw/bicicleta/
<muurkha>the example session in http://canonical.org/~kragen/sw/bicicleta/README may be illuminating
<muurkha>or the example program in http://canonical.org/~kragen/sw/bicicleta/freezer.bicicleta
<fossy>stikonas[m]: i believe the 2>&1 in the tar one silences the command not found warnings from grep, and wrapping that in a command -v grep detracts from clarity throughout the rest of the block so i don't think that
<fossy>'s worth it
<fossy>i have now wrapped the first one in a command -v grep for clarity instead of 2>&1 now howerver
<fossy>let me just check that silences all the errors however
<fossy>i am having trouble reasoning that error 13... not a big deal though
<unmatched-paren>if i wanted to change a number in memory on RISC-V, e.g. add one to it (`*thing += 1`) would I need to load it into a register first?
<unmatched-paren>sorry, wrong question...
<unmatched-paren>if i have `foo
<unmatched-paren>..aargh enter key |:
<unmatched-paren>SO if I have `foo = &something`, how would I modify `foo` to point to `(&something) + 1`? in C i'd do simply `foo += 1` and the pointer arithmetic would be worked out automatically.
<unmatched-paren>the thing that `foo` points to is a string, btw.
<unmatched-paren>(I'm trying to iterate over nul-terminated strings)
<fossy>are you doing this in assembly?
<unmatched-paren>yeah, RISC-V assembly
<unmatched-paren>i was told yesterday that it was a better choice for starting out than x64, since it's so much smaller
<unmatched-paren>(riscv64, of course)
<unmatched-paren>actually, i should probably be keeping track of an `i` instead of adding to the string pointer...
<fossy>not familiar with riscv assembly, sorry
<unmatched-paren>aand... my riscv hello world program works!
<unmatched-paren>:D
<muurkha>yay! congratulations!
<unmatched-paren>muurkha: what should i try to do next?
<unmatched-paren>maybe replicate some basic libc functions?
<stikonas>unmatched-paren: we indeed replicate some basic libc functions in stage0-posix
<stikonas>e.g. https://github.com/oriansj/stage0-posix-riscv64/blob/master/cc_riscv64.M1#L611 and https://github.com/oriansj/stage0-posix-riscv64/blob/master/cc_riscv64.M1#L636 are useful for printing stuff
<stikonas>that's why going over stage0-posix can help to learn assembly
<stikonas>early programs are small but by the time you understand cc_* you would be quite good at assembly
***madage is now known as ichichjunk
<Hagfish>heh, i feel like a self-taught software engineering degree could consist of just: nand2tetris, live-bootstrap, and linux-from-scratch
<Hagfish>(i'd also feel better about humanity's long term chances if all of those were required modules for every computer science student at university)
***jackhill is now known as KM4MBG
***KM4MBG is now known as jackhill
***ichichjunk is now known as madage
***madage is now known as pussyriot