IRC channel logs
2022-09-14.log
back to list of logs
<oriansj>ok, I think there is only about 12 emails on the mailing list that I missed. (all before I knew that it existed and a couple deleted about the website being down and the mes 0.8 release) <oriansj>so rekado or janneke if you have a copy of those, we can have a complete and up to date mbox file <oriansj>midnight: hopefully that helps you out (sorry it took longer than expected) <stikonas>mihi: so something is indeed bad with one of the earlier text processing tools (sed, grep...) <stikonas>should be backup, comment, emit, file, guard, optimize, pthread, table, test; but it is only ; <stikonas>ok, I think it's just the case of grep being too old <stikonas>fossy: so I think for autogen stuff we need to add at least the following: build newer grep, then either build which or add a bash wrapper around command -v <stikonas>and then of course some further fixes to gnu-autogen-bootstrap repo <stikonas>next autogen error is bootstrap failure: cannot find GNULIBDIR but that should be easily solvable <stikonas>doras: would you mind backporting your header change to binutils-2.14 ? <doras>stikonas: if my small patch to get it to automatically regenerate is acceptable, sure. <stikonas>the one that removes @MAINT@ ? That's fine <doras>stikonas: actually, the patch may not be needed for `binutils 2.14` since we're not targeting the architectures for which the files were pregenerated. (ia64 and z8k) <doras>In `binutils 2.38` there was also a pregenerated file for i386. <doras>I'll upload a PR once the bootstrap succeeds. <stikonas>though we are not super strict about removing non-used pre-generated files in live-bootstrap <stikonas>in some places it is done but not everywhere <doras>Yes, I'll just rm those files. I just want to make sure it doesn't actually break the build. <doras>It's harder to figure out which pregenerated files are unused than to simply remove them all. <stikonas>well, once you start relying on complex build systems, then yes. Very early in bootstrap (especially when we manually write makefiles) we know exactly what is used <aggi>apropos, currently stumbling, upon perl-5.8 dependency graph... sys-libs/db and gdbm <aggi>seems circular... perl requires db,gdbm, db and gdbm require autotools, and autotools require perl <aggi>hence, a toybox userspace linked against mes-libc is desireable <aggi>and i already git-pulled a posix make implementation... just in case whatever dependency graph gnu make got <stikonas>those are probably optional dependencies <aggi>yes, in the gentoo-ebuilds those are labeled optional with use-flags <stikonas>optional circlular dependencies are fine <aggi>however, currently while archiving/freezing the gcc47 c-only toolchain profile, a cross-compile CBUILD=aarch32 with CTARGET=amd64 <aggi>the perl-5.8 build freaks out over missing headers of db,gdbm <aggi>although i didn't activate those use-flags <Hagfish>"It's harder to figure out which pregenerated files are unused" <-- is it possible/useful to record which files are read by using some kernel level tool? <aggi>another good question, had not begun yet to downgrade to linux-2.4, and which implications this has with headers pulled in from kernel (for mes-libc) <aggi>musl-libc insists on some kernel 2.6.X; don't know if mes-libc will pass with linux-2.4 headers <aggi>criteria for linux kernel version: must compile with tcc-toolchain (without binutils/gcc) <aggi>which could introduce another circular dependency graph, with perl/autotools if perl is required with kernel-build by tcc-toolchain <aggi>tcc-toolchain (tccboot) implemented some custom build-system for linux-2.4, and didn't use linux Kbuild <aggi>Hagfish: reminds me of another utility, systrace from nils provos <aggi>while ago create a gentoo-ebuild <aggi>anyway, the bootstrapping path with tcc-toolchain/kernel-2.4/toybox-userspace/mes-libc should exclude all GNU autotools and related dependencies <aggi>"public domain implementation of make which follows the POSIX standard".. hopefully this suffices to avoid GNU make too <sam_>[11:17:07] <aggi> seems circular... perl requires db,gdbm, db and gdbm require autotools, and autotools require perl <sam_>yes, you can avoid db, even gdbm <stikonas>thoguh that pdpmake is still interesting <aggi>sam_: just found it a moment ago, i think perl-5.8 build system has general issues when cross-compiling <sam_>aggi: maybe can find old perl-cross? <sam_>there's autotoolsification for perl which makes it much easier to cross <aggi>sam_: no need to worry about perl-5.8 cross-compile <aggi>currently, this issue affects the gcc47 c-only system profile freeze/archival only, and i'll hack it <aggi>with the tcc-toolchain i'll prefer a more radical approach, including full removal of autotools/gnu-make etc <aggi>of cause, bootstrapping gnu-toolchain/buildsystem shall be possible, however first with the tcc-toolchain profile i want to remove the vendor-lock against GNU <aggi>for _technical_ reasons, there's that many <aggi>stikonas: gnu-make depends on autotools/automake which is reason enough to consider a full detanglement and alternative approach with a POSIX make implementation, if possible <stikonas>aggi: yes, but it's trivial to build gnu-make with your own makefile <aggi>stikonas: thanks! noted. <stikonas>you still need to write a list of tcc commands <stikonas>though maybe pdpmake has fewer files, so the build script would be shorter <doras>stikonas: what do you say about changing musl's library path from `/usr/lib/musl` to `/usr/lib/i386-linux-musl`? <stikonas>doras: fine with me, just keep in mind that a lot of hashes would change, so I prefer a separate PR for that <doras>It seems that some projects expect the system's library path to either have no special prefix (simply /usr/lib) or have a triplet-style path (/usr/lib/<triplet>). <doras>And for those I have to add `-L/usr/lib/musl` manually to CFLAGS. <stikonas> /usr/lib is not good for live-bootstrap because we do jump across different libc's unlike normal system <stikonas>and it's much easier to jump if you can have them coinstalled <stikonas>or perhaps I'm mistaken here and /usr/lib could also work <stikonas>I don't think we actually build anything with mes libc once musl is built <doras>stikonas: also, I noticed that we don't have a `/lib`->`/usr/lib` symlink. Is this intentional? <stikonas>not sure if it was fully intentional, but we never needed it <stikonas>well, I don't have /lib -> /usr/lib symlink on my normal Gentoo system either... <doras>I doubt something needs it, but it's usually what distros do. <sam_>doras: this is "merged usr" <sam_>it's completely fine to not have oneq <sam_>it's not what all distros do, it's really just a choice <sam_>in general I think one probably should do it as it's way simpler <doras>Actually... never mind. I think we do have it. <doras>Or at least it's there mid-bootstrap. Strange. I was sure it wasn't there after the bootstrap completed. <stikonas>it might be added there in sysa->sysc jump <doras>I'll check again when the bootstrap ends. Maybe something removes it. <aggi>sam_: fyi, perl-5.8 doesn't contain a configure script supporting cross-compile <sam_>that's why I mention perl-cross <aggi>cross-compile and bootstrapping are distinct problems, had only hoped for to keep version perl-5.8 for all those <aggi>ok, seems the perl-5.8 ebuild scraped from the archives didn't utilize perl-cross <aggi>to keep it simple, i'll probably do this: perl-5.8 for regular and tcc-toolchain builds, and an exception/unmasking of a recent perl version for cross-compiling with the gcc47 c-only toolchain system profile <aggi>having tested perl-5.8 suffices, i do know it works, and passes with tcc-toolchain if necessary <aggi>and hacking cross-compile support into perl-5.8 to support GNU autotools which i want to avoid anyway, is too much effort <aggi>wanted to begin testing mes-libc almost two weeks ago already, and problems simply do not stop piling up while freezing/archiving the gcc47 profile <aggi>sam_: quickly tested perl-cross with perl-5.8 "This perl version is probably not supported by perl-cross" <doras>stikonas: I suspect the symlink is removed because of musl's dynamic linker. <doras>Mostly because it's the only thing left in `/lib` when the bootstrap completes. <doras>I guess this means `xbps-install` isn't smart enough to follow symlinks? <doras>I'm not sure if it's smart to have musl install the dynamic linker into `/usr/lib` instead. <doras>I guess I can "mv" it post-install. <sam_>we had fun with this before, btw <sam_>it doesn't properly respect DESTDIR <stikonas>luckily live-bootstrap does not need to deal with cross-compilation <stikonas>doras: anyway, fossy is the person to go to for xbps questions <aggi>perl-5.8 isn't supported by perl-cross helpers, which is an annoyance because i wanted to keep this version for any bootstrap/cross-compilation path <aggi>otherwise, perl-5.8 suffices for latest autoconf/automake, at least <aggi>yet, perl-5.8 known to compile with tcc-toolchain, fails cross-compilation <aggi>not important, just another hint, why i want to fully detangle from GNU-toolchain and GNU-buildsystem <aggi>too, it's a relevant question, which priority a clean cross-compilation path had with bootstrapping <aggi>any cross-compile with CBUILD=gnu-toolchain CTARGET=tcc-toolchain, currently, will fail, because of perl-5.8 <aggi>if the ARCH is identical with both gnu-toolchain and tcc-toolchain, that's the only small path to sneak through with perl-5.8 and tcc-toolchain <aggi>which is the minimum linux kernel version of boostrappable? i fear linux-2.4 (or 2.6) to compile with tcc-toolchain could hit problems elsewhere (mes-libc?, don't know yet). <stikonas>mes-libc itself shouldn't cause problems, linux does not need C library <stikonas>at most some helper tools need it (kconfig stuff?) <aggi>tccboot implemented some self-made build-system for linux-2.4 <aggi>i do know, musl-libc does require a later kernel-2.6 (it's documented on the web-site of musl-libc) <aggi>the idea is, to avoid musl-libc entirely, and see to toybox userspace links against it <aggi>toybox build-time dependencies are less troublesome than GNU coreutils/util-linux/etc.., too toybox userspace is less troublesome than busybox <doras>I think I'll make some changes around musl's dynamic linker. I see some issues. <aggi>toybox userspace links against it, mes-libc, without any musl <aggi>i wouldn't bother either if static-linking "only" was available, that's good enough <aggi>fyi, "TCCBOOT was only tested with Linux 2.4.26", musl-libc requires v2.6 <aggi>so, either linux-kernel compilation was verified against tcc-toolchain with v2.6, or musl-libc is gone <muurkha>what's the problem with musl on 2.4? <aggi>"musl is built on the Linux syscall layer. Linux kernel >=2.6.39 is necessary for POSIX conformant behaviour" <aggi>"2.4 kernels will only work for simple single-threaded applications" <aggi>no clue, what "simple" covers, such as toybox userspace, and some development utilities (Vim, git, make, tcc-toolchain) <muurkha>I wonder if glibc on 2.4 was non-POSIX-conformant in similar ways <muurkha>presumably the issue is something related to POSIX's shitty threading semantics <muurkha>but maybe there's other stuff I don't knwo about <aggi>well, i would too rule-out musl-libc (and most other libc) because it does require binutils to digest GNU gas assembly <aggi>there's only one way to know, re-vive tccboot with linux-2.4, mes-libc, and toybox userspace linked against it <aggi>with tcc-toolchain that is, not GNU <muurkha>GNU gas assembly is pretty trivial, isn't it? <aggi>not my field of expertise, and if it was, i rather depart to Z80 assembly or Gigatron TTL <stikonas>and there are just 13 or so arm assembly files in musl <stikonas>can't be too hard to fix them to subset that tcc understands... <stikonas>I doubt that it needs much expertise, just a bit of time and reading through docs <aggi>lol, last time i tried to read docs at developer.arm.com w3m browser didn't render anything <muurkha>ugh, yeah, I've had that problem too <aggi>the only browsers i would consider barely passing acceptence criteria <muurkha>I think for ARM, gas syntax is actually regular ARM syntax <stikonas>I'm sure there are plenty of other tutorials <muurkha>yeah, there are some nice books on ARM assembly <stikonas>or even if you read x86 assembly tutorial, 90% of the arm assembly would be clear <stikonas>or maybe risc-v would be a bit closer but still <aggi>i did dig into the aarch32 assembly parts, and no, it is not trivial <aggi>and it's cluttered with various extensions, for arm vfp, gnu gas specifics and whatnot <muurkha>yeah, risc-v is closer to arm than amd64 is <aggi>question then, if it's so simple, why then didn't arm-tcc digest the aarch32 asm inside musl-libc? <aggi>same with python/libffi aarch32 asm parts... failed with arm-tcc... <muurkha>what I meant is that translating from GNU gas assembly syntax into the syntax for whatever other assembler you're using is generally pretty trivial <muurkha>not that writing an assembler is trivial <muurkha>(sometimes it is, but indeed not for the entire ARM instruction set) <aggi>if it's trivial, why does it fail then? <muurkha>not trying is the easiest way to fail! <aggi>you know, i had wasted yet another two weeks to cleanup the typical GNU chaos <aggi>and whatever had failed, a rollback to linux-2.4 is necessary to pass with tcc-toolchain <aggi>it's certainly not any of my failures <aggi>muurkha: your arrogant attitude is somewhat inappropriate, given this situtation, whoever you are or whatever you do otherwise <aggi>and such a kernel-version rollback, this one alone is estimated worth more than 2billion cash coins worth of development costs <aggi>muurkha: and if you could recommend any appropriate aarch32 hardware i could boot such a kernel with, lecture me please <aggi>i am certain, an opensource aarch32 SoC, that's accomplished, with a few minuts of work? because it's "trivial"? <sam_>i think you've misunderstood what they meant <sam_>they mean mangling handwritten gas into another format is usually only a few transformations <aggi>for aarch32/64/RISC-V, uboot-loader would need a rewrite too, to avoid c++/python-swig there as BDEP <aggi>otherwise, you had to take the route with GNU-toolchain and c++, which is dozens of millions of LOC, trivial or not <aggi>to have a boot-loader at least <stikonas>indeed, even converting from GAS syntax to M0 is fairly trivial (and M0 is a tiny program far far simpler than tcc) <stikonas>writing the whole things is indeed more complicated, you need to plan how to structure everything in assembly <stikonas>but making changes or moving to different syntax is relatively easy <aggi>none of this is neither simple nor trivial <aggi>stikonas: did you test the hex0.S with amd64-tcc? <stikonas>no, neither tcc, nor gcc works with it, I built it with clang <stikonas>only clang supports x86_64-unknown-windows <stikonas>well, there is also fasm2 but it was not packaged on Gentoo <stikonas>but .M1 version can be built with M0 which is 2 KiB binary <muurkha>aggi: I'm not sure what you think is arrogant. I think probably arm-tcc doesn't translate ARM assembly between formats because tcc doesn't try to translate assembly between formats <muurkha>maybe if you think I'm arrogant it's because you thought I was saying *you* weren't trying, but that wasn't what I meant <muurkha>I recognize that you are doing awesome and amazing and very difficult things, and they are things I appreciate very much <muurkha>as for arm32 SoCs, I don't think there can be an open-source one due to ARM's patents, but the Raspberry Pi is ARM32, is ubiquitous, and has a reasonably well documented boot process (unlike the even more ubiquitous used cellphones) <stikonas>doesn't raspberry pi need huge videocore blob? <stikonas>so I wouldn't call it reasonably well documented <stikonas>there are some way more open arm systems, or at least aarch64 <muurkha>yeah, there are some much better aarch64 systems out there, like the various pine64 things <muurkha>but I don't know of a better option than the Pi for an arm32 with an MMU <stikonas>indeed, I have rockpro64 which does not need any blobs to boot <stikonas>well, there is a blob on the ROM (32 KiB if I remember correctly) <stikonas>but it's ROM, so might as well be hardware <aggi>the low power consumption of those ARM SBC is amazing <aggi>and those too define some natural barrier to what's acceptable with compile-time performance <aggi>reason enough, to remove c++/g++ and llvm <aggi>until i realized, uboot-loader got a nasty dependency graph (python/swig/c++) <aggi>and, rock64/rockpro64 require an aarch64 uboot/kernel... which gcc47 doesn't support anymore <aggi>another reason, i'll freeze/archive/terminate the c-only toolchain system profile <aggi>there is no way forward anymore with this <aggi>backtracking this, including opensource hardware, i arrived at Z80 FPGA SoC or Gigatron TTL <aggi>as far as hardware bootstrapping is concerned, Gigatron TTL is the best offer to my knowledge <muurkha>what is the problem with the C-only toolchain system profile? <aggi>doesn't require any fancy software tooling, TTL7400 series parts are available (some Z80 parts may be scarce already) <aggi>muurkha: a c-only system profile required extensive treatment of the portage tree (working with gentoo) <aggi>had to pull in 300 ebuilds into my overlay already, with 600 packages still available (which don't require any c++ anywhere in userspace) <aggi>and yes, i rather had fun with assembly hacking than struggling with GNU autotools wreckage, for months and years <aggi>btw, SDCC compiler, is implemented in c++... just saying <aggi>although with Z80 or Gigatron TTL, i would probably skip the entire C-lang realm and stick to ASM <aggi>yet then it wouldn't neither be ARM nor X86 <muurkha>if you're building your own CPU it might be less effort to use an architecture better suited for C <muurkha>I don't know if you saw that SeRV implements all of RISC-V in 200 4-LUTs <muurkha>a small fraction of Lattice's smallest FPGA <aggi>there's some interesting 68K SoC too; in the end, as soon as linux and GNU (or BSD) get involved, situation is, difficult, to remain polite <muurkha>Linux up to about 02010 is pretty doable without C++ I think? <aggi>i patched Linux-5.10 already, to avoid some C11 clutter, and passed with gcc47 still <muurkha>the 68k is pretty nice to program on but it's an order of magnitude bigger than an ARM1 <muurkha>and the ARM1 is an order of magnitude bigger than SeRV <aggi>my current favorite is the Gigatron TTL; with such a device however, obviously, no internet <aggi>the advantage with Z80 is this, it's relatively cheap, and Rodney Zak "Programming Z80" didn't require any update in 40years <muurkha>why obviously no internet? Contiki can run a WWW browser on a Commodore PET <muurkha>I think the Gigatron is 39 74HCT and 62256 chips? <muurkha>...and what is this ATTiny85 doing in it? <aggi>i could dig down to the Verilog/Digital-Circuit design level, not any lower down to transistors or physical manufacturing characteristics <muurkha>I don't think SeRV by itself will run Linux, but maybe you could bolt an MMU onto the side of it <muurkha>unfortunately RISC-V support in GCC postdates C++ in GCC by quite a bit <muurkha>the PicoRV32 RV32 implementation is several times larger than SeRV but enormously faster (because it's not bit-serial) <aggi>muurkha: good question, any clue what the ATTiny85 does? for the sake of it any such system should contain un-documented ICs <aggi>*should NOT contain un-documented ICs <muurkha>I'm guessing it does something relatively peripheral but I don't know yet <muurkha>I wouldn't be surprised if you could convert the SeRV design to a Gigatron-like design without increasing the parts count enormously <aggi>with various Z80 SoC FPGA it's a similar problem, some undocumented ICs (Adafruit) are attached to serve peripheral I/O <muurkha>a more traditional, non-bit-serial, Gigatron-like RISC-V implementation is the Pineapple One <aggi>and i don't welcome the complicated software tooling with FPGA deployments either <muurkha>I suspect the ATTiny85 is used for the serial port or the PS/2 keyboard port, because it's in the "Pluggy McPlugface" module <aggi>similar issues with Geoff's VT100, undocumented ICs to terminate VT100 with PS/2 and VGA <muurkha>I wonder if those are a result of people getting tired and giving up <muurkha>a few weeks ago I talked with a guy who did a VT52 design on an FPGA <muurkha>he reported that a big part of his footprint was the PS/2 keyboard decoding <aggi>ao486 SoC hasn't got USB... <muurkha>that includes the VGA generation as well <aggi>j-core.org turtleboard, got it, USB (not sure); yet then, tcc got no J2 ISA support <muurkha>J2? is that a descendant of the J1A? <aggi>yes, and aboriginal linux and j-core.org made considerable progress <muurkha>and GCC supports SuperH but unsurprisingly tcc doesn't <aggi>however, with SH2/4 currently this locks against GNU-toolchain <aggi>and with GNU, see above, i wouldn't intend to lock-out GNU-toolchain, of cause not, i am not willing to vendor-lock against GNU <aggi>for _technical_ reasons, GPL is fine otherwise <muurkha>the J1A is a nice simple CPU design but I haven't tried compiling C to it. I wouldn't be surprised if it was a bit of a pain, though, because it's a Forth machine <muurkha>yeah, I think there might be some difficulties in practice complying with the GPL for "gateware", but I'm not sure I really understand them <muurkha>maybe Icestorm avoids the problems, or maybe they don't really apply to FPGA realizations since the users can always load a new bitstream into their FPGA <muurkha>with respect to "getting tired and giving up" I mean that maybe people are 95% done with their homebrew computer system and then they discover that, say, the PS/2 protocol is nontrivial, or their CPU is too slow to generate VGA signals in software <aggi>all those FPGA deployments are limited, almost always, to a few dozen MHz clock frequency <muurkha>and so instead of going back to the drawing board they just patch the problem with an expedient solution that has an entire computer in it <muurkha>it depends a lot on the FPGA; I think Claire Wolf has gotten her PicoRV32 to run at 200MHz on a Xilinx FPGA <aggi>meaning then, any deployment to such system, wouldn't remain self-hosting i fear; on any such FPGA SoC i doubt any software could be compiled <muurkha>a lot of the Lattice parts really top out under 100 MHz though, and you have to work really hard on optimization to get that high <muurkha>I've compiled a lot of software on things like a 25MHz SPARC and a 12MHz 80286 <aggi>tcc-toolchain, is in the realm of being feasible, and some linux-2.4 kernel <muurkha>admittedly, when I was compiling C++ on a 25MHz SPARC, it usually took me a week to build the system from scratch <muurkha>which was my main job at that company <muurkha>I wish I could tell you the order of magnitude of line count of the software, but let's say 256 kloc <muurkha>Navarro's VT52 project seems like it might be a promising starting point for an FPGA SoC with PS/2 and VGA output; you'd have to add a CPU and RAM to it <muurkha>my experience compiling things on a 4MHz Z80 is a lot more limited. usually I was using interpreted BASIC because I didn't know assembly at the time and didn't have any high-level language compilers, or even C compilers <muurkha>but a lot of people did use Turbo Pascal on such machines, and compilation times for a source file were typically under a minute <muurkha>I did compile a fair bit of software on a VAX-11/785 (1 MIPS, but 32-bit), again with compilation times under a minute per source file <muurkha>so I feel like somewhere around 1 MIPS is where self-hosted software development in high-level languages becomes practical <muurkha>a few dozen MHz with a RISC design (usually 1 IPC) is somewhere in the range of 16-64 times faster than that <muurkha>it's a real drawback if you're using a CPU like the Z80 or 6502 that's hard to generate good code for <aggi>the argument with Z80 was Rodney Zak's book, and 40 years stability <muurkha>the 286 era (2 MIPS, say) is about when the PC mainstream switched from assembly language (and BASIC for prototypes) to C, C++, and Pascal <muurkha>hmm, how about the ARM then? it's not quite 40 years <aggi>put aside ARM for a moment: the Z80 and 68K too are interesting for another reason, which is their historical track record with scientific calculators <aggi>nowadays, the 68K series (Ti89/92) is defunct, and the sources/schematics of those weren't released to my knowledge <aggi>the Z80 series calculators from Ti are manufactured still... <muurkha>the PalmPilot and Macintosh were also 68Ks btw <aggi>yet, for those Z80 Ti84(?), some Computer Algebra System (CAS) software wasn't available <muurkha>KnightOS runs on those Z80 calculators <aggi>and the Ti84/Z80 calculators aren't opensource/free either <muurkha>I think there's an open-source CAS for Z80 calculators out there somewhere <aggi>the Gigatron TTL btw. is build upon even _older_ designs, late 1960s... Apollo Mission... <aggi>reminds me, ESA chose SPARC Leon... tcc-toolchain got no SPARC support <muurkha>also I think Oberon might have implemented a 68k backend at some point? <aggi>NASA jumped onto RISC-V recently <muurkha>have you looked at Wirth's RISC, btw? the one he designed for Oberon <muurkha>it's very, very simple. even simpler than RISC-V <muurkha>yeah, apparently Oberon does have a 68K backend. also PowerPC, and lkcl is working on getting OpenPOWER shipped <aggi>yep; that's another problem, to fit any SoC onto a decent priced FPGA <muurkha>well, as I said, SeRV fits into a fraction of Lattice's smallest FPGA <aggi>and it is noteworthy, the Z80 Ti84 series remained, while 68k TI92 terminated <muurkha>the ARM 2 was the first one they really shipped, and that was in 01986. so you could sort of argue that it has "36 years" of stability <muurkha>but I'm not actually sure that ARM 2 code will run on a modern ARM 7 (or ARM 6 like the Raspberry Pi) <aggi>OK, and too i noticed opencores.org documents some early ARM designs <aggi>nonetheless, the entire system integration of a full SoC including any operating system... what's the final result? <muurkha>oh, that's cool! yeah, surely any ARM architecture from before 02002 is patent-free <muurkha>(though definitely you could use patented inventions in a microarchitecture that implements that patent-free architecture) <muurkha>what do you mean about the final result? <aggi>let's define some criteria first: tcc-toolchain support? linux-2.x? USB, VGA? RAM? some shallow first notes <aggi>will the system be capable to run a TCP/IP stack? <aggi>will it remain self-hosting? <aggi>for example, ao486... no ethernet, no usb, OK, no problem, if this would be the final result <aggi>however, i want to know before investing months and years of work <aggi>good hint, with Gigatron TTL, it contains some undocumented IC for PS2/VGA... i'll not buy that <muurkha>it might be possible to replace the ATtiny85 <muurkha>you can run a TCP/IP stack on just about anything; Contiki has wedged it into truly astonishing places, including, as I mentioned above, a Commodore PET <muurkha>you can definitely run Linux on many ARM32s. not sure if it's ever been ported to RV32, and the RV64 port is recentish <aggi>a known deployment of Linux-68k onto (Altera) FPGA is documented; tcc got no 68k support <muurkha>I may switch my laptop from Ubuntu to Debian Sid in order to make it easy to install libraries for cross-compilation <sam_>it's even easier with gentoo :P <muurkha>Ubuntu only has three architectures, Sid has 14 <sam_>arch does not have particularly wide arch support (or in general, support for "interesting things")_ <aggi>as far as system-integration (with the typical GNU) is concerned, gentoo is the most capable one <muurkha>though to be fair those 14 architectures are all amd64, arm64, arm, i386, mips, mips64, powerpc, ppc64, or s390x <muurkha>plus big-endian and Hurd and FreeBSD variants <muurkha>in particular Debian no longer exists on 68k though <muurkha>and I think maybe it's been dropped from Linux too? <muurkha>USB is a huge pain and maybe not necessary for basic usability <aggi>j-core.org mentioned USB1.x max <muurkha>VGA is sort of a pain because it requires tight timing <muurkha>pcc or lcc might be an alternative to tcc for some architectures <aggi>usb1.x too is documented with opencores.org, and whatever else j-core.org did <aggi>muurkha: tcc is a complete toolchain, not only compiler <sam_>no, gentoo does m68k still, and it still works on linux in general <sam_>(we also still have hppa, and had superh until recently (but our HW died)) <muurkha>Linux on ARM was originally a port to the ARM2 I think <sam_>superh was kind of weird because like.. nobody seemed to be interesed in it at all <sam_>we had 1 guy and he got bored of it <sam_>the nice thing about gentoo is it's very easy to port something to it and bring it back if interested <aggi>i recommend to cross-check which architectures tcc-toolchain supports <muurkha>but for other low-complexity CPUs it might be easier to use NetBSD rather than Linux to get a POSIX <muurkha>and hppa, itanic, and vax, though none of those is a reasonable option for "low-complexity CPUs" <aggi>the same criteria, gcc47 and tcc remain with NetBSD <aggi>didn't *BSD switch to LLVM already? <muurkha>I think so, but I think you can still build them with GCC if you want <muurkha>and I think they too are C++-free, if that's a thing you want <aggi>i won't accept LLVM, and intend to fully detangle GNU-toolchain too <aggi>on the linux-side, that's kernel-2.4 verified with tcc <muurkha>yeah, I don't think anyone has tccbooted a BSD yet <aggi>and any architecture tcc _and_ kernel-2.4 support <muurkha>but gcc does support 68k, sh3, hppa, itanic, and I think even vax <aggi>nothing wrong with gcc, it's just, I am not willing to accept this type of software anymore <muurkha>what do you think about pcc and lcc? <muurkha>pcc has been revived but lost a bit of momentum since the shift of the BSDs to LLVM <aggi>i do know, OpenBSD did verify pcc-x86 15 years ago <aggi>not sure if they used any of the GNU binutils, i won't <aggi>i can't have a look at configure.ac anymore without drinking vodka <aggi>i won't accept GNU autotools/automake anymore either <aggi>the perl-5.8 story of today... see above <muurkha>oh, it's just the build system? I was thinking maybe you hated BFD or thought the CVE history was unacceptably dirty <aggi>buildsystem, compiler/toolchain, non-POSIX bashism, python clutter inside buildsystem, c++ dependencies in the earliest bootloader parts <muurkha>I mean, the build system is certainly nontrivial <muurkha>but it's not the same order of magnitude to replace GNU binutils's build system as it would be to replace binutils itself (though, yes, I know tcc doesn't depend on binutils) <aggi>suckless.org shows, how it's done, to ship some makefile and config.h <muurkha>is your objection to Python the circular dependency or is it something about the Python language itself? <aggi>Python bootstrapping is problematic (and currently _impossible with tcc-toolchain) <aggi>i am not obsessed with tcc-toolchain itself, it's just revealing some dirt as a side effect <aggi>and, tcc-toolchain, is practically, usefull <aggi>furthmore, Python as BDEP creepts into where it doesn't belong, certainly it doesn't belong into the earliest boot-loader parts anywhere, neither as RDEP nor BDEP <aggi>same problem with C++; it does not belong into early bootstrapping paths <muurkha>with regard to Ethernet I think 10BaseT signaling is relatively simple. the wire encoding is just manchester encoding <aggi>i think all BSD and Gentoo distinguish this appropriately <muurkha>yeah, Debian does too, just doesn't use the "RDEP"/"BDEP" terminology <aggi>anyway, NetBSD, probably not; and this is the important difference <muurkha>I think it's good to get away from writing your build system in low-level languages like C pretty early <aggi>TCCBOOT was verified with linux-2.4 <muurkha>because it reduces both the bug-proneness and the volume of the code you're writing <muurkha>which makes the bootstrap path easier to audit <mihi>hello stikonas :) I see you found out egrep to be the culprit :) Re GNULIBDIR: I see you already import gnulib into many sources, so probably it is just a question of pointing GNULIBDIR to where gnulib lives :) <mihi>btw did you make any progress in looking for generated files? <muurkha>I still haven't written a compiler targeting RISC-V unfortunately. but from the RISC-V assembly I've written so far it seems like it is a pretty pleasant architecture to compile to <stikonas>mihi: not much progress loogking for generated files yet <stikonas>yesterday was mostly familiarizing with how it works and trying to run it <muurkha>a little less to write assembly for, much less to hand-write machine code for <stikonas>yes, writing hex0 code for risc-v is hard due to encoding of immediates <stikonas>once you have hex1 (which is as large as hex2 on x86), at least part of that problem goes away but there is still a problem of encoding immediate constants which doesn't go away until you build M0 for risc-v <stikonas>mihi: I'm also thinking, maybe we should add a mode where bootstrap.sh script exists after it builds stage1 bootstrap binaries, so then the user can do normal build with a bit more control, what do you think? Shouldn't be too hard, just an if an exit <stikonas>I also need to submit another PR to update bootstrap-tarball.sh script with those --std=gnu99 flags <stikonas>which I tested yesterday in tarball bootstrap mode <mihi>another option would be extracting bootstrap-stage0 into its own script and calling it from the other scripts. But "if and exit" is also fine. <muurkha>apparently NetBSD has C++ in an unwinder in its kernel now <muurkha>but it probably isn't necessary for normal use <aggi>that's on optional rdep, with llvm c++ is a bdep of *BSD <aggi>even this, a kernel with c++, may be acceptable, if, and only if, a kernel _without_ any c++ dependency remained somewhere <muurkha>I was thinking you might be able to compile netbsd with tcc, pcc, or lcc <aggi>ok. just remember the pain it was to rebase patches against linux-kernel to support rock64/pro64 <aggi>there wasn't any clean mainline-integration for the hardware i am working with, and that's annoying <aggi>if i had to re-base/re-implement any hardware support with NetBSD, depends on the hardware chosen <aggi>the reasoning with linux-2.4 too would be this, to nail-down this one with tcc-toolchain, and ignore any hardware which isn't supported <stikonas>mihi: hmm, yes, extracting into another script might be cleaner <muurkha> https://en.wikibooks.org/wiki/Oberon/compilers says Oberon's past backend compilers included ns32000, arm, something called OLGA, i386, mips, 68k, sparc, power, ppc, hppa, the OMI slim binary format, alpha, .net (CIL), and a couple of other things I don't think are actual hardware <muurkha>but currently it only supports i386, ppc, and sparc, not even arm or wirth-risc <muurkha>it would be more interesting if someone grafted a C frontend onto it <mihi>C because of the syntax or because of the unsafe memory operations possible? <aggi>mihi: "memory-safety" is a compiler-feature (let's say some runtime-instrumentation injected by the compiler); i would say it's not a language feature of C or any other close-to-hardware <mihi>I was referring to what C# or Oberon calls unsafe, i.e. pointer arithmetic without bounds checking, or type casts that are not type-checked at runtime. <mihi>and Oberon is definitely less close-to-hardware than C or Rust. <mihi>and yes muurkha, I am not aware of anyone having ported OP2 to Wirth RISC; there is "only" the single-pass Oberon compiler written by Wirth available for that platform as far as I know. <mihi>(and there is oberon-retro-compiler targeting Wirth RISC, which supports a subset of OP2's features) <mihi>in comparison, OP2 is "the gcc" of Oberon world (lots of features and targets, but the most bloated one) while yet orders of magnitude smaller than gcc of course. <muurkha>mihi: C because then you could use it to compile existing software written in C, such as tcc <muurkha>Oberon does have a module for accessing arbitrary memory addresses, necessary for device drivers <muurkha>I don't know anything about oberon-retro-compiler and I wonder why Wirth's single-pass compiler isn't in this table <mihi>I know of SYSTEM module, it contains all the "unsafe" stuff. It is just that in C code that is the default. <stikonas>this adds GUILE_VERSION env variable and a few other fixes <doras>stikonas: I'd like to add ldd given that musl would have dynamic linking support. Do you think it makes sense to add it to the existing PR adding dynamic linking support for musl, or should I create a new one that depends on it? <doras>ldd in the musl world is just a symlink to musl's dynamic linker. <stikonas>I've seen it before that ldd is just symlinks, so that's certainly fine <doras>I'll run one more bootstrap before uploading a new revision for the musl dynamic linking support. <stikonas>there is a 256 element of array with entries 0, 1, 2, ... , 255 and all manually entered <doras>stikonas: can you recall the reason to attempt to build GCC 10 or so first and not a newer version? <doras>I guess this might be part of the reason: "A compiler with support for C++11 language features is required." <mihi>stikonas, probably to make you think it actually contains all entries. It does not (it does not include uppercase letters). Or maybe for systems where the source encoding is not ASCII? But then the table would not make sense either. <mihi>Or somebody believed that mmap'ing 256 bytes is faster than a loop to initialize the array (there are many questionable "optimizations" hidden in Autogen. Probably the compiler does it better than the Autogen author anyway). <stikonas>mihi: so far I've checked columns and getdefs (the easy ones I guess), seems good so far <stikonas>well, that table has 8 columns and 32 rows, so that's 255 <stikonas>but yes, it seems that capital letters are actually in the place where lowercase letters would be... <stikonas>still, that's way less readable than direct comparisons... <stikonas>maybe tiny bit faster to execute but it's not like autogen is on the critical path <stikonas>doras: I think GCC 11 needs newer C standard <stikonas>still if it works, jump from 4.7.4 to GCC 10 would be fairly good <stikonas>doras: but I would really prefer (and I think fossy too) to first get autogen in <stikonas>that will simplify build script a bit (which is fairly messy) <mihi>building lookup tables for every trivial state machine or trying to save a few symbols (?) by indexing constants from a long string literal are in the same league. Even if you are using autogen as CGI scripting language, your Guile scripts will be the limiting factor and not the state machines. <stikonas>anyway, I'm unlikely to finish checking autogen itself today, but made some progress