<fossy>hey guys what's the issue with psyntax.pp? <fossy>AFAICT guile 2.0.14 dosen't have the binary so can't we just use guile 2.0.14 to bootstrap 2.2.0's psyntax-pp.go and go from there? <damo22>does mes currently rely on having a running gnu/linux system? <damo22>im interested in how mes could be used in a coreboot payload as a rescue mechanism from bare metal <bauen1>damo22: as far as i know mes (and the stage0 bootstrap) currently rely on having a unix-like kernel (linux) <bauen1>but you don't really need any other userspace tools apart from a minimal binary seed and the source code of everything else <damo22>for example, on a system that has coreboot+seabios in flash, you could easily add another binary that can be chainloaded and selected from the seabios menu... this could enable a full system rescue without needing to have an existing machine that works <damo22>or perhaps integrate it as a grub module, which in turn can be loaded into flash on supported boards <bauen1>you can already stuff a linux kernel into an coreboot image, so with a kernel and a minimal initrd you should be able to do that <damo22>grub already has filesystem drivers <damo22>surely dependence on grub is better than having to trust a whole linux kernel + initrd? <bauen1>it depends, you'll still need a kernel at some point, the toolchain required to compile grub also isn't exactly trivial <bauen1>neither is the toolchain to compile the linux kernel <bauen1>which is why i'm building a posix-ish kernel that can be compiled by just tcc <bauen1>grub in itself is almost like a kernel, but without the benefits <damo22>wouldnt you also need to write disk drivers? <bauen1>grub has _a lot_ of disk drives, which makes it an interesting target <damo22>at some point you have a chicken/egg problem <damo22>does mes target a particular architecture only? <damo22>like the initial binary needs to be compiled for the target arch right? <damo22>i think it makes sense to have that baked into the bios <damo22>on most modern machines you have around 3-7MB of flash to play with <damo22>coreboot has a filesystem layout as well, its called CBFS, you can burn files into that and its accessible as a disk in grub <bauen1>damo22: mes doesn't exactly target a specific architecture, but you would have to "port" the initial bootstrap to your architecture <bauen1>but i haven't worked with mes / mescc / stage0 so i know little about it ***ChanServ sets mode: +o rekado
<bauen1>and i finally managed to load elf files :) <dddddd>M1.scm now correctly represents negative numbers in the output. <dddddd>Now, let's see what's happening with big numbers in octal output... <dddddd>hmm, it seems a bug in M1-macro.c instead (I was comparing results from both implementations). <dddddd>For big positive and small negative numbers, M1-macro.c gives incorrect octal representations: <dddddd>%0xFFFFFFFF -> 777777777777 (instead of 037777777777) <dddddd>!@~ are unaffected AFAICT, it's just the 32b % case. <dddddd>I'm wondering if a 64bit host mask this problem (I'm running on a 32b arch). <OriansJ>damo22: stage0 doesn't rely on posix until after the M2-Planet stage. At which point we already have a working C compiler and if bauen1 takes the time to make his kernel buildable by M2-Planet then we can just build that posix on bare metal and do a little hand assembly for a bootloader and boom: minimal bootstrap we could easily shove into a coreboot/libreboot image. <OriansJ>dddddd: the octal is probably entirely wrong as I never had the time to make it correct (as it would also have to work with hex2's octal, which requires 3chars per byte [including a leading zero] which would make it different than the standard octal input) So as nothing is currently using it we can change both rather easily to work for those who might need octal (or just strip it out entirely) <dddddd><dddddd> The other option is to remove binary/octal if we don't want to support it, because unused(?) <OriansJ> Well some architectures much better map to binary and octal <OriansJ> and supporting them is minimal effort <dddddd>"here" as in the scheme implementation, I mean. <dddddd>Most of the job is done (and not "enterely wrong" AFAICT, just that corner case). Removing it now feels weird as an option, out of the blue. <OriansJ>dddddd: I guess I'll have to fix the mescc-tools versions after you get the slow-utils version working with a few tests I can work off of <dddddd>One "test" is above, the extreme one, but it happens for > %0x7fffffff <dddddd>I'm fine removing it all if it's a burden; but reintroducing the feature(s) might be painful. <dddddd>Honestly, I don't know... Do you really consider it important? I'm getting mixed signals and don't have the general vision you have. <dddddd>BTW, note that I'm not testing it along hex2, just compating M1 implementation outputs. <dddddd>The leading zeros are in place, every output has 3/6/9/12 chars, for !@~% resp. <dddddd>The obvious candidate is stringify(), I'd say the shifting. <dddddd>... maybe not playing nice with the logical and. <dddddd>... that, and the size/signess of the integer for an odd 3 shift. <OriansJ>well octal was invented prior to the invention of the 8bit byte <OriansJ>and an (i & 0xC0) >> 6, (i & 0x38) >> 3 and (i & 0x7) should get the octal pieces out nicely <dddddd>I'm testing stringify() in isolation. <dddddd>The overall logic seems fine, mirrored in a loop; but the recursive functions gives the weird output. <OriansJ>well if the recursion is just walking down the string, switch to iteration and what ever output looks weird is the char of input you need to look closely at. <OriansJ>dddddd: strings are just arrays of chars <OriansJ>integers are just a packed set of chars <OriansJ>(i & 0xFF000000) >> 24, (i& 0xFF0000) >> 16, (i & 0xFF00) >> 8, (i & 0xFF) <dddddd>One of us is missing the point. Are you looking at the function? <dddddd>This is some signed/unsigned thing, almost sure. <dddddd>Notice that starts failing when the msb is one. <OriansJ>int stringify(char* s, int digits, int divisor, int value, int shift) <dddddd>Indeed, my bad... the working loop is using unsigned int. <OriansJ>potential sign dragging? with the bit shift? <OriansJ>probably in the return (i >> shift); <dddddd>that was in the table hours ago. <OriansJ>and if one did a return ((i >> shift) & (divisor - 1)); <OriansJ>I probably should just make it iterative <dddddd>That doesn't fix it. unsigned int is needed, I think. <dddddd>For example: unsigned int i = value;