<bauen1>fossy: on the plus side, it should be a somewhat easier to port to other architectures since i've properly used size_t, uintptr_t where necessary, it already supports i686 and x86_64 <bauen1>fossy: it does require a multiboot bootloader, but if you can read a file, load an elf file, and setup some memory maps you will be fine, that should be easy to do from assembly too if you want <bauen1>klange actually made a simple multiboot bootloader for toaruos, which i modified slightly to load myunix v2 i believe, so yes simple enough <OriansJ>There is a very good reason why M2-Planet was designed to run on bare metal; it makes the kernel bootstrap problem so much easier. <OriansJ>6 upvotes; nice that is better coverage than we got when I hand wrote a C compiler in x86 assembly. <OriansJ>yt_: one thing we could do is enable #define statements by converting them into CONSTANT statements. Then the rule in M2-Planet is use the last defined CONSTANT as correct. <OriansJ>that way we can do #define foo 1 // CONSTANT foo sizeof(int) and it'll continue to do the correct thing <yt_>OriansJ: hmm I hadn't considered that <OriansJ>until we fix pointer arithmetic in M2-Planet and can simply drop the // CONSTANT statements <yt_>thing is, I'm about 80% there on #define XD <OriansJ>I'll try to whip together a hacky solution. <yt_>well, I say that, but I'm not. I'm about 80% on #if defined(FOO) :-) <OriansJ>well right now #define foo 1 just eats the line; which is a reasonable thing <yt_>yes, agreed, so I guess you're saying that the next step is translating #define foo 1 to CONSTANT foo 1, which sounds very reasonable to me <yt_>in the absence of proper macro expansion <yt_>then the next step would be IMO to get #if foo (or at least #if defined(foo), which is easier) working <yt_>having that could help a lot with M2libc, I'd say <OriansJ>yt_: only support the parts of C you like <OriansJ>and you are always free to be strict on your input <yt_>OriansJ: joke's on you, I'm having too much fun XD <OriansJ>wait until you see my latest commits to M2libc <OriansJ>I'll whip up a libc-full.M1 to make it work nicely once I figure out my little CONSTANT hack to get it working right <pabs3>^ LWN article about bootstrappable <yt_>PR hopefully tomorrow, if I can manage to get the tests to pass again <OriansJ>the only thing needed would be to move the // CONSTANT after the #define <yt_>would the // CONSTANT still be necessary? wouldn't the #define be enough? <OriansJ>oh in the future could you use paste.debian.net as it doesn't require javascript to view? <yt_>OriansJ: sure, no problem <OriansJ>well foo isn't a function or a type and thus wouldn't be a valid thing in the global space <yt_>ah I see what you mean now. // CONSTANT can be removed from source, but the preprocessor reinserts them in place of the #define <yt_>I think that hack can coexist with my partial implementation of #define <OriansJ>it also gives us an escape valve if we need a #define for GCC but a different value for M2-Planet #define foo 1 // CONSTANT foo sizeof(struct pointer) <OriansJ>oh my; my patch works without any code changes for any of the tests <stikonas>either at the top level or we need to add some comments to all shipped scripts... <yt_>OriansJ: M2-Planet's test1000 (the self-hosting test) gives me nightmares now XD <yt_>but this time round I managed to not use any unsupported C features, phew <OriansJ>yt_: well that is why I have to really do alot of work on --bootstrap-mode soon <yt_>OriansJ: is the idea that --bootstrap-mode matches cc_* behaviour? <OriansJ>and then we can add features and know that they didn't use them in a way that would break the bootstrap <OriansJ>yt_: short version it should throw a big fat line error when enabled on EVERY feature not in cc_* <yt_>OriansJ: that sounds very useful. I wonder how we'd handle for example the preprocessor: at the moment we rely on cc_* and M2-Planet ignoring preprocessor directives, but they do need to be in the source for gcc compilation <OriansJ>well I was just going to skip the preprocess step entirely and go back to just dropping everything after # until newline <OriansJ>or perhaps make a compatibilyt function to do just that. <yt_>OriansJ: makes sense <OriansJ>I'll hack something together later tonight to make it work in a useful fashion. <yt_>OriansJ: anyway, enough from me today. I'll have a PR tomorrow; debugging went smoothly at least! <OriansJ>god, all the string to integer functions in stdlib.h suck <xentrac>usually you can implement them all in terms of strtoq, or strtoll if you don't have that, or strtol if you don't have that <xentrac>I guess strtol doesn't give you strtoul <OriansJ>well compare it to M2-Planet's numerate_string <OriansJ>there are far better C programmers than I; so how did I write a better function that for converting a string to an int <OriansJ>M2-Planet --architecture x86 -f x86/Linux/unistd.h -f stdlib.c -f x86/Linux/fcntl.h -f stdio.c -f foo.c -o foo.M1 --debug && blood-elf -f foo.M1 -o foo-footer.M1 && M1 --architecture x86 --little-endian -f x86/x86_defs.M1 -f x86/libc-full.M1 -f foo.M1 -f foo-footer.M1 -o foo.hex2 && hex2 --architecture x86 --little-endian --base-address 0x10000 -f x86/ELF-i386-debug.hex2 -f foo.hex2 -o foo && ./foo <xentrac>well, you weren't trying to be compatible with BSD code from 1979 <OriansJ>xentrac: well GNU C Language Extensions don't have to be either <OriansJ>or the FreeBSD C Extensions like strtonum <xentrac>and, to be totally evenhanded, it can do things numerate_string can't <xentrac>and the implementation is probably about four times faster than set_reader <OriansJ>well I hate having to think about what the input is when I am expecting an int <OriansJ>I wonder if I should make a bootstrappable.h lib in M2libc to cover these sorts of pieces with more C standard names <OriansJ>so that I can pull the functions folders out of M2-Planet, mescc-tools and blynn-compiler <xentrac>do you mean to provide implementations of things like numerate_string on top of standard C library functions? you'd still have to have an implementation of numerate_string in that case, it would just be calling atoi instead of set_reader <xentrac>or implementations of things like atoi on top of things like numerate_string? <OriansJ>xentrac: or I could just leverage janneke's atoi and other stdlib primitives <xentrac>that sounds like a reasonable thing to do but I still don't understand what you mean by "cover" <OriansJ>as in create a standard library bootstrappable.h that contains functions like numerate_string <xentrac>oh, move numerate_string and friends to M2libc instead of having separate copies in the three places? <xentrac>what do you mean by "more C standard names"? fortunately we no longer have to suffer linkers that only support six significant letters for a global symbol :) <xentrac>that sounds like a reasonable thing to do to me <OriansJ>as for what I mean by more C standard names is name them something easy for a C programmer to guess <xentrac>strtoint or str_to_int or those other variations probably are clearer than numerate_string <xentrac>which is more easily interpreted as the antonym of innumerate_string <xentrac>but I think a comment in the header file is probably more important than changing the name <xentrac>I mean, once you know what it means, you probably aren't going to forget. It numberifies the string <xentrac>is that where you got it? I've never used delphi <OriansJ>but not a claimed c or c++ name; *DIBS* <OriansJ>now hopefully someone finds an improvement for M2libc's __init_io <siraben>Can't get more idiomatic haskell than `queens' n k = [x:xs | xs <- queens' n (k - 1), x <- [1..n], isSafeColumn x xs, isSafeDiagonal x xs]` <gforce_de1977>OriansJ: you should really maintain a TODO-list somewhere, even for "small" things like the M2libc's __init_io <gforce_de1977>OriansJ: maybe divided up into "small changes/big changes/ideas"... <OriansJ>Hagfish: good to see the R community starting to address those issues <OriansJ>gforce_de1977: yes I could; that would certainly point directly to known flaws, such as the lacking documentation and general disorganization of it all. However it might discourage people from trying to fix what annoys them if it isn't on the list. <fossy>janneke: is at a guix thing there? <janneke>no, i'm selecting the wrong emacs windows this morning, very sorry <fossy>what is that, i am very interested <siraben>OriansJ: i'm sure over time we'll converge on some standard doc format that describes which stage each component is for and so on <siraben>I tried to do that in blynn-compiler's readme, for instance <siraben>pder: modulo the prelude, the n-queens code is 100% compatible with GHC <siraben>and wrapping it with GHC would just be #include from another file like the wrappers in site/ <civodul>rekado, janneke & all: i've pushed a fix for "GuixSD" and an update to mes.md, which was lagging behind (you folks work too fast :-)) <janneke>civodul: it will never happen again ;-) -- i mean, ty! <civodul>rekado: should we change bootstrappable.org to use static-web-site in berlin.scm, so that it gets updated automatically? <janneke>./pre-inst-env dzn code -l c++ew test/all/hello/hello.dzn *janneke is waaay too busy today ***ericonr- is now known as ericonr
<deesix>OriansJ, I patched the M2-Planet test suite to allow parallel execution. It needs a couple of tweaks, but I'll send you a first draft/RFC soon. <pder>Since there is a desire to have a C preprocessor for M2-Planet, has anyone looked at https://hackage.haskell.org/package/cpphs? Its a stand alone C Preprocessor written in Haskell. According to cloc it is only 1389 lines of Haskell code. Maybe it could be ported to run on blynn-compiler?