IRC channel logs

<stikonas>oriansj: hex2 only supports 32-bit labels, doesn't it?

<stikonas>I wonder why we need to special-case 64-bits here https://git.savannah.gnu.org/cgit/mes.git/tree/module/mescc/x86_64/as.scm?h=wip-riscv#n129

<oriansj>stikonas: well we figured one wouldn't need to produce more than a 2GB binary in hex2 and that %0 %label or %label %0 would work for big or little endian 64bit addresses

<stikonas>yeah, we wouldn't build much more than tcc...

<stikonas>anyway, maybe I can skip that 64-bit part for riscv64...

<oriansj>or just do a riscv32 bit port first

<stikonas>well, I'm just modyfing existing 64-bit port that was using pre riscv defines

<stikonas>which wouldn't really work well with either old or new mescc-tools

<stikonas>but in any case it's easier than new port (riscv32)

<probie>oriansj: is a lisp interpreter in Haskell (that can be run by Blynn Haskell) particularly desirable, or just a case of "would be cool"?

<stikonas[m]>probie: I don't think it's particularly desirable... Just might be cool

<stikonas[m]>But it would probably be slow, even slower than mes-m2

<stikonas>oriansj: anyway, I'm now trying to figure out what is all that wrap-in stuff in mescc...

<stikonas>I'm getting errors like Wrong type (expecting string): (#:string "Hello, Mescc!\n")

<stikonas>so it looks like variables that I get are not strings but somehow wrapped-in strings

<oriansj>probie: I encourage people to pursue projects they might find fun or cool; not that they always should be useful

<probie>The nix derivation for https://github.com/oriansj/blynn-compiler doesn't seem to work :(. I'll just build it using gcc for now

<oriansj>probie: well probably because of the transistion from FILE* builtin type and proper FILE* structs

<oriansj>and we transistioned to using M2libc after we noticed a good bit of duplication occuring.

<probie>Nah, I think it's pulling a bad version of M2libc (or not pulling it at all). It's getting "Unable to open for reading file: M2libc/sys/types.h"

<oriansj>yep, that'll do it

<oriansj>if you are using M2-Mesoplanet use -I or setting the env variable M2LIBC_PATH to where a copy of M2libc is located

<oriansj>but there might still be a few lines using the old //CONSTANT behavior

<probie>To clarify, I'm getting this failure when I run `nix-build -I nixpkgs=https://github.com/OriansJ/blynn-compiler/archive/master.tar.gz '<nixpkgs>' -A blynn-compiler`

<oriansj>probie: here is what I get: https://paste.debian.net/1280186/

<drakonis>muurkha: that's an enjoyable 100r post

<emilytrau[m]><ericson2314> "emilytrau: it looks like kaem-..." <- i didn't notice! great catch thank you!

<emilytrau[m]><ericson2314> "it would also be good to use ..." <- what's the difference between `derivation` and `derivationStrict`? I can't find docs for it or examples in nixpkgs

<muurkha>drakonis: yeah, I loved it

<ericson2314><emilytrau[m]> "what's the difference between `..." <- `derivationStrict` is the actual primop, and doesn't leak its inputs

<ericson2314>there is no urgency to use it

<ericson2314>but some of us have been thinking it would be good to migrate Nixpkgs away from always leaking this steam (for perf and sanity)

<ericson2314>and the bootstrap, being self contained, is an excellent place to start :)

<ericson2314>btw, I've started working on the parallelism thing

<ericson2314>no mv or rmdir?

<stikonas[m]>In stage0-posix? No those are not present

<stikonas[m]>You could do cp followed by rm

<stikonas[m]>Possibly rn works on directories too but I'm not sure now

<ericson2314>stikonas: is there a barrier to adding them?

<stikonas[m]>Not really...

<stikonas[m]>Like I said we already have cp and rm

<stikonas[m]>mv is just combination of them

<ericson2314>it seemed like cp recursive was working weirdly?

<ericson2314>also mv has different performance characteristics

<stikonas[m]>I don't think we have recursive cp

<ericson2314>yeah it make have just made me a blank dir or something

<stikonas[m]>stage0-posix has a fairly simple cp

<ericson2314>`mv` gets "recursion for free"

<ericson2314>so to speak

<ericson2314>anyways, it is not a blocker

<ericson2314>maybe I could contribute it, but no rush

<stikonas[m]>As long as we I don't need any new syscalls. We would like to keep initial syscall set small, to not extend builder-hex0 kernel

<stikonas>janneke: so I'm looking a bit at riscv64/as.scm and M1.scm. So x86 version had lots of calls like (#:address ,label) in as.scm that are processed in M1.scm file.

<stikonas>janneke: so for riscv64 I think I need to add similar addresses but specific riscv64 instuction formats

<stikonas>e.g. u_format

