<OriansJ>xentrac: we looked at c* previously. It only supports uint64_t; which means absolutely no bytes, arrays or structs; which is just horrific to write a C compiler in. (cc_* supports more of the C language than it does) <OriansJ>no support for assembly either, which mean no real syscalls. <OriansJ>Now https://github.com/nanochess/bootOS could be used as a starting point as it provides the ability to create hex files(of exactly 512bytes) So writing a better file editor and a better program loader would be required. Also 640KB hard limits are in place because of the BIOS calls <stikonas>I guess that excludes blynn-compiler then... <stikonas>but I guess once you have M2-Planet maybe it's possible to avoid 512 byte limit... <OriansJ>stikonas: real-mode has to be escaped to enter protected mode which would enable 4GB <stikonas>so basically we need kernel by that time <OriansJ>Which means it is going to have to have hardware specific drives <stikonas>well, there is no really running away from it. Either you have hardware specific drivers, or you rely on some abstraction layer, kernel or BIOS... *stikonas goes back to bison.... <OriansJ>why do you think Bishop Hardware was in the plan from day one? So I could have hardware which reads and writes bytes without a BIOS, firmware, kernel or microcode. <OriansJ>Why do you think every piece was designed not need an environment and only have 1 input and 1 output? So that everything up and including M2-Planet could run on that same bare metal. Then we just get a kernel written in M2-Planet's C subset and it is solved. <stikonas>no, I understand that. I'm was just saying that to agree... <OriansJ>The next question is the selection for getting PowerPC(32/64) and RISC-V hardware for mescc-tools and M2-Planet development <OriansJ>as Guix and MesCC will need us to get that work done too. <OriansJ>either that or find someone with PowerPC/RISC-v Hardware to help <dftxbs3e>I'll have a PowerPC 64-bits VM with GNU Guix on it shortly, I can give out SSH access <stikonas>fossy: pder: so for now I've got bison working with shipped (config.h and configmake.h). Still need to do some more work to remove these two files. But they only contain some defines, so it's definitely possible <stikonas>I guess configmake.h can actually stay, it's just a list of folder paths... <OriansJ>dftxbs3e: well we are looking with people with PowerPC hardware to double check our VM work. <dftxbs3e>OriansJ, oh there is work done already? how was that done? you want native or QEMU/KVM is OK? <OriansJ>dftxbs3e: well QEMU/KVM is something we can already do but it is more about making sure what we do behaves the way we expect on real hardware. <dftxbs3e>OriansJ, okay well I can run anything for you. What virtualized hardware do you have now? From where? <dftxbs3e>Unfortunately I can't give access to my baremetal machine like this for security reasons, but I can run things you tell me <dftxbs3e>There is really not much different between baremetal and QEMU/KVM on PowerPC 64-bits <OriansJ>dftxbs3e: let us hope bare metal and virtualized have no differences that we hit. but the initial testing will just be some mescc-tools tests to get an idea of how immediates would be expressed in M1 and offsets would be expressed in hex2 <dftxbs3e>OriansJ, by the way, I have a working GNU Guix installation on my baremetal machine, so if you have a third party channel with stuff to build :-) <pder>stikonas: thats great news about bison. I had some success building perl, and got as far as miniperl compiling <pder>But there is definitely something weird that needs to be fixed with tcc and musl related to pipes or redirecting output. <fossy>is that tcc / musl related or bash? <pder>It's not bash related because I can reproduce it running the binaries outside of the chroot <pder>tcc-mes behaves correctly and tcc-musl does not. <pder>I ran strace and noticed musl uses writev syscalls instead of write which mes uses. <pder>Did you see my paste from earlier? <fossy>OriansJ: if you have a sec, would you mind repasting the crc32 m2-planet impl <fossy>it expired and i lost it :| sorry ***nckx[2] is now known as nckx
<gforce_de1977>fossy: I changed the two remaining code style issues and the PR is now hopefully ready <efraim>OriansJ: I have a mac G4, 32-bit PPC sitting next to me, already powered on, if I can help. <efraim>I also have one of the mips machines Guix used to use but it's not hooked up currently <gforce_de1977>echo "093c993767f563a11e41c1cf887f4e9065247129679d4c1e213d0544d16d8303 m4-1.4.7.tar.gz" >>SHA256SUMS.sources <stikonas[m]>pder: nice regarding miniperl. Did it not need bison and gawk? <stikonas>actually, awk is probably only needed by ./Configure script <dannym>janneke: I fixed the __*div* functions in mes a little--commit 33cf5ea5e820e21a8f46de7df08a8b49bb8f62ee <dannym>janneke: Now I get: /tmp/guix-build-glibc-mesboot0-2.2.5.drv-3: /gnu/store/s741s14wgn7lhcdm8jsfd0v8mzikazid-mesboot-headers-0.22-123-g9cd754498/include/asm/sigcontext.h:135: warning: unnamed struct/union that defines no instances <dannym>And then ../sysdeps/unix/sysv/linux/arm/sigaction.c:139: `__NR_sigaction' undeclared (first use in this function) <janneke>dannym: when trying to get glibc-mesboot0 built, i was collecting a number of patches <janneke>i didn't share or push these yet (or maybe reverted), as they became more uninformed and hacky as i went along <janneke>until we really got stuck on these division problems <janneke>i was hoping that many of the patches were needed to compensate for including the wrong headers, based on (< GCC_MINOR 3) etc preprocessor instructions <janneke>(there must be something on novena:~janneke/src/guix) <janneke>dannym: i'm pushing the wip'py glibc patch to wip-arm-bootstrap <janneke>i haven't update mes yes; do you have commit for that? *janneke is afk for half an hour or so <janneke>hmm, how come "0.22-123-g9cd754498" didn't update? np, though, we can always amend/reset wip-arm-bootstrap :-) <dannym>What is the version number we should use? ^^ <janneke>dannym: i'm just doing 'make dist' and use whatever it comes up with <janneke>when it works, we release mes-0.23 and it becomes "0.23" :-) <and>/!\ this channel has moved to #nyymit /!\ <sh4nksVx>/!\ this channel has moved to #nyymit /!\ <dfggpZ>/!\ this channel has moved to #nyymit /!\ <nikoXO>/!\ this channel has moved to #nyymit /!\ <dannym>Pushed the guix wip-arm-bootstrap mes update <pder>stikonas: the perl Configure script did need awk. I cheated by using busybox awk, but that was the only tool missing <stikonas>pder: so for now you are using ./Configure script? <stikonas>anyway, I think this evening I'll finish bison and then maybe start looking at awk... <stikonas>pder: but I think we'll eventually want to avoid using perl's configure script... <stikonas>maybe if we manage to write makefile to build miniperl, that would be enough to recreate ./Configure script... <pder>That should definitely be doable. First I want to investigate this issue with redirecting output breaking in subtle ways <stikonas>well, once we merge coreutils and bison, it should be getting a bit easier to experiment... <fossy>hm, but reuse lint passed, how odd <stikonas>and another thing to note when you'll be doing merges is that bison and coreutils PRs don't conflict but coreutils end up with wrong number ***ChanServ sets mode: +o rekado
<fossy>bison looks mostly fine, one question tho, is there a particular reason to use config.h? <fossy>i'm fine with that for the most part <stikonas>if you want I can switch back to cflags... <stikonas>three stages of bison worked quite fine with 3 bash build scripts :) <fossy>which i just commented int he pr <stikonas>in principle I can merge even all 4 files since they all came from a single gio's commit... <stikonas>ok, merged missing includes into one, but left the other patch separate <janneke>dannym: amazing: /gnu/store/jgkf60r29blzhrg0w3dar3rz06xwkx5q-glibc-mesboot0-2.2.5 <janneke>next up is gcc-mesboot0 and it segfaults in configure <dannym>(If you need it, I've also generalized the long division so it works for both long and long long--but let's not change stuff needlessly before the entire thing built successfully once) <pder>stikonas: I found a clue with the issue of tcc-musl -E testcpp.c | cat truncating the output <pder>If I run unbuffer tcc-musl -E testcpp.c | cat it works correctly. unbuffer is from the expect package <janneke>dannym: that's great, and yeah -- let's first see how this goes <janneke>syscalls should be swi instead, right? <dannym>swi and svc are exactly the same opcode <dannym>swi is older, called "software interrupt" <mihi>pder, stikonas: let me guess, it is caused by __stdio_exit being implemented as weak symbol in musl, so your musl-compiled calls the no-op __stdio_exxit instead of the "right" one? <mihi>While you are at it, atexit is also implemented via weak symbols, so in case you patch one, better patch the other one too :) <fossy>cause we patched out weak symbols <mihi>(if you ever encounter programs that want to use atexit, of course :D) <fossy>janneke: is this arm shenanigans? <dannym>in the newer (unified) arm assembly they always use svc, "supervisor call" <janneke>dannym: see novena:~janneke/src/guix/gcc-mesboot.sh to reproduce <janneke>fossy: yes, we just built glibc-2.2.5 on arm, finally <fossy>thats what ur talk said iirc <janneke>glibc-2.2.5 was built with gcc-core-2.95.3 <janneke>sure, risc-v was only added in gcc-7.x, i believe <dannym>janneke: SWI <number!=0> and SVC <number!=0> are non-EABI syscalls btw <dannym>Whatever you do, the flag in the EFI header whether it wants EABI or not must match the actual SWI/SVC usages in the program <dannym>for EABI, it's always SWI 0, SVC 0; never != 0 <dannym>for non-EABI, it's SWI <syscallnumber>, SVC <syscallnumber> <janneke>"janneke: could you also make it write the opcodes of the disassembler?" how do i do that? <janneke>i don't remember doing EABI or non-EABI in gcc/glibc *dannym should lay off the AMD firmware development for a while ;) <janneke>so, it doesn't match with the syscall <dannym>Yep, Linux is gonna be very annoyed <dannym>I verified the opcodes for ldr r8, [r10]; svc 0x00000014; mov r4, r0--they are all correct <dannym>So the CPU is fine with those :) <stikonas>argh, nice catch by migi (although, just left) <stikonas>pder: can if we can survive until binutils, we can then recompile musl/tcc... <pder>so we just need ar from binutils? <stikonas>but binutils is tricky to build, I don't think we can do it before we have autotools <stikonas>it has quite a few big libraries (bfd, etc...) <pder>I'm not clear on what the fix is in musl, since we no longer have any weak symbols right? <pder>And if you remove that weak symbols patch you just had trouble linking? <pder>Do you think it could just be a linking order issue? <pder>static linking can be particular about order <stikonas>but it's hard to control linking order...