IRC channel logs

<muurkha>stikonas: hooray!

<notgull>stikonas: I see, thanks

<stikonas>notgull: if you want to work on one of those options, let us know :)

<notgull>Sounds good. Im trying to follow the WASM-based bootstrap path I mentioned earlier, to see if it's a viable option

<notgull>But I'm in a rabbit hole and was wondering if Risc-V could host my WASM-based OS

<matrix_bridge><Jeremiah Orians> Yes it can

<stikonas>but wasm is probably one of the intermediate stages...

<stikonas>might be too complex for early stuff

<stikonas>it's somewhere between M0 and cc_*

<notgull>I think I can get to a WASM VM from M0. Then I can use that to bootstrap up to C

<stikonas>in RISC-V you really want to get through hex0 to M0 stages as soon as possible

<stikonas>yeah, that is reasonable

<stikonas>once you have M0, RISC-V is quite alright to work with

<matrix_bridge><Jeremiah Orians> I suggest you prototype your wasm interpreter in a high level language and then rewrite it in c and we can help/do the assembly version

<notgull>The issue I'm trying to solve is to try to establish a secure chain of custody as early into the build as possible

<notgull>Jeremiah: that was my current plan. So far I've been prototyping in C in POSIX

<notgull>It'll be a weird WASM machine, since it needs access to more outside resources than a WASM machine usually provides in order to actually do anything usefuk

<notgull>s/usefuk/useful

<matrix_bridge><Jeremiah Orians> Well file in and file out are unavoidable unless you define them as memory mapped by default

<notgull>Yeah. I was thinking that I could eventually bootstrap my way to a WASI interface, which is not only pretty safe but also there's a libc implementation that wraps it

<notgull> https://github.com/WebAssembly/wasi-libc

<muurkha>stikonas: because the instruction encoding is so hard to read?

<muurkha>notgull: I don't know if there's a good WASM implementation for RISC-V yet

<muurkha>I wonder if you can start with some very small subset of wasm

<stikonas>muurkha: kind of

<stikonas>in particular immediate constants are encoded in nasty formats

<stikonas>it's not just little endian

<stikonas>there are those I J B S formats

<stikonas>and not just immediate constants

<stikonas>but on the other hand, I think riscv is done from a bit lower level than x86

<stikonas>e.g. x86 let's say we have mov rax,rbx

<stikonas>and people tend to look it up how it is encoded

<stikonas>so it's a single M1 define

<stikonas>on the other hand, on risc-v we construct addi x1, x2, x3 from bits that represent addi, x1, x2 and x3 separately

<notgull>muurkha: WASM is a bit more structured than normal assembly, so it doesn't really have the bootstrapping properties of FORTH

<notgull>Although that does get the noggin joggin': could I make a WASM machine that's malleable like FORTH is, and then "freeze" it once it's up to speed with WASI?

<stikonas>notgull: but you also need WASM compiler, don't you?

<stikonas>i.e. people would probably write wasm text form...

<notgull>stikonas: My current plan is to write the text form compiler in M0 assembly, but with the defines compiling to WASM

<matrix_bridge><Andrius Štikonas> Yeah, that makes sense

<notgull>Then I bootstrap from WAT to... some other higher level language, I suppose, to write better drivers in

<notgull>Probably C or Scheme, my brain is too smol for forth

<oriansj>notgull: well forth only is a reasonable language if your target architecture's assembly is garbage or if you lack 64KB of RAM needed to run a C compiler or Lisp Interpreter.

<notgull>Yeah I was reading the wiki and I saw people trash talking FORTH. Is it really that bad?

<oriansj>it isn't bad; it just works best in certain working conditions.

<notgull>Hmm, so like if im trying to bootstrap from a TI-83?

<oriansj>well a TI-83 has a z80 processor and its assembly is quite good

<notgull>Oh, neat

<oriansj>same for 6502 systems like the VIC-20 or Commadore 64

<notgull>Cool, so you can bootstrap from there?

<oriansj>or 6809 systems.

<oriansj>notgull: you can bootstrap from any 8bit processor still available for sale.

<oriansj>or even one you make yourself if you really wanted.

<notgull>Hmm, I just think that it would be hard to bootstrap to anything higher level or with significant memory requirements

<oriansj>well memory requirements can be replaced by disk storage if one runs a virtual machine. (or the hardware has an MMU)

<oriansj>and even VIC-20 systems can be connected to 1TB media these days

<notgull>Almost makes me want to scavenge in my garage for the DVD player I have in there

<oriansj> https://www.c64-wiki.com/wiki/SD2IEC

<oriansj>and there are rather cute options: https://github.com/rossumur/littleatari810

<matrix_bridge><emilytrau> has anyone ever experienced gnu tar exiting successfully but not unpacking any files? (1.17-1.35, musl 1.1-ish)

<matrix_bridge><Andrius Štikonas> No, I don't think I saw anything like that

<matrix_bridge><Andrius Štikonas> Maybe worth strace'ing it?

<janneke>emilytrau: i believe i saw something like that when there was a bug in mes c library's seek function (i've got no experience with musl)

<muurkha>stikonas: that makes sense

<muurkha>notgull: I agree that WASM is more structured than normal assembly

<muurkha>people did use Forth a lot on Z80s and 6502s

<muurkha>I think the biggest problem with Forth is that it tempts you to be clever

<muurkha> https://blog.plover.com/prog/Java.html describes Java as the antithesis of this

<muurkha>if you can resist the temptation to use the stack for local variables, it becomes just a slightly worse language than C with a much better interactive programming environment

IRC channel logs

2023-09-22.log