<stikonas>do you think they can go to M1.scm?

<stikonas>e.g. what is in x86 hex2:offset3, in riscv64 is address for u-type instructions

<janneke>stikonas: yes, adding another type (#:u-format) sounds as the way to go

<ericson2314> https://github.com/ZilchOS/bootstrap-from-tcc oh already in Nix

<ericson2314>I wonder if it is useful

<janneke>stikonas: or possibly keep (#:offset ..) and (#:address ..), but in M1.scm differentiate how to handle those according to the archictecture in info

<stikonas>oh info has architecture...

<stikonas>hmm

<janneke>wait, has info architecture

<janneke>right, i was just looking that up

<stikonas>oh, but emitting is more complicated

<janneke>no, it hasn't

<stikonas>e.g. in x86 it was (string-append "mov____0x32,%" r) (#:address ,label)

<janneke>yeah, using new labels seems the proper solution

<stikonas>on the other on riscv64 I need to emit a few instructions

<stikonas>something like

<stikonas>"rd_a0 ~label auipc" and then "rd_a0 rs1_a0 !label addiw"

<stikonas>auipc loads high bits and addiw then adds lower bits

<janneke>ah

<janneke>you can prolly just create a list

<janneke>'("rd_ar" (#:u-format? ..) "auipc")

<stikonas>ok, I'll try that

<stikonas>though don't expect anything fast... I'm still fighting with scheme which I'm just barely familiar with

<janneke>stikonas: i'm delighted you're willing to look into this

<janneke>and i'd much rather have you can enjoy it than finish a bit sooner

<ericson2314>janneke: I would like to add a CLI flag for the CRT dir for tinycc

<ericson2314>what branch/repo should I target?

<mihi>stikonas, I assume you have solved the mystery of "wrapped strings"? :)

<stikonas[m]>mihi: more like understood how they are processed

<stikonas[m]>after looking at M1.scm

<stikonas>mihi: they are processed in https://git.savannah.gnu.org/cgit/mes.git/tree/module/mescc/M1.scm#n146

<mihi>ok :) I would not call those list expressions inside quasiquote and pmatch "calls", they are just list expressions which are later processed by pmatch :)

<ericson2314>oh maybe I can do '{B}' tricks

<janneke>ericson2314: the latest in use in guix, is mes-0.23

<ericson2314>ok thanks

<Irvise_>A potentially dumdum question. Can Mes be run in a "normal" Linux distro?

<Irvise_>I would like to test its Scheme support. However, it seems it requires "blood-elf" to be installed in the system. That requires Mescc-tools, which require M1 planet, but that seems to require the rest of the "low level" bootstrap procedures...

<mihi>Irvise_, you can build mescc-tools with gcc or tcc, no M2-Planet required

<mihi>just use the included Makefile

<janneke>Irvise_: sure, i believe mes is included in debian

<janneke>as is mescc-tools, no planets are needed

<janneke>it's also included in guix, as a regular (non-bootstrap) package

<janneke>guix install mes ;-)

<Irvise_>OpenSUSE does not have nyacc available in the repos. I will go down the Guix route :)

<janneke>Irvise_: to run mes itself, you don't need mescc-tools or nyacc

<janneke>those are only required to run mescc

<stikonas[m]>And nyacc has to be at very specific version

<stikonas[m]>It's just easier to get it outside distro

<mihi>ACTION was not aware that mes, mescc-tools and nyacc are packaged in Debian. Also, the only package depending on either nyacc or mescc-tools in Debian is mes :) But mes in debian stale is at 0.22 and mescc-tools at 1.1 :)

<stikonas[m]>And Debian build of mes is built with gcc

<stikonas[m]>Unlike guix build which is bootatrapped

<janneke>sure, well, in guix you can have both

<stikonas[m]>Well mes-m2 is crashier than mes

<stikonas[m]>I have seen cases of mes-m2 crashing on tcc build

<stikonas[m]>But mes working fine

<janneke>ouch

<mihi>ACTION wonders if did anyone did ddc with mes built with itself or mes-m2 for different compilers that built first mes?

<mihi>I would expect the binaries should be identical once you have built mes with mescc.

<stikonas>I think I've seen that with mes-m2 0.24, haven't tried building tcc with mes-m2

<stikonas>mihi: yes, that will be identical

<stikonas>but binary mes-m2 build with M2-Planet will be quite different from mes built with mescc

<stikonas>M2-Planet binary is maybe twice as big and is 30% or so slower

<mihi>stikonas, so you tested it, but is that just the expectation?

<stikonas>identical builds?

<stikonas>somebody else tested earlier

<mihi>okay :) best argument ever :P

<stikonas>Debian Guix, etc builds were identical

<stikonas>though it was with older versions

IRC channel logs

2023-05-14.log