<oriansj>janneke: have you taken a look at the current state of mes-m2 yet? <janneke>oriansj: no, i haven't -- you made good progress? *janneke has been enjoying holidays and will have do that some days more <oriansj>janneke: well I got it to a much nicer state, virtually all of the primitives match guile's behavior exactly <oriansj>The only remaining major piece is support for guile's module system and then everything becomes a slow incremental march until until we are able to solve the guix and guile bootstraps *janneke sometimes feels a bit sad that because of the forking we are doing some duplicate work... <janneke>oriansj: i suspect you don't want to use guile-1.8's boot-9 module implementation? <janneke>i have been playing with porting that to my wip-module branch <oriansj>janneke: well I honestly haven't figured out the best way to implement module support that would work long term <oriansj>Because if I could limit it to a handful of well designed primitives and did the rest in scheme functions and macros, it would be much nicer <janneke>oriansj: on wip-module, i copied the guile hash-table and low-level record and module functionality and then run guile-1.8's boot-9.scm <janneke>otoh, we need the most thorough review we can imagine, and you/we are doing an amazing job there :-) <oriansj>janneke: have you looked at mes-m2's mes_record.c? <oriansj>which are all of the record primitives that guile exposes by default <oriansj>I designed it to be trivial to understand and easy to inspect/use <janneke>oh, you did it all in C..interesting. <oriansj>janneke: it also makes it more introspectable when debugging <oriansj>I did something similar with Macros, so that we literally have a single point of pre macro expand and post macro expand to know if are macros are doing what we expect of them <janneke>having m2-planet, the need for a true minimalistic C core is no more <oriansj>janneke: exactly, we have the freedom to not worry about lines of code but how understandable our code is <oriansj>and the path for mes-m2 is to become a drop in replacement for guile; <janneke>that could be a reason to do certain things in scheme; and that's a much better reason than "we need the core to not change and be minimal, because we need to hand-code it in assembly" <oriansj>so guix can be reduced down to just guile for now and when mes-m2 is done; we filp the switch once and boom everything is done <janneke>having these well-defined interfaces always gives us the freedom to move things from C to Scheme and vise versa <oriansj>It also allows all future guix hardware bootstraps have to deal with is the stage0 steps <janneke>yes, civudul's initrd experiments help define what we need from guix to do a build <oriansj>janneke: actually I have something even better than initrd in the pipe <oriansj>building a posix from bare metal using cc_x86 <janneke>i think hannes will like that; sounds uni-kernel'ish <janneke>re initrd; i was referring to defining the guile compatibility target for mes <janneke>an initrd build is guile+(minimal guix).scm <janneke>we "just" need to => mes+(minimal guix).scm and we're done <oriansj>just keep marching down the path as usual. Find something blocking the road, break through it though sheer will <janneke>we may want to look at building on hurd, and try removing everything except the microkernel <janneke>the idea of cross-distro hash comparisons is very interesting <oriansj>janneke: well one will still need some posix compatibility in microkernels otherwise read/write become something much more complex <janneke>oriansj: yes, we need some open/read/write functionality but that could be real simple; we would not need a hurd filesystem daemon, e.g. even key-value store could work <oriansj>and I know you'll be excited by the fact that all M2-Planet builds are 100% deterministic (including cross-distro, cross-architecture and environment blind) <oriansj>and if I can do the same thing with mes-m2; well that makes for something very special ***ng0_ is now known as ng0
<oriansj>janneke: one thing we can do to speed up our scheme is to compile it and I was wdonering if you have seen Peter Norvig's compile1.lisp (a scheme compiler written in scheme) <janneke>oriansj: no, i haven't looked at compiling scheme or scheme compilers at all, really <janneke>i glanced at scheme48 three years ago and found it too unwieldy to really look <janneke>but it could be a good idea although at the moment speed is not an issue <janneke>when mescc matures it could become an issue :) <oriansj>well you know me, I am always thinking about how to start addressing problems long before we hit them. <oriansj>speaking of which, we really should take a serious look at building binutils directly from MesCC as a major priority in MesCC development <oriansj>(It will allow us to switch MesCC from producing M1-macro output to gas output and make the tooling for MesCC easier to maintain in the long run) <oriansj>and with the current expansion of mes-m2 into a drop-in replacement for guile, MesCC will be able to switch to guile by default and make MesCC a true competitor to GCC in the long run <janneke>hmm, and then we need to rewrite gas in scheme ;-) <bitmapper>was wondering if you've made any progress on it since then <bitmapper>i'm interested in this for two very different reasons, to be honest <bitmapper>number one being that hugs has been ported to plan 9 <oriansj>janneke: or just let the binutils team deal with it and just use a fixed tree in MesCC that depends upon mescc-tools for the bootstrap of that piece and save us some trouble until we get a couple of schemers willing to do that work <oriansj>dddddd: well the answer to trustable hardware is based on how the process for lithography is done. Aka in the end you either need to make it out of TTL (or individual transistors) or trust the party making your chips. <oriansj>Now anything that we can do to make detecting underhanded things in the lithography process cheaper and make the financial penalty to the organization who does that work higher for violation; the lower the risk <oriansj>(aka you don't risk $1M when the other side only needs to spend $1 to catch you) <oriansj>aka be willing to pay $1 for a $0.01 part; if the manufactor is willing to risk $1M in penalities per chip if compromised. <oriansj>Heck be willing to spend $20 for a $0.01 part if the manufactor is willing to risk $10M in penalities per chip if compromised and that business will spend $5 per chip to ensure security. <xentrac>perhaps we can inspect the chips with a ptychographic microscope <xentrac>but constructing them myself sounds cheaper <oriansj>xentrac: well there is no way that you can know for certain if the backdoor is only in 1 in 100,000 chips <oriansj>also TTL computers are freaking expensive <xentrac>perhaps we can compile on 100,000 chips and use the majority-rule compilation result <xentrac>nah, there are TTL computers you can build for under US$100 <bitmapper>i know of someone working on EBL for chipfab <oriansj>Or do a compilation and then decap after you get the result <oriansj>Monster 6502 ended up costing $10K to build if I remember correctly <xentrac>the MOnSter 6502 would cost thousands of dollars if someone were buying it <xentrac>but it's not using TTL and it's not using any chips <xentrac>and things like the 74181 are worth quite a lot of discrete transistors <oriansj>well we would want to limit ourselves to only chips that are readily available all over the world and are trivial for any garage fab to make <xentrac>right now I don't think there are any chips that are trivial for any garage fab to make <oriansj>But then again I view this as a process problem <xentrac>but hopefully we can improve that situation <oriansj>right now we have garage fabs able to make nands and nors and simple SRAM <xentrac>whose last name mysteriously is "fools" backwards, so I'd like to see replication of his results <oriansj>but trivial in the anyone willing to do the work can get the results sort of trivial <xentrac>I mean I think he's probably for real but we're a long way from "anyone willing to do the work can get the results" <oriansj>well we are just at the beginning of doing this work <oriansj>3 years ago, people were telling me it was impossible to bootstrap a C compiler from assembly <xentrac>as we found out, one of the most popular CP/M C compilers was written in assembly <xentrac>and 8080 assembly at that, not a comfortable assembly like 386 or Knight <xentrac>people just get way too intimidated by things <oriansj>xentrac: those people just were not assembly programmers <xentrac>speaking of which, I need to get back to hacking on PDf generation for Dercuano <oriansj>otherwise they were actually really good programmers <xentrac>I hacked together a font cascade mechanism to get rid of the tofu but I still need to integrate it into the HTML rendering engine I wrote the other night <oriansj>So I expect we will be hitting lots of problems when doing the hardware bootstrap <oriansj>I even have a plan to rewrite hex0, hex1, hex2 and M0 for knight if I end up needing to change the instruction encoding to simplify the implementation <oriansj>So, I expect failures and cheating and abuse but in the end, no one should have to trust me nor anyone else <oriansj>It is why anything in my code that isn't obvious is a bug that needs to be fixed