<bauen1>theruran: yeah, iirc there was an email thread some time ago asking for a new release, and it was like "nah", people of course frequently push things that break setups :( <theruran>:( so a developer actually replied "nah" lol <oriansj>nimaje: the problem in that case is that two compilers implementing the same spec can result in different behavior or just straight up not be able to compile each other's code. <oriansj>and thank you for the hint for a more proper malloc <oriansj>theruran: if it is really that bad, I might just have to fork TCC and turn it into the previously proposed M3 idea <rickmasters>oriansj: searching IRC logs didn't turn up much on M3, could you elaborate? <unmatched-paren>because Mes is a little s l o o o o o o o o o o o o w and there's really no need to complicate the chain by diverting into Scheme <rickmasters>there isn't a line of documentation yet so it's mysterious <unmatched-paren>you'd think that you'd want to reduce the amount of extensions in a bootstrap compiler <unmatched-paren>i suppose the plan might have been to build the compiler first with gcc and then simplify it for m2 later <rickmasters>yes, mes is slow, it takes 53 hours to build itself on qemu without kvm on my machine <rickmasters>i finally broke down and deployed bare metal yesterday, it compiles in 19 minutes with -enable-kvm <rickmasters>so, my dev cycle just got sped up about by a factor of 160. i was stupid not to have used kvm sooner <rickmasters>on the other hand I've had a busy summer and bootstrapping was on the back burner any way so I just lived with it. <rickmasters>i'm now using an AWS bare metal server type m5zn.metal which is not cheap but its worth it until I can get tcc compiled <rickmasters>anyway, I really like the idea of an M3 compiler replacing mes but I can see that being a lot of work. <unmatched-paren>it'll probably be a little easier, since both are iirc strictly POSIX conforming <rickmasters>My hats off to whoever wrote the mescc.scm C compiler in scheme. someone must have been really motivated. <aggi>i considered tcc an option to verify if it is possible at all to compile kernel/userspace with any alternative compiler/toolchain (not gcc and not llvm) <unmatched-paren>It's even had GNU extensions developed specifically for it, apparently :) <aggi>from the 600 ebuilds, it is only two remaining which didn't pass with tcc: musl-libc and kernel <aggi>and the situation surrounding any libc (uclibc, musl, dietlibc etc.) is far more concerning than i expected <aggi>not because of c-compiler/toolchain, because of vendor-specific and gnu-specific ASM <unmatched-paren>Apparently the support for compiling the kernel with Clang was actually a massive project that took a while <rickmasters>not too familiar with cproc / QBE but maybe its M2 -> cproc/QBE -> tcc, just looking at what aggi has done with tcc it seems like a good target <aggi>which means, this is a battle at two frontlines: to repair/re-write most parts of the ASM inside libc, and to implement/extend any assembler <aggi>rickmasters: yes, bootstrappeble is focusing on lower level realms which preceed tcc <aggi>the closest intersection now is, the ASM issues with tcc and any libc to choose <unmatched-paren>rickmasters: QBE is a small backend compiler that's used by cproc and harec :) <aggi>what tcc had demonstrated "only": it is possible to replace c-compiler _and_ binutils/elfutils with it <aggi>which is good news for any other compiler choice to be made <rickmasters>i thought bellard built linux with tcc, i'm looking for the link <aggi>i too began hacking linux-5.10 already, and had seen alot of objects emitted from arm64-tcc... just saying <aggi>however, the current show-stopper is another one: the ASM issues <aggi>because, tcc too provides LD/AR/AS... and this is what i was excited about too, to replace binutils/elfutils <aggi>which too was possible with almost all of the 600 ebuilds i tested with <aggi>however... libc and the vendor-specific and gnu-specific ASM syntax... that's the current issue <aggi>because, i consider the initial verification with tcc CC/LD/AR successfull already, which too means any other decent implementation (cproc or whatever else) may succeed <aggi>instead, i consider the ASM-related issues almost impossible to resolve <rickmasters>unmatched-paren: yes, it was tccboot building 2.4.26 but looking at the README again I see it was not a proper bootstrap anyway <rickmasters>aggi: to clarify, are you saying your tcc package builds require a pre-built libc and all usable libc's use an ASM that only, what, gcc supports? <aggi>tccboot/README: "unsupported assembly directives: .rept, .endr, .subsection" ... <aggi>rickmasters: i say the C-compiler issue can be considered almost resolved with tcc <aggi>and the ASM problem is almost impossible to repair, AS isn't implemented by gcc either, it's the GNU binutils <aggi>and _all_ libc variants i checked quickly yesterday (musl, uclibc-ng, dietlibc) are cluttered with alot of ASM which tcc assembler cannot digest <aggi>so, it really depends on the project requirements, and allthough i consider tcc-toolchain verification successfull <aggi>i consider ASM support a total failure <rickmasters>aggi: thanks. ASM support is a total failure of what? <aggi>this will be very much work, to re-write many ASM parts inside any of the libc, and too re-implementing ASM support with tcc (or any other non-binutils assembler) <aggi>rickmasters: i am not aware of any alternative assembler implementation, and the implementation from tcc failed with _all_ libc i quickly tested <rickmasters>aggi: sorry for the stupid questions: so all those libc variables use GNU Assembler syntax (gas)? <aggi>rickmasters: i am not a compiler developement expert nor ASM hacker, i don't know what type of vendor-specific and gnu-specific extensions it is <aggi>i too quickly tested i386-tcc assmbler to digest one or another asm file from the libc ... didn't look promising <rickmasters>unmatched-paren: thanks, that was my next question, re: POSIX <aggi>my argument is this: it is absolutely OK to rely on binutils; however, i do insist on any alternative to binutils NOT being locked out <aggi>too tcc-assembler (for any architecture it supports) is a neat verification if it is possible, for example, if it passes with tcc CC|LD and AS(!) <unmatched-paren>if they were specified by the arch, they would be wildly different for each one <unmatched-paren>And POSIX can't specify pseudoinstructions because it can't make assumptions about binary formats, I guess <unmatched-paren>The only thing it could possibly specify is the surface format of instructions <aggi>and that's why, i will freeze the project, and terminate my work. <aggi>meaning, the gcc47 c-only toolchain system profile with 600 ebuilds is finished, too the tcc-toolchain did pass compile-time and some quick runtime-test inside a chroot <aggi>i'll archive this, and quit working on it <aggi>simply because, i consider the ASM problem not feasible to resolve with reasonable efforts <rickmasters>aggi: what are your assembler requirements? it can't be GNU Assembler, it must start from scratch? And support multiple architectures? <aggi>rickmasters: this is the approach i had taken CC=arm-tcc LD=arm-tcc AR=arm-tcc-ar AS=arm-tcc <unmatched-paren>I suppose since .s is a nonstandard format there's nothing you can really use other than gas <aggi>of cause, if there is any suggestion for AS=??? which is NOT binutils (or anything from llvm) <aggi>i simply consider AS=arm-tcc the best bet because CC|LD|AR=arm-tcc did pass with the entire _userspace_ already (except kernel and musl-libc) <aggi>it is a battle at two frontlines: to re-write ASM inside any of the libc (currently i chose musl-libc), and too extending/re-writing the assembler inside of tcc (or any other alternative, i don't know any) <aggi>and, it is a battle at two frontlines, for many different architectures <aggi>unmatched-paren: i do not know <unmatched-paren>If it isn't, then any attempt to use it was probably doomed from the start <aggi>btw. arm64-tcc hasn't got any asm support implemented yet at all to my knowledge <aggi>just as said, i do not object to relying on GNU gas, i object to the fact any alternative is locked-out, such as arm-tcc assembler <rickmasters>aggi: sorry, could you clarify locked-out? do you mean the maintainers won't accept another assembly syntax, like a new psuedo-architecture when one already exists? <unmatched-paren>aggi: Strange that the aN and vN notations for arm32 didn't work in tcc-as <aggi>rickmasters: with locked-out i mean i did not succed with feeding various arm/<aarch32-asm>.s files from musl-libc into arm-tcc assembler <aggi>arm-tcc freaked out all over the place <aggi>however i am no expert with ASM hacking, i only suspect it is _not_ tinycc assembler at fault <aggi>instead, i think various vendors and GNU locked out any alternative such as tcc <rickmasters>well, it just sounds like arm-tcc picked a different assembler syntax than gas <aggi>whatever it is, i consider it a total failure <unmatched-paren>but since it's basically impossible to standardize assemblers, it's pretty hard to make them equivalent, i guess <unmatched-paren>aggi: Eh, that's a little harsh. It was never intended for bootstrapping. <aggi>i can't drink as much as i wanted to puke over it, sorry. <aggi>and even if i wanted to practice ASM hacking, which i want to btw., i wouldn't pick anything related to GNU <aggi>for example, Rodney Zak programming Z80 book, published 40years ago, seems rather stable <aggi>Gigatron TTL offers some documentation for their native assembly language and gigatron control language, another candidate <rickmasters>not sure if stikonas is around, but it looks like live-bootstrap compiles musl with tcc so I'm wondering how bad can it be? <rickmasters>I believe he mentioned that recently, but I don't remember the details <aggi>and i chose aarch32, not x86/64 <stikonas>it wasn't too bad building musl with tcc <stikonas>well, we can check regarding patches to tcc <stikonas>yes, but musl is not that assembly heavy <aggi>i did a quick find/grep '\.s' inside src-dir only, and decided to quit, aarch32, it's beyond my abilities <aggi>and even if i wanted to dig inside asm hacking, i won't do it with aarch32 <stikonas>tcc weak symbol support is quite bad, so had to use ugly hack <rickmasters>looks like aggi needs tcc to handle the arm 32 bit assembly in musl? <aggi>nope, just as said, i'll freeze the project, and i will terminate. this decision is made. <aggi>even then, because integrating tcc-toolchain revealed that much dirt, i had not seen before <aggi>and then, i had to migrate the packaging from portage to another package manager... alot of work <aggi>it's feasible, but _not_ worth the effort anymore <rickmasters>yeah, its not a tcc world, maybe that closed the book for you <aggi>no, tcc-toolchain was only a verification, which, just as said, succeeded. <aggi>and i had been working 70hours/week for almost a year <aggi>of cause, i'll not delete what i got here, i'll freeze it, and terminate. <aggi>the moment when, i opened developer.arm.com with w3m browser, to gather documentation there... <rickmasters>so its the GNU world and other entrenched solutions that you don't agree with that would be too much work to continue? <aggi>it's not worth the effort anymore <aggi>i already had to block at gcc47, which is 10years old, doesn't support aarch64, and isn't sufficiently stabilized either imo <aggi>and blocking perl to a version from year 2005... <aggi>i'll just freeze. and quit. <rickmasters>I hope you understand that I am just trying to understand, as someone who hasn't followed closely, what you're ideal end game was and how you got here... <rickmasters>it sounds like you wanted an arm 32 bit linux distro with common packages and less GNU stuff and other stuff like not portage and so fort? <aggi>how should i explain... i could happily live with a Ti92 calculator, if it was opensource with schematics and source-code available <aggi>and i think, precious development man-power shouldn't be wasted <aggi>for example, aarch32, just recently there was rumors ARMv9 will abandon aarch32 compatibility <aggi>i patched linux-5.10 already to pass with gcc47, meanwhile linux-5.15 announced they had bumped compiler-version requirements, AGAIN, who knows what they did <aggi>and i am not willing to switch to ia32/amd64 either... the BIOS/UEFI/firmware situation there is unacceptable <rickmasters>were you working towards a reasonably stable and technically sensible software platform that you could work on top of and invest development in? ... just trying to understand <aggi>yes. however certainly i am not the only one who did. <rickmasters>i mean, i think that you have some of the same principles and goals that bring people here - trying to rebuild a more sensible path of build tools <rickmasters>but the monster is 70 years old or so, glommed together over millions of man years. its a long game and every contribution helps so thank you for deciding to archive your work <aggi>the system-integration with gentoo-tooling is relatively clean, and reproducible, with log-files for almost everything <aggi>the gcc47 c-only toolchain profile can compile/cross-compile/gcc-upgrade into any direction desired <aggi>the tcc-toolchain build doesn't contain a package manager anymore, because i decided to drop python with tcc-toolchain <aggi>anyway, 70hours/week, more than 1year <rickmasters>so do you call the project you have been working on "tcc-toolchain" and runs from a set of gentoo derived tools (with portage removed)? <aggi>i began with sanitizing the entire profile with full removal of all c++ dependencies <aggi>re-integrated gcc47/binutils-2.22 toolchain, stabilized the compilation/cross-compilation/upgrade paths <aggi>and with this setup, i tested tcc-toolchain integration recently <aggi>except for musl-libc it seems possible to compile more than 500 ebuilds (which contain almost everything desireable with a linux system) <aggi>and this is what i'll freeze <aggi>tcc-toolchain, another discussion, because although 99.9% of builds suceeded, it is those 0.01% remaining which conceptually contradict the whole idea <aggi>to remove GNU-toolchain (gcc,binutils) <aggi>and it's two discussions remaining: linux kernel and libc <rickmasters>thanks, it sounds like a really worthwhile effort, even if it didn't get to 100% <aggi>because i consider the situation surrounding ASM, a failure <stikonas>assemblers are fairly easy, M0 is 2 KiB binary <aggi>ok. if you accept the premise i had to follow with aarch32, it's not worth the effort anymore <aggi>for other, practical reasons: which is long-term reliable hardware supply for example <aggi>currently i am using some rock64 SBC, which require an aarch64 uboot/kernel, on top of which i worked with an aarch32 userspace <aggi>i don't want to discuss all details of this scenario, nonetheless i fear aarch32 is a dead-end, to invest years of work into <aggi>one hint: ARMv9 rumors were they decided to drop aarch32 compat... and tcc hasn't got arm64 assembly support <aggi>meaning, even if i invested another year of work, it's not worth the effort anymore <aggi>and i consider the whole BIOS/UEFI/firmware situation in ia32/amd64 territory unacceptable <aggi>besides those two, ARM/64 and X86/64 i am not aware of any other practicually useful platform to work with <aggi>maybe SPARC/64 (SPARC leon was chosen by European Space Agency), however, tcc hasn't got SPARC support iirc <aggi>reminds me someone mentioned Pineapple One (RISC-V), i would be cautious, since i am not aware gcc47 supported RISC-V <aggi>and i fear, RISC-V will require recent linux-kernel versions, those kernel versions which aggressively bumped compiler versin requirements <aggi>rickmasters: armv8a can, rumors were armv9 will drop aarch32 compat <aggi>which isn't an issue yet, not yet, however in a few years it will be, if you had to dumpster dive for some armv8 SBC <aggi>ARMv7 SBC are almost gone already <vagrantc>rickmasters: some can, some can't, it's hardware-specific <vagrantc>rickmasters: 32-bit support is optional in armv8, not all processors support it <vagrantc>(technically, there are 32-bit armv8, but that's pretty much just theoretical) <unmatched-paren>Wouldn't sticking to an old Linux that requires a less recent gcc/clang be a terrible idea for security, anyway? <aggi>no. but with older kernel versions you'll be locked out with hardware support quickly <aggi>then you got a kernel, but no hardware anymore <aggi>or, in case of Pineapple One (RISC-V), chances are you'll need a most recent kernel-version which cannot be compiled with an alternative compiler such as tcc <aggi>to compiler kernel-5.10 with gcc47 was some dirty hackjob already, and linux bumped compiler-version requirements since then AGAIN <aggi>this is what i mean with locked-out <aggi>with ia32 i would accept the following, if an ia32 system could be deployed to FPGA, including USB1 and VGA and ethernet, and used as development system <aggi>the ia32 FPGA deployments i had seen seemd inconclusive with their specs (USB1? ethernet? i wouldn't want to work without this) <rickmasters>I feel for you aggi. I'm currently developing in x86 32-bit with BIOS dependency but I tell myself that at least qemu will support that long enough <aggi>and those ia32 FPGA are _slow_ <aggi>and yes, the ia32 FPGA deployments used opensource BIOS (seabios, bochs or something)... <rickmasters>its a compromise because BIOS may disappear in my lifetime but it works for now <rickmasters>if intel/AMD started talking about dropping 32 bit support I'd have to seriously question my efforts <unmatched-paren>rickmasters: I doubt that will happen until maybe 2030. There are probably still far, far too many 32-bit only windows applications, and they don't want to upset Lord Microsoft. <aggi>i question mine because of the BIOS/UEFI situation with x86/amd64 <rickmasters>how does aarch32 differ in terms of a BIOS/UEFI interface? <aggi>well, u-boot loader is opensource/free, too the ATF sources are available, at least <aggi>i wont accept any UEFI at all anywhere <aggi>hence i had to slightly re-work the firmware layout and boot-procedure here, just a side note, it's still possible to wipe all UEFI <aggi>on x86/amd64 i blocked at an older syslinux version, which hasn't got any UEFI support, for the sake of it <aggi>theruran: good to know. thanks. by coincidence would you know which kernel-versions supported the Pineapple One RISC-V system (or any other recent RISC-V SBC)? <rickmasters>aggi: what part of UEFI (and BIOS) is not acceptable? I only ask because I can think of many <aggi>rickmasters: short answer, all of it isn't acceptable. <aggi>with the exception of seabios/bochs <stikonas>how is seabios different from tianocore? <stikonas>if one is acceptable, why the other isn't? <stikonas>yes, API that they implement are different <aggi>i question the entire design-rationale of UEFI, in principle <stikonas>but in principle it does the same stuff as BIOS, does input/ouput <aggi>one hint: BIOS image size fits into who knows, 64KiB of RAM? how much ROM/RAM does a UEFI firmware need? <stikonas>well yes, I agree that UEFI is much bigger <aggi>furthremore, UEFI didn't abandon, and shouldn't abandon legacy BIOS anyway <aggi>furthremore, legacy BIOS, with ACPI and related, was bad enough already <aggi>side note: for a while i hacked inside coreboot to repair support for some Phenom2 board... never again. <stikonas>well, coreboot is a layer under BIOS/UEFI <stikonas>whereas BIOS/UEFI corresponds to U-Boot proper <aggi>besides, kernel and BIOS duplicate various hw-init and driver support, which is another hint, of the conceptual problems <aggi>ACPI is another reason, to stay away from x86/amd64 as far away as possible <aggi>i remember, older x86/64 systems at least could offer SMP without ACPI... <aggi>similar situation with aarch32/64, who implement some hacks inside their ATF to provide SMP <aggi>stumbled upon this, because i wanted to boot an aarch32 kernel on top of an aarch64 uboot-loader, which i proceeded with <aggi>up until i noticed PSCI (an ACPI equivalent) was absent then, SMP gone, RAM clocked at a few MHz only then, and CPU core at lowest clock speed <aggi>aarch32 kernel, because tcc is limited with aarch64 (no asm support for this yet), and gcc47 hasn't got aarch64 support either <aggi>situation with ia32/amd64 isnt any different <aggi>the ia32 FPGA deployments with bochs/seabios seem very interesting, however FPGA capable of an ia32 deployment are _expensive_ <stikonas>hmm, double of at least some stuff initialization is probably unavoidable. The question is how much hw we initialize <aggi>the altera board i had seen: ~800$... and it would be capable of an ia32 clocked at a few dozen MHz only, insufficient for regular linux/foss development <stikonas>if you want to have a bootloader, you need ot initialize some hw <oriansj>well it is entirely possible to define a universal assembly language. It wouldn't even be hard; just getting people to actually use it however seems unlikely ***chexum_ is now known as chexum
<aggi>the Gigatron TTL shipped for $150, both gigatron native assembly and the gigatron control language seemed documented <aggi>to they implemented MOS6502 ASM emulation; didn't study this in detail yet <aggi>with Z80 i appreciate it's somewhat stable now, for 40 years <aggi>not sure what Rodney Zak "programming z80" covers, if asm hacking is sufficiently lectured with it <aggi>the beauty of gigatron, the ttl7400 series parts can be soldered onto a breadboard <aggi>it got single step debugger, a Z80 with SRAM too can be single-stepped <aggi>with Z80 i fear, parts supply could be problematic, dumpster diving necessary, to desolder old chips (various peripheral I/O for parallel and serial port, various chips, not sure what's available) <aggi>motorola 68K (used inside closed-source and abandoned Ti89/Ti92 series calculators) too are problematic, to source parts... dumpster diving <aggi>even NASA reported, they had to dumpster dive for i8086 era parts on ebay, for their Space Shuttle <aggi>General Electric reported, they had trouble hiring PDP-11 era hacker skills, for their nuclear facilities... <aggi>with hardware deployed onto FPGA, i remain sceptical, it's a nice-to-have, even with open-source software tooling available <aggi>i am not willing to depend on IBM Wintel Computers with Altera Studio or Xilinx IDE, Lattice got some offerings open-source <aggi>FPGA is expensive, Altera $800, Gigatron TTL 150 coins, a full Z80 system (Zeta V2 or some other S-100 BUS system) is more expensive than the gigatron too <aggi>with Gigatron TTL, the developer of the v1.0 ROM died, could be a problem too, in case of questions arise <aggi>with Z80, the east-german manufacturing (Robotron, and Erfurt Semiconductors) are defunct since 1990, to my knowledge it's dead. <oriansj>unmatched-paren: well it doesn't even need to be an intermediate language, it can be a 1:1 mapping to native assembly. eg LOAD8U R0::15:8 <- R1::31:0[8] which would map to mov ah, [ebx+8]; but wouldn't have a mapping on say MIPS but the syntax would still be the same for say LOAD32U R0::31:0 <- R1::31:0[8] and most architectures would have a 1:1 mapping