IRC channel logs
2024-01-08.log
back to list of logs
<stikonas>rickmasters: hi, can I ask what happens to symlinks in live-bootstrap repo when read by builder-hex0? <Googulator>stikonas: IIRC generator.py isn't aware of symlinks, so it will just store them as copies in srcfs <stikonas>I think it's just patches that are symlinked in srcfs <plasma41>Googulator: What was the recent Haskell discussion about? <Googulator>basically, a potential new bootstrap path using hbc <Googulator>If we can transpile hbc's LazyML sources into Haskell code compatible with Yale Haskell 2.05, that could give us a usable (if interpreted) version of lmlc to properly compile hbc <Googulator>And then, hopefully we can fix up the recently rediscovered GHC 0.26 enough so it compiles with hbc <Googulator>(the last version of GHC to support compilation with hbc was 0.24, which is lost) <Googulator>Once we have that, it should be possible to traverse the development history of GHC from 0.26 to the present day, thanks to the same archive repo that had 0.26 <stikonas>all that old stuff is likely not to build on modern systems <Googulator>LazyML appears to be a much simpler language than Haskell (e.g. no massive Prelude), with the same paradigm as Haskell (lazily evaluated, purely functional, algebraic type system), so the ideal transpilation target for Lazy ML is Haskell <Googulator>and we already have a working, if really old/basic Haskell implementation almost-bootstrapped (Yale Haskell, on top of clisp) <Googulator>clisp itself isn't bootstrapped in LB, but it probably is in Guix <Googulator>(it's not even really bootstrapping, as clisp isn't self-hosted, it's written in C) <stikonas>in the meantime I'm close to remong weak symbols hack from live-bootstrap (issue #322) <oriansj>muurkha: well yes; if one is limited to assembly and assembly programs, it is quite easy to function in 4KB but if you want to support building gcc via a large storage drive and only the minimal RAM, the lower bound would be 16KB <oriansj>and it'll take a considerable amount of time <oriansj>the more RAM the less loading pages from memory and faster the result would be. <plasma41>Googulator: Exciting stuff! Very cool :-) <rickmasters>stikonas: sorry, stepped away. Links not supported in builder-hex0 <Googulator>The 2 key developments since the failed attempt to bootstrap ghc 0.29 using nhc98 are rekado's port of Yale Haskell to clisp, and the discovery of a Git repo of ghc's history going back to 0.26 (originally converted from darcs, but with history preserved) <stikonas>rickmasters: I've left one comment on your PR regarding link <stikonas>wouldn't change much, but all other patches in that directory are symlinks <Googulator>Unfortunately the conversion from CVS to darcs was performed without history, and the CVS repo itself is lost, so we don't have pre-0.26 history <Googulator>which is a shame because 0.26 is the first version of GHC not to be cleanly buildable using HBC <stikonas>no checksums would be affected by this... <Googulator>an important sidenote is that the version of HBC that was supported for compiling pre-0.26 GHC is (of course) also lost <stikonas>i.e. do we expect signigicant changes since the last version that was compatible with HBC... <stikonas>somehow haskell people did not care about history :( <Googulator>the newer HBC has 2 Haskell frontends, a deprecated one for Haskell 1.2, and a newer one with 1.3 and partial 1.4 support <Googulator>the deprecated 1.2 frontend might be good enough for compiling 0.24, if we ever find it <Googulator>or 0.26 if we patch out whatever makes it incompatible <Googulator>Before GHC 2.0, GHC was strictly a Haskell 1.2 compiler, meant to be compiled with itself, hence the codebase is also 1.2 <Googulator>2.0 introduced Haskell 1.3 support (breaking 1.2 compatibility), initially requiring it to be compiled with 0.x (there never was a GHC 1.x) <Googulator>Then at some point between 2.0 and today, the codebase was refactored to be Haskell 1.3 (again, probably using GHC extensions) <Googulator>GHC's intended solution for bootstrapping (well, "bootstrapping") was via generated, separately distributed ".hc" files - which are (it feels like I'm repeating myself at this point) *lost* <Googulator>".hc" files were intermediate C code emitted by older versions of GHC <stikonas>well, similar story to stuff that happens today... e.g. zig... <Googulator>GHC used to transpile to C, then compile that C code using the system C compiler <Googulator>nowadays, it compiles to GCC or LLVM IR instead, and calls the relevant compiler backend directly <Googulator>I guess Haskell folks back then didn't consider source-based bootstrapping important (again, Zig comes to mind with their new "oh, just use wasm" approach) <stikonas>at least zig folks haven't lost the history yet... <Googulator>reading Yale Haskell's documentation, this gem stands out: <Googulator>"Compiling the Yale Haskell system from the source distribution takes a few hours, and requires a substantial amount of virtual memory, particularly for processing the standard prelude. We recommend that you have at least 50 megabytes (and preferably more) of swap space available to do this." <Googulator>(and this was, of course, meant to be done on mainframes or at least minicomputers) <Googulator>On a modern AMD system - assuming it did indeed build everything it was supposed to -, the build took about a minute. <stikonas>well, resources is something we can be far more wasteful in modern bootstrapping <Googulator>Seems like we've come a long way since Yale Haskell was developed... <nimaje>I assume that faster hdds/ssds have also a play in that <Googulator>you were expected to compile this on a SPARC running SunOS, with Macintosh support "planned" <Googulator>also, the language it's written in is Common Lisp, which back in the day was notoriously difficult to implement in a performant way on regular hardware, leading to the birth of dedicated Lisp machines <Googulator>I guess all the optimizations that today's CPUs have (which gave us Spectre...) help with efficiently executing Lisp <Googulator>(isn't the "knight" architecture also based on a Lisp machine?) <oriansj>Googulator: knight architecture predates lisp machines <oriansj>if I was to be 100% compatible, I would have to do symmetric compliment rather than twos <oriansj>(think -0 == NaN) and several integer operations could result in NaN values being put in registers and there were jump and skip instructions if the value in the register was NaN <Googulator>I wasn't aware Tom Knight designed any other ISA before CONS <Googulator>rickmasters: builds completed successfully on both of my bare metal test systems <Googulator>pder: are you still seeing the Fiwix memory map issue with the new 1.5.0-lb1? <fossy>Googulator: i have done a bit of bare metal testing but will be doing more when all your PRs are merged... i'm on the move a bit though, so it can be difficult for me to have a reasonable feedback cycle <fossy>Piraty: hm? no, i think it's just text form being text. legitimately do not use abi-dumper in live-bootstrap at all <fossy>okey lets get some of these PRs merged <Googulator>fossy: Pushed a few more fixes, including a new PR to fix a bug in one that got merged <matrix_bridge><Andrius Štikonas> Googulator: I don't think it'd named after tom knight. It is after some company called knight <Googulator>In autogen-5.18.16, are we supposed to have "SKIP_MAIN=1 . ./bootstrap_tarball.sh" (note . before ./)? <matrix_bridge><Jeremiah Orians> Googulator: no it had nothing to do with Tom knight, it had more to do with chess. As their operating system was called bishop and their high level languages was called rook. <muurkha>GoogulatorMobile: I think "notoriously difficult to implement in a performant way on regular hardware" is a bit of an overstatement <muurkha>at the time designing hardware to support a particular language seemed like a reasonable thing to do <muurkha>for numerical code in the 70s MACLISP was already comparable to Fortran (though Fortran has advanced since then) <muurkha>one of the biggest problems for Lisp efficiency was garbage collection; generational GC wasn't invented until the early 01980s, and that was the crucial invention that made GC performance-competitive with malloc/free memory management <muurkha>it seems likely that "50 megabytes of swap space" was a workstation rather than a minicomputer or a mainframe. though surely there were minicomputers that had that much <muurkha>GoogulatorMobile: the git repo of ghc 0.26 is very exciting news! <muurkha>oriansj: I wasn't talking about just assembly and assembly programs; you can also do BASIC or Forth in 4K. building gcc in 16K would be quite a feat but you are probably right that it is possible <muurkha>that's getting pretty far into the Turing tarpit, though, because that's going to be spending orders of magnitude more time paging than computing, even if you use VAX-style 512-byte pages <muurkha>hmm, though I guess that does have 16KiB of RAM <muurkha>oh, and also an ATMega644a, which only has 4KiB <muurkha>this is using a DIMM as a "large storage drive" since the AVR doesn't have the capability to use external RAM as RAM