IRC channel logs
2024-01-07.log
back to list of logs
<stikonas>rickmasters: do we still need that lb1 in fiwix version? <rickmasters>stikonas: yes, it signifies an interim release to support live-bootstrap <rickmasters>stikonas: if Mikaku wants to call it 1.5.1 instead that's fine with me but that might take more time / formality. <rickmasters>stikonas: by using -lb1 it just signifies a source snapshot that live-bootstrap is free to use prior to the next formal release. <stikonas>CI is still running, so let's wait with merging... <stikonas>and possibly Googulator might want to try baremetal run... <rickmasters>stikonas: yeah there are a lot of outstanding PRs which means there will probably be conflicts to resolve. <stikonas>I didn't do much today though but I merged posix-runner into stage0-uefi main branch and also made it build at the end of stage0-posix <stikonas>yeah, we have quite a few open issues and PRs now <rickmasters>stikonas: I'm assuming I may have to rebase my PR but that's ok. I just decided to put it out there rather than wait indefinitely... <rickmasters>stikonas: maybe. I'd like to help Googulator rather than make it more difficult. I think that's where my focus will go next. <stikonas>yeah, Googulator is making a lot of improvements too <stikonas>I do have some changes I want to make to live-bootstrap, but will probably wait a bit due to being busy... <stikonas>need to improve uefi bootstrap a bit. And there is also an unfinished riscv64 posix bootstrap... <Googulator>Thanks for the heads up about the Fiwix PR; will do a bare metal test of that on my boards soon. <Googulator>BTW, am I the only one at this point doing testing on bare metal? <stikonas>Googulator: for now I think you are the only one <stikonas>I only have 2 machines and the one that has BIOS compatibility mode is production right now... <Googulator>I was also looking at the Haskell bootstrap situation - the recently found GHC 0.26 source code mentions that it was previously built using Chalmers HBC, but as of 0.26, that's no longer supported. Still, IMO HBC has the best chance of working - if we can get it compiled at all, that is. <Googulator>I did get Yale Haskell to run using clisp (on my regular system, not in a bootstrapped environment, but AFAIK clisp is written in C, and shouldn't be too hard to bootstrap) <Googulator>The issue with HBC, of course, is that it's written in LazyML, a language that's pretty much extinct <Googulator>& the only LazyML compiler that ever existed is the one that eventually got extended to support Haskell, becoming HBC. <Googulator>But I was thinking: LazyML is one of the earliest lazy functional languages, and one of the inspirations for Haskell itself. <Googulator>...Maybe we can write a simple transpiler to read LazyML and output Yale-compatible Haskell? <Googulator>HBC's LazyML parser frontend is written in C (using lex & yacc; it's easily fixed to be Bison-compatible), and it probably shouldn't be hard to wire it up to a simple Haskell code generation backend <Googulator>so the plan is: fix up the LazyML parser to build with modern Bison (done), write a Haskell generator backend in a language we already have bootstrapped, use that to transpile HBC into Yale-compatible Haskell <Googulator>Then use the transpiled HBC running under Yale Haskell's interpreter to hopefully compile GHC 0.26 <Googulator>And then walk up the chain of GHC versions until we hit modern day <Googulator>Yale Haskell 2.05's docs state that one of the new features is "Monadic I/O", but I'm not quite sure if this is the same monad system Haskell has today <Googulator>(Yale Haskell 2.2 apparently existed, but releases newer than 2.05 appear to be lost.) <stikonas>I think he was the last one to look at haskell <oriansj>muurkha: well one needs enough RAM to run a kernel capable of handling memory paging and process management. (Assuming one has Memory mapped storage devices, otherwise additional functionality may be required in the kernel as well) <oriansj>and atleast 2 pages of memory for user space processes. <Googulator>stikonas: I haven't talked to him yet, but I'm using his fork of Yale <stikonas>well, I haven't looked much into haskell... Maybe it would indeed be easier to write some transpiler/compiler for some stuff rather than just rely on historic code <nimaje>hm, I throught I read here a while ago about some really limited subset of haskell, that can be used to compile a less limited subset, that can compile ghc, but that must have been months ago, so I could easily remember wrong <stikonas>at the very least there isn't complete chain <stikonas>you could compile haskell with an older haskell <stikonas>and then there are various options, like nh98, hugs, and those Googulator mentioned <Googulator>According to ghc's own documentation, the only thing besides itself that as ever used to compile it was hbc <Googulator>Even if the problems with getting nhc98 to produce usable binaries when interpreted by Hugs are solved, compiling ghc with nhc98 would amount to breaking new ground <stikonas>oh, that one is nowhere even close to building ghc <Googulator>Looking at hbc's source, it seems to be mostly good news: there are 2 separate parsers written in C/Yacc (one for Lazy ML, one for Haskell) which are apparently meant to produce a common representation <Googulator>& then that representation is fed to a common backend, which is itself written in Lazy ML <Googulator>All of this is tied together by a driver program, also written in C <Googulator>Is there a built-in way to turn a Yacc/Bison parser into a generator? <oriansj>nimaje: blynn was just explored as the question of would it be easier to write a scheme in hasekell to run mescc; using a haskell compiler bootstrapped from C. <stikonas>but mes-m2 that was buildable with M2-Planet materialized first <stikonas>first it was non-upstream fork but later janneke made upstream mes buildable by M2-Planet too <janneke>yeah, that was another effective 1-2 <janneke>oriansj initiated it and fixed all kinds of things in their fork that i backported and used <stikonas>I was just testing mes-m2/mescc on UEFI... <stikonas>it would probably run (it seems to be doing things...), but I think tehre are still some bugs in my implementation of fork/execve <stikonas>probably similar issues that I saw with kaem <stikonas>(after outputing correct M1 assembly for crt1.c) <stikonas>janneke: while you are here, how does mescc find M1? <janneke>so, you can also set environment variable M1 and that will take precedence <stikonas>argh, I was looking at the wrong mescc.scm first <stikonas>but it spit out a lot of DEFINE statements... <stikonas>and it actually created crt1.o with corrent sha256sum checksum <stikonas>just for some reason printed some unexptected arguments (8 instead of 0) in primitive-fork and got stuck <stikonas>I guess something is wrong with "command" variable in mescc.scm (and (zero? (apply assert-system* command)) <stikonas>hmm, perhaps I need to print some debug info in mescc... <janneke>there's only one primitive-fork, in posix.mes, afaics <stikonas>still, it's looking very promising so far <stikonas>but how did it even output correct crt1.o file... <janneke>that primitive-fork looks like it's caused by some sort of corruption <stikonas>more likely my fork implementation doesn't do something correctly when suspending/restoring process <muurkha>oriansj: CP/M and PDP-7 Unix were self-bootstrapping without memory paging or, in the case of CP/M, process management <muurkha>PDP-7 Unix had one user process in memory at a time, to which it allocated half of the 8192 18-bit words in the machine <muurkha>I don't know how much RAM CP/M needed to be able to successfully assemble and link itself. obviously it couldn't be more than 64KiB <muurkha>but I suspect it was much lower, more like 16KiB <muurkha>the reason I'm focusing so much on memory is that a 6502 is 3500 transistors, a PDP-8 is 4000, a Z80 or SeRV RISC-V is 8500, a MuP21 is 7500 <muurkha>but 4KiB of DRAM, the minimum you can really get by with for a high-level language, is 32768 transistors <muurkha>so for the first 30 years of computers they didn't build RAM out of transistors but out of something cheaper: mercury delay lines, wire torsion delay lines, Williams tubes (1024 bits in one vacuum tube), magnetic drums, and finally magnetic cores <muurkha>4KiB is what Apple Integer BASIC and Altair BASIC needed, and you can do an ITC Forth with a text interpreter in that space too 