***stikonas_ is now known as stikonas
<OriansJ`>No comments on the armv7l cc_x86.S? no recommendations? no suggestions for improvement? instructions which the assembler will quietly change to something entirely different? <fossy>i read over it, it looks fine but i am not really an assembly person <OriansJ`>mostly I am finding that it is not actually possible to encode the loading of 577 directly as it can not be expressed in 8bits, nor with 8bit value shifted; thus the assembler quietly replaced it with a thumb2 instruction that isn't valid on all armv7l systems. <OriansJ`>now 576 can be encoded in 8bits with a 4bit shift and the thumb instruction loads it and then incrememts <OriansJ`>tstmi r2, r3, ror 1 but objdump -d shows: movw r1, #577 <OriansJ`>So I am stuck with either the documentation is right or the assembler is right or the disassembler is right. because all three disagree with each other. <OriansJ`>and this is only 10 instructions into converting into M1 <OriansJ`>as RASM2 is spot on with the documentation; objdump is interpreting as movw and gnu assembler states it is a thumb2 optimization. So someone is right and everyone else is wrong <xentrac>what if it varies depending on the hardware? <OriansJ`>xentrac: then I have to do something insanely ugly to load 577 into a register on all armv7l systems <OriansJ`>because M1 has a 1:1 correspondence with binary output regardless of hardware or operating system. <OriansJ`>and it has to have the EXACT same behavior on ALL armv7l systems <OriansJ`>if even one armv7l system doesn't work right with a given encoding, I can't use it. <OriansJ`>So all of the armv7l ugly special cases need to be avoided so that cc_armv7l.S runs on all armv7l hosts (assuming the malloc, fgetc and fputc functions are adjusted according to the operating system or lack there of used) <OriansJ`>it is why I didn't use the floating point division route because I needed to work on systems without SIMD or FPUs <OriansJ`>minus a handful of logical operators, it is just: load immediates, load memory, store memory, add, compare, push, pop and a handful of branching instructions. <OriansJ`>now in theory even though I am calling it armv7l, it should also work on 90ish of all armv6 processors as well <OriansJ`>because it turns out some of them don't support blx or multiply; which is crazy. <OriansJ`>Not as bad as the armv5 vs armv6 crazy but pretty bad <OriansJ`>is ARMv8 but it also doesn't support multiply <OriansJ`>Armv7-M and Armv7E-M architectures always include divide instructions but Armv7-R might in thumb instructions and Armv7-A optionally in virtualization extensions???? (Hence the rolling of a division function) <OriansJ`>I guess, I got spoiled by x86 where turing core instructions are always there in every single processor; even the weird third party chips like via or cyrix or even FPGA cores. <OriansJ`>and heaven help you if you set condition bit 9. As you will crash the kernel. <OriansJ`>as you have just set all data to big endian and the kernel has you preserve your condition codes in memory prior to reseting the register to something sane; otherwise it will not be preserved across syscalls. <OriansJ`>and on some optimized kernel trees, they skip that step and get damn near instant kernel panics as all of the bytes in the words the CPU was reading are now flipped into big endian format on load or bit 24; then the cpu will assume kernel instructions are java bytecodes and take a hard dump. <OriansJ`>Registers R0 through R7 and the condition register are the same across all CPU modes; they are never banked. <OriansJ`>Registers R8 through R12 are the same across all CPU modes except FIQ mode. FIQ mode has its own distinct R8 through R12 registers. <OriansJ`>R13 and R14 are banked across all privileged CPU modes except system mode <OriansJ`>plus it isn't possible to directly push or pop the condition register on the stack and the condition register and the "do not modify bits" are an absolute mess across implementations <xentrac>division isn't as big a loss as multiply, just because hardware divide is still slow <OriansJ`>it also is architecture and host neutral; reproducible and deterministic. eg every binary produced is always 100% bit for bit identical when given the same source code. <OriansJ`>xentrac: the standard load/store, arithmetic/logic, comparision and call/jump functions. multiply wouldn't be a big loss either; it is even simpler to implement than division and for terms of 16 and below make for shallow loops. But the lack of consistency in arm standards makes for land mines in bootstrapping. if someone had done this work back in armv4, they would be saying: "what do you mean core instructions were removed or got new <OriansJ`>literally not a single binary from armv4 will work correctly on an armv5/6/7/8 system <yanmaani>OriansJ`: Doesn't that make scheme unsuitable for bootstrapping? <yanmaani>Wouldn't it make more sense to try and build tcc with cc_x86? <stikonas>yanmaani: tcc is built with mescc which doesn't need guile and guix <stikonas>(easy automation would of course be a plus but I don't think it warrants to say that scheme is unsuitable) <yanmaani>stikonas: Why can't you modify tcc to build with cc_x86 directly? <stikonas>I don't know. But my guess is that it would be more work <stikonas>ok, but that's a bit orthogonal to guix bootstrap anyway <stikonas>well, early bootstrap automation is done using kaem is and fairly easy to use. Hopefully, once mes-m2 is ready, tcc will be easy to bootstrap too (e.g. just by running some kaem script) <stikonas>(there is always unbootstrapped kernel in the equation too...) <stikonas>that could be true, but it's still something much bigger than stage0 bootstrap seed <yanmaani>Does stage0 bootstrap not need a kernel? <stikonas>yanmaani: x86/arm etc bootstrap on linux does need a kernel (it uses syscalls to e.g. read and write files) <stikonas>well, if it's not on linux, you need to write you own input output driver code... <stikonas>but in principle you can build some custom hardware that uses some kind of tapes... <stikonas>but I meant you can build some custom arch to run knight instruction sets <stikonas>feed in some tape, you get some tape out <yanmaani>I'm a bit confused by this. Maybe it's already covered in the FAQ, but wouldn't it make much more sense to reproducibly build and bootstrap a trillion different versions of say TinyCC? <yanmaani>yeah there's that guy who built a computer with wires <yanmaani>seems like, if you need a trusted binary kernel, it's better to have this be something small (like tOS) than something big (like linux) <stikonas>but how cna you guaranteed that all of them are not compromised <stikonas>you don't know that temple os is trusted binary kernel <yanmaani>they all have to be compromised in the same way <stikonas>you either need trusted binary kernel or trusted hardware <yanmaani>It's unlikely that the adversary would compromise MacOS 8 *and* Mac OS X *and* MS-DOS 6.22 *and* Windows XP *and* Windows 7 in the exact same way <yanmaani>I know that, but isn't it at least more secure with a smaller kernel? <stikonas>well, it's unlikely that adversary would compromise gcc, msvc, clang in exactly the same way either... <stikonas>yes, it is more secure with smaller kernel <yanmaani>Then you have say 100k of random blobs instead of 1MB <yanmaani>Can't you just cross-compile tcc and make sure it self-hosts reproducibly then? With all the obscure combinations <stikonas>yes, tha'ts true... I was just saying if you want absolutely minimum blobs, you need to work quite hard and at some point deal with hardware <yanmaani>clang on macos 8, msvc on windows xp, gcc on ms-dos. Seems improbable all of them would be compromised in the same way <stikonas>well, you can actually replace binary kernel with binary tcc... <yanmaani>stikonas: doesn't binary tcc need binary kernel still? <rain1>it is self hosted and the official ISOs were tampered with by "fans" that stole the authors passwords <rain1>so there's basically no way to know it isn't infected in some way <stikonas>I think somebody had expermented with tcc as bootloader compiling binary kernel on the fly <rain1>we can expect that they only put on a textfile about themselves and didn't infect the compiler, but still worth noting <yanmaani>rain1: There's archived copies of it etc <OriansJ`>yanmaani: 1) the cc_* do not require a kernel as indicated by the knight bare metal version implementations. 2) M2-Planet does not require a kernel and can run on bare metal (there is an example main function that hard codes a tape input and tape output. Thus if there is a kernel in C that M2-Planet can build, we can bootstrap it without needing a kernel. <OriansJ`>the idea of making a version of TCC that can compile GCC directly and be buildable by M2-Planet was discussed and is the idea of the M3 work that is currently on hold. In short, because I am doing all of the work myself, I will do it however I wish and in the order I find fun. <yanmaani>What'd need to be stripped out? Does TCC use function pointers and stuff? <rain1>did anybody manage to build any libcs with tcc? <rain1>i cant remember if musl eventually worked <yanmaani>Technically you only need to be able to compile the full TCC. Or is there some goal of minimizing the bootstrap stages? <OriansJ`>If anyone else wants to pick up the work and write a proper cross-platform ELF linker in M2-Planet or a proper cross-plaform assembler that generates elf object files. It'll save me the effort. <OriansJ`>yanmaani: in short TCC's generation of direct binaries makes future porting work harder than required. <OriansJ`>So a linker and assembler good enough to cover MesCC's assembly expectations would be enough <OriansJ`>ideally compatible with binutils in a minimal way, so that MesCC can leverage binutils to speed up their cross platform porting and will make the GCC bootstrap easier too. <OriansJ`>I figure do it right, so that we can finish this once and for all. <OriansJ`>More often then not C language abuse (specifically macros) are the primary problem with getting M2-Planet compiling a program. As it supports unions, structs, arrays, if, else, do, while, for and even inline assembly. <yanmaani>So your goal is to use M2-Planet to compile a linker? <OriansJ`>yanmaani: my goal with M2-Planet is to build what is required to bootstrap GCC with the fewest of my years spent achieving that task. <OriansJ`>Be it via mes-m2+guix or M3 with people who are willing to do the work. <yanmaani>So if tcc would have a separate linker and be buildable under m2-planet, that'd work? <OriansJ`>yanmaani: if someone is willing to get TCC to be directly buildable under M2-Planet, that would also work <OriansJ`>we could do the seperate linker and assembler later when we need to figure out the porting to new platforms <yanmaani>does m2-planet support all of C save for #define? <OriansJ`>yanmaani: not all but it includes alot of the things you would need to build anything useful in bootstrapping software. <yanmaani>But what would you need to change about tcc to make it build under m2p? <OriansJ`>and anything that it doesn't support but can be exampled in a reasonable test, I can add rather easily <OriansJ`>yanmaani: honestly it looks like a bit of C abuse mostly; even mescc had to remove some of the insanity to compile it. <OriansJ`>it is easier if you just look at its source code for a minute and then look at M2-planet's source code for a minute. <OriansJ`>or simply pass any of the files to M2-Planet and it will explicitly tell you <OriansJ`>hence why I have very little motivation to address the gaps in TCC at this exact momement and instead are dealing with the armv7l port of the bootstrap. <OriansJ`>it is just alot of work for little payoff. Yet no one else cares enough to even do the basic clearing work <OriansJ`>I already went through a similiar process trying to get mes.c buildable via M2-Planet. <OriansJ`>It took months just to get a single GCC command to compile the C source code <janneke>rain1: tcc can build the mes lib c :-P <janneke>yeah, it's used in the guix reduced binary seed bootstrap <OriansJ`>I get bitched at for not having everything on savannah, yet I don't see anyone picking up even that task. <OriansJ`>Because I really look forward to the fight of getting actual binaries approved in savannah <yanmaani>what's this mean? ./m2-planet < hello.c > a.out doesn't seem to work <yanmaani>Can't you just use the preprocessor to concatenate all the files, ensure no symbols are globally duplicated, and compile? <OriansJ`>yanmaani: the primary job of a linker is to resolve and fix references (hex2 does this just fine). The primary job of an assembler is turn human words into binary encodings (M1 does this just fine) and `Lion we have catm which unlike cat doesn't require a shell to produce useful files <yanmaani>OriansJ`: Can't you just include the libc in each input source file? <OriansJ`>you didn't look at any of the M2-Planet tests did you? <OriansJ`>The reason for the new proper linker and assembler written in M2-Planet C; is so that one could do development in gnu assembler and be able to directly build that code without having to convert it into the constraints of mescc-tools <fossy><OriansJ`> the idea of making a version of TCC that can compile GCC directly and be buildable by M2-Planet was discussed and is the idea of the M3 work that is currently on hold. In short, because I am doing all of the work myself, I will do it however I wish and in the order I find fun. <fossy>there's no point doing this if we dont find what we are doing interesting, we wont be interested in maintaining it