IRC channel logs
2023-05-04.log
back to list of logs
<stikonas>this function is mostly used with r0 = r1 (but not always), so perhaps we are lucky not to hit any serious bug <stikonas>hmm, I think if I use new defines that whole function would look a bit different anyway <stikonas>there is no need to special case 1 0 and -1... <stikonas>janneke: unless I'm very confused, current mes risc-v code would not work at all with mescc-tools <stikonas>it passes --architecture riscv to M1 and hex2 <stikonas>but then uses % @ ! and & $ as if they are standard immediate <stikonas>On risc-v M1 has different meanings for % @ ! <stikonas>it's not 32-bit 16 bit or 8 bit immediate <stikonas>but rather specifies instruction type and appropriately mangles bits <stikonas>yep, it does seem like this is what is happening <stikonas>no way current wip-riscv branch could work <stikonas>I think it predates all that fixed word architecture work that oriansj did for hex2 and M1 <oriansj>stikonas[m]: %label and &label are still 32bit relative and 32bit absolute values <oriansj>@ is RISC-V B format; $ is RISC-V J format and ~ is RISC-V U format <stikonas[m]>Though we have nothing to insert e.g. 32 bit value directly... <oriansj>except with immediately followed by an integer and then it is: ! is RISC-V I format, @ is RISC-V S format and ~ is RISC-V U format <oriansj>well %0 and %-1 would certainly make sense in RISC-V <stikonas[m]>Yes, but the way mes was loading immediates was store it inline in the code and load it <oriansj>if we did something like jump 4; immediate; loadr R0 [PC-4] <stikonas[m]>There is no prefix right now that does not mangle bits <oriansj>it just writes 4 bytes in the appropriate endian order <oriansj>we could simplify that logic to only cover values that fit in I format and just use RD_A1 RS1_A0 !214 ADDI and if it is outside that range, jump over the immediate %value and do a relative load <oriansj>you can opt to later add more cases to make it more efficient <janneke>stikonas[m]: that would be great, no hurry <janneke>ACTION is still looking for a riscv machine running guix (or guix substitutes) anyway <oriansj>I guess I could write up a gentoo setup procedure for RISC-V which would get you to a state capable of doing that development. <stikonas[m]>Qemu userspace emulation gets me most of the way there already... Not sure about janneke though <oriansj>stikonas[m]: Guix doesn't have qemu userspace so.... yeah <janneke>i'm using qemu-binfmt a server, but didn't want to rebuild world when someone's got substitutes available <janneke>esp. because off correctness, i had quite some litts problems there with arm <stikonas[m]>We had one small issue with riscv on qemu that triggered but in real hw. qemu zeroed all registers on start which real hw didn't. But that's the only difference <muurkha>service? Do you mean like a daemon or more like a company you pay? <stikonas[m]>It's not a daemon, it's just one off configuration of kernel <roconnor>janneke: where can I find binutils-boot-2.20.1a.patch ? <stikonas[m]>That's way bigger patch than what live-boitstrap has for binutils 2.30... <aggi>the dependency graph, for autotools/perl is somewhat problematic, that much, i rather avoided those entirely <aggi>which is possible, with a tcc-toolchain-only system, as an alternative option, for some specific *nix niche <aggi>that's the plan, already got some devdrop, of a 99% tcc-toolchain only compiled system, and it booted, and x86_64 (no problem to back down to x86_32 either) <aggi>yes stikonas[m], that's why. oasis-linux, re-implemented the binutils buildsystem completely, with their custom lua-based scripting <aggi>lua, last time i reviewed it, was much easier to cross/compile, than perl for example <aggi>i am not opposed to autotools/perl/gnu itself, i think however, an alternative is necessary, to avoid those, not because of GPL licence, because of technical reasons <aggi>because, i think, GNU, got quality issues, rather severe, and the bootstrapping ones, are some of those <aggi>with autotools involved, the cure seems worse than the disease it was intended for to cure <aggi>strangely, there was some blameshift onto GNU/GPL, although the bootstrapping and quality issues, originated elsewhere <roconnor>guix builds binutils-mesboot0 without autotools? <stikonas[m]>I just checked, that lua system does not rebuild bison/lex files <roconnor>I guess guix calls configure directly without deleting it. <stikonas[m]>But need more manual commands if you need to rebuild some generated c files <aggi>if tcc-toolchain, was capable, to fully replace binutils-asm, this would be a highly desireable alternative to have available <aggi>if i succeed with tcc-only for kernel/asm-parts/libc which is missing still, then this is where i will stop, and not bother with binutils bootstrapping/cross/compile <aggi>i mean, it is important, to have a clean bootstrapping path for the _entire_ GNU, and it is too extremely important, to have have an alternative to autotools/perl/etc <stikonas[m]>aggi: well, if tcx is sufficient for you then why not <aggi>i tracked a huge dependency graph, against autotools/binutils/gcc already, and almost all of it can be avoided <aggi>stikonas[m]: tcc, can compile/assemble/link almost _everything_ <aggi>linux-2.4-x86-tcc/tccboot, that's some missing piece at the frontline i was fighting at, and some minor musl-libc-asm parts, which bootstrappable reported were patched already for tcc <aggi>i did cleanup the entire profile here already, to avoid _all_ c++ dependencies <aggi>well, tcc was one motivation, to do it, and guess when ignoring the autotools/perl issue, i even got mplayer/libsdl and various stuff recovered, from the gentoo-archives from 10 years ago <aggi>i mean, that's outside the scope of bootstrappable, but it is feasible, to arrive at this level of software-complexity <stikonas[m]>Yes, it indeed can build most of the low level stuff <aggi>and mutt mailer, catgirl irc client, a shell, lua-interpreter... <aggi>well, i do see a chance for w3m to survive, with sixel graphics support <aggi>dvtm terminal multiplexer (see suckless.org), was easy with tcc, yaft for sixel buffer below... it is feasible <aggi>however, tcc-emitted binaries, are notable slower, than gcc -Os optimized ones <aggi>interestingly, Bellard did optimize some ffmpeg/mplayer parts for MMX... so this may not be hit that severe <aggi>that's the rationale behind what i did, in the last years <aggi>to recover a useful free software stack, which passes minimum acceptance criteria, including clean bootstrapping <aggi>that's why, i joined here <aggi>i tried to say, gcc optimization, are decent, and relevant, but i am willing to sacrifice those, for a tiny software niche, i consider more important, for my realm of things <aggi>gcc-toolchain, is powerful, but it doesn't fit into use-case and acceptance criteria, which tcc may, if it can replace gcc/binutils 100% <aggi>among OpenBSD, they tried with pcc, which doesn't contain asm/linker etc... and this was difficult enough, year 2007 <aggi>in comparison, that's when you realize, how powerful and important tcc is <aggi>i am a little worried, about recent versions of it <aggi>i got a little sick recently, didn't continue any longer <aggi>most recent tcc-versions, require libc-stuff, which earlier versions didn't... that's important, to be aware of <aggi>tccboot, and related problems, that's too important, to review, and verify, what went wrong, and why, with linux kernel <aggi>because, i think it is not possible, to survive with fiwix and limited hardware support, it's both an advantage, and too problematic if you haven't got usb, but needed it <aggi>if Bellard had answered to my mail, i had wanted to ask too, what he thinks, about recent changes to his compiler, adding complexity and libc-dependencies, which his version didn't have <aggi>and i think, for bootstrapping, the riscv-64 and aarch64 support are irelevant, for other reasons (u-boot related, which locked against c++ dependencies/python-swig) <aggi>so, you couldn't easily bootstrap a firmware/bootloader for riscv-64 or aarch32/64 almost always, without c++/python/swig creeping into... i won't accept this, for the niche i am interested in <aggi>stikonas[m]: don't quote me, it seemed, tcc shipped required headers and functions itself, without the need to link against any libc.a... correct me if i'm wrong <aggi>i did review several versions of tcc, and with tccboot, earlier versions didn't require any libc at all (tccboot is different to tcc-compiler) <aggi>it was just a coincidence, to see later versions of tcc, did more heavily lock against libc-stuff, mainly related to 64bit/aarch64/riscv64 it seems <aggi>and i had raised this question before, which version of tcc-toolchain i should stick to: tccboot, linux-2.4, bootstrappable, and the c-only software-profile i collected <aggi>two years ago, i just picked some (buggy) git-HEAD of tcc, patches some stuff myself, and used that; i'll probably roll-back with tcc itself too <aggi>0.9.25...seyko2-changes some place, if this is clean and doesn't require additional libc-linking for tccboot-loader <stikonas[m]>Well, that's not too surprising regarding libc. Like I said you can't write portable code without libc. libc is the place where platform abstractions go <stikonas[m]>So once you want to have more than 1 os or isa, you need libc <oriansj>aggi: well requiring a libc isn't a problem if one only uses 6 syscalls and a couple simple libc functions. Heck M2libc supports much more than that <oriansj>and that is entirely for supporting the tools other than M2-Planet <oriansj>give me fopen, chmod, fgetc and fputc and I'll bootstrap the world <oriansj>fseek, fclose and everything else are just nice extras <probie>Don't you need some sort of exec in there? <oriansj>probie: the Compiler doesn't need to exec anything. Only a shell would <oriansj>and then we would be talking about the libc requirements of the tools you want to build and what compilers support the constructs in those libc implementations. <probie>I guess I'm thinking about a scenario that's not really worth thinking about - that you want to build a system by booting into it (so the start of your bootstrap process and the only binary is at /sbin/init) <muurkha>probie: I think that's quite reasonable; in a sense that's how tccboot works, and there are also some Forth systems that have booted up that way <muurkha>stikonas: you can provide the same syscall interface on more than one platform; WSL1, FreeBSD, and Linux all support the same Linux syscall interface <stikonas>but even Linux does not provide the same syscall interface for x86 and x86_64 <muurkha>so a program like qfitzah or stoneknifeforth built for that interface without libc can be expected to run on all three <muurkha>well, it sort of does; stoneknifeforth, httpdito, and I think qfitzah are written for i386, but they run fine on this amd64 Linux box <muurkha>but it's true that Linux *also* supports an amd64-specific syscall interface on here, which is necessarily different; it isn't even clear what it would mean for it to be the same <muurkha>you can't, for example, put the same arguments in the same registers, because those registers don't exist in some cases, and in any case are too small <stikonas>ok, but still, riscv64 has completetly different syscall numbers from amd64