IRC channel logs
2023-05-21.log
back to list of logs
<oriansj>out of curiousity, has anyone looked deeply into the SBCL bootstrap? to rule out generated files; like we did with Guile (which we found generated files) <Irvise_>Afaik, CLisp is used as the common bootstrap CL for SBCL. <Irvise_>But that says nothing about pregenerated files. <stikonas>and I've merged rickmasters kernel bootstrap PR <fossy>thanks for handling that last bit stikonas :) <stikonas[m]>fossy: well I was just doing some final reviewing and testing, it's rickmasters who was doing coding. Big thanks to him! <janneke>ACTION finally has a riscv64 guix environment, partially qemu-built <janneke>[exa]: yeah, just in time to look at stikonas' work <stikonas>janneke: I've pushed some more fixes to that branch <stikonas>we still have crashes on building some files <stikonas>janneke: are you running full emulation? <stikonas>I'm just doing userspace emulation which is not bad <stikonas>(i.e. not runnign the whole system with the kernel) <janneke>stikonas: right, not a VM, i don't have any hardware either <stikonas>so at the moment I think mes-m2 crashes for me when I build fread.c <janneke>though it seems that qemu on my laptop is at least an order of magnitude faster than a riscv box <stikonas>riscv hardware is probably not too fast... <janneke>ACTION starts to understand the one million riscv processor project <stikonas>though qemu-aarch64 on my laptop is slower than my aarch64 rockpro64... <janneke>yeah, we should give riscv some time <oriansj>well architecture is not a magic bullet. An ugly architecture with lots of great engineers working on it will be blazing fast but a beautiful architecture with only a single average engineer will always be dog slow. <stikonas>I don't think risc-v is inherently slower, it probably just needs more time till more powerful CPUs are built... <janneke>ACTION believes that an open architectecture will always win, in the end <stikonas>well, risc-v is open ISA, the hardware itself is not always open <janneke>people keep investing time in dead-ended efforts <janneke>there seems to be no cure for that yet <oriansj>stikonas: I don't think it is time so much as excellent engineering effort <stikonas>yes, but I think amount of risc-v engineering is going up <oriansj>unfortunately hardware has a property that is very different from software. Experiments are expensive <oriansj>software has the advantage of making failure cheap <stikonas>there are ways to do some experiments with hardware but even those are not cheap... <stikonas>you can emulate hardware on CPUs and or FPGA <stikonas>probably. But for big companies that's pocket change <stikonas>still, it's more expensive than experimenting with software <oriansj>well yeah, spending a $1B to design a chip that costs $0.01 to make and is sold for $1000 <janneke>i concur that hardware is prolly much more difficult than software <oriansj>fortunately bootstrapping has considerably lower performance requirements and something with Core2Duo speed is good enough for a RYF laptop (x200) <janneke>but anything you create that's not open may have helped you accumulate wealth, but contribute nothing <stikonas>janneke: do you know if laanw ever got mescc to build mes? <oriansj>Look, if I could design hardware and sell it at cost and still live a modest life. I would do that in a heartbeat. <janneke>stikonas, no idea, they never answered any of my mails <janneke>and their contribution came out of nowhere, truly amazing <stikonas>I did talk to laanwj on this channel at some point <stikonas>pointing out those risc-v changes in mescc-tools <stikonas>laanwj was not aware of them before and agreed that previous way is way too complicated <stikonas>anyway, it's still a very good starting point <stikonas>I was able to get quite a few test cases working <stikonas>including scaffold/read.c which dragged in half of mes C library... <janneke>it was amazing, and their patches came at a very awkward time and were stuck in limbo for about two years, which is very bad <stikonas>but it was also started from mes and not from stage0-posix <janneke>i was halfway (quarterway) into M2-Planet support... <stikonas>so it was a bit awkward on mescc-tools side too <oriansj>I wonder if there is a path into RYF chip design via the limited supply Retro computing chip problem. (VIC and SID chips pops first to mind) <oriansj>immibis: correct, the first steps into giving people control of their computing from the direction of hardware. It definitely does not go far enough but it contains some good <stikonas>janneke: so I was looking at what causes crash in compiling lib/stdio/fread.c <stikonas>if I reduce buffer size in static char debug_buf[4096]; <janneke>but not unique, debugging code causing problems <janneke>mescc's stack frame size allocation is terribly unclean...but there shouldn't be a difference wrt using guile <stikonas>and I don't have any normal mes for now... <stikonas>PATH=${PATH}:../mescc-tools/bin/ libdir=lib GUILE_LOAD_PATH=mes/module:module:../nyacc-1.00.2/module/ bin/mes-m2 -e main scripts/mescc.scm -D HAVE_CONFIG_H=1 -I include -I include/linux/riscv64/ -c lib/stdio/fread.c <janneke>of course, 4096 is entirely arbitrary <janneke>ACTION used it waaay back debugging reads <stikonas>perhaps I should try with x86 builds of mes... <stikonas>janneke: does ./configure not work without guix? <stikonas>though I can add foreign distro guix that I have to PATH <stikonas>but that probably shouldn't be required.... <janneke>it just checks for guix to handle automatic guix package edits -- make release etc <janneke>mes should --in non-bootstrap-mode-- behave just like any package <stikonas>janneke: strangely the workaround was ./configure CC=gcc <stikonas>though I run into other problems with guild later... <stikonas>maybe I'll just grab a binary from live-bootstrap that was built with mescc <stikonas>janneke: ok, so mes-m2 from x86 also can't build fread.c from this branch <stikonas>argh, that was because I forgot to export MES_STACK <stikonas>ok, at least with MES_STACK set properly, the whole build process runs fine <janneke>MES_DEBUG=3 may tell you something... <stikonas>janneke: no, it probably crashes way earlier <stikonas>though somehow even x86 version that I built crashed... <stikonas>I ended up writing a kaem script to build meslibc an dmes <stikonas>anyway, at least mes-m2 can run through build process... <stikonas>janneke: also debugging symbols are broken on riscv64 <stikonas>I don't see those function labels in gdb that I would expect with blood-elf <janneke>stikonas: ah, a kaem script for mescc, interesting <janneke>i'll have a look at the x86 version on wip-riscv <janneke>stikonas; without your patch, kaem -f kaam.riscv builds fine, but now i get <janneke>m2/mes.M1:41 :Received invalid other; ld_____%a0,-0x08(%fp) <janneke>just some macro(s) that are missing/in another place i suspect <stikonas>janneke: hmm, indeed there are still old defines in lib/linux/riscv64-mes-m2/_exit.c and lib/linux/riscv64-mes-m2/_write.c <janneke>ah, you're replacing them all, yeah makes sens but a lot of work indeed! <stikonas>ld_____%a0,-0x08(%fp) would be rd_a0 rs1_fp !0x08 ld <stikonas>(ld has to be the last one, other macros can be in any order) <stikonas>so basically a few different macros instead of one <stikonas>anyway, for mes I've used lowercase macros... <stikonas>maybe I should do the same in stage0-posix-riscv64/M2libc too <stikonas>because we started with uppercase macros (this is what old x86 macros looked like too) <stikonas>hmm, for li_____%a7,SYS_exit" I can't use that macro trick that I used in mescc folder <oriansj>stikonas: well we can always put mescc specific things in #ifdef blocks and M2-Planet will now ignore those. <stikonas>oriansj: that just assembly include file there <stikonas>I'll just use asm ("rd_a7 !64 addi"); // SYS_write <stikonas>janneke: I've pushed new update file to my repo... <stikonas>though perhaps I'll now update M2-Planet to spit lowercase defines too <janneke>lib/linux/riscv64-mes-m2/syscall.c: asm ("ld_____%a7,-0x08(%fp)"); <janneke>i guess that the previous version would print Hello,M2-mes! isn't much help in way of debugging/bisecting? <janneke>in any way, i'll start by looking at the scaffold/*.c tomorrow <janneke>like you said, exit 42 already works ;) <janneke>yeah, that was the idea of the scaffold, small steps up