<OriansJ>The extra fun part is realizing that 74% of the changes are updates to the comments <OriansJ>Assuming I didn't make any obvious mistakes, the updated mescc-tools-seed will be up tomorrow and the slow march to mes-m2 completion will begin (hopefully dddddd finishes the aarch64 port soon as code changes to M2-Planet may be required to support additional functionality) and janneke I am probably going to break the shceme for a little while while I harmonize its test behavior with that of guile ***ChanServ sets mode: +o rekado
<dddddd>OriansJ, can you elaborate a bit about what changes are you planning to make? I have to rewrite part of the port, so one possibility is for me to do it over the new codebase. <OriansJ>dddddd: no plans yet, I however is hoping to merge in your port and do a release prior to any potentially changes that might break compatability with cc_* <OriansJ>as any breaking change must become a new major version number <dddddd>I just don't want to slow down your progress. I can make some basic clean-up and release a crude version but I'd prefer not to. <dddddd>My idea, now that even test100 looks like is going to pass, to go back to the beginning and redo everything in a cleaner way. For example, using sign-extend from the start, use NULL instead of NOP, etc... Commits and comments needs some clean-up too. <dddddd>But this will take some weekends... <dddddd>If you need the "final" port to work the next iteration of M2-Planet, it's way too much time, I think. <dddddd>Another point of view: if you merge the port, then we need to update it with the new funcionalities as they are added (like the rest of the ports) but you're not familiar with the aarch64 port (which is going to be under-documented in that moment), so again is slower. <dddddd>Were you waiting for me all this time? <OriansJ>I can wait for you to clean it up but I still need time to review your changes before I merge them in. So mes-m2's release will be delayed but it gives me more time to make its behavior more standard. <dddddd>OK, let's see how this works: I release a very crude (even squashed and non-documented) proof of concept (today I guess), not for merge. Then, I start to make smaller commits/branches... per test. Again, not well documented nor for merge, but more review-able. We can see the pace I can manage and feedback starts to flow. With that, I think you can decide if you still want to wait for a mergeable port to start the big M2-Planet changes. Makes <OriansJ>clear communication is our first goal with all code; avoid clever <dddddd>oh, this code is far from "clever" (both the compiler code and, specially, the generated code). <dddddd>I'm wasting stack space to avoid aligment problems. I'm generating silly constructs to avoid the weird imm in the ops... <OriansJ>So long as they are easy to understand and explained clearly <dddddd>Sure, that's why I don't want to throw a patch to the wall, but make a clear history of explained commits. <dddddd>I was even thinking on a blog series, but that's very much undecided. <OriansJ>well if you wanted to do a blog series, it would probably work best with a 1:1 match with commits; probably aligning the commits with individual tests with a final build up to full understanding that a simple state machine is a cheap way to make a compiler <OriansJ>write the blog first to ensure it flows into a coherent narrative and share the links with us so we can all follow along with your story <dddddd>I'm wondering if the changes to come will change the shape of the compiler. <dddddd>... to the point that it will use different tactics... <OriansJ>dddddd: there will be major changes that get incorporated over time. Hence why I prioritized porting over new features with the current release series <dddddd>So the supposed blog series will be "obsolete" right away... <OriansJ>It will simply map to the work all ports must begin with <OriansJ>M2-Planet is designed to never need anything not supported by the previous major release <OriansJ>So M2-Planet v1.0 is a very important foundation that all ports will need to know about to do a complete from zero bootstrap <dddddd>Oh, true... so, from that point of view one version doesn't "die" with the release of another (even it can recieve more ports in the future) <dddddd>and I guess the aarch64 can be one of those. <OriansJ>M2-Planet v1.x will effectively become immortal and only really grow in regards to more ports <OriansJ>The second we hit a feature cc_* can't support but M2-Planet v1.0 can; we can't use it until v2.0 <dddddd>So we can think of aarch64 of one of those future ports (even if it's closer). <OriansJ>and we can even add lots of new features to M2-Planet v1.0 but we can't use them unless cc_* supports them <dddddd>What do you mean by cc_*? (now that you use both that and M2-Planet as different things I'm a bit lost) <dddddd>(note that M2-Planet are mostly cc_* files) <OriansJ>cc_x86 and cc_amd64 are hand written assembly programs cc_armv7l with be the same as well as a future cc_aarch64 <OriansJ>Which only support the minimal subset required to bootstrap M2-Planet v1.0 <OriansJ>as in cc_x86 has been written and I am not going to be backporting features by hand into assembly <OriansJ>So the feature set of M2-Planet v1.0 might grow but it must grow in the hard limitations provided by the minimal subset of cc_x86 <OriansJ>as in the entire M2-Planet v1.x series must be buildable by cc_x86.M1; one can not skip the rule of no use a feature until the next major release <OriansJ>Sorry for any confusion as when I speak of cc_* I am referring to the cc_x86.M1, cc_amd64.M1 and similiar series <dddddd>So, you want to wait just to see if I'm changing something fundamental in the compiler (incompatible with 1.x series)? <dddddd>Because, otherwise, I don't see a reason to not start with 2.x (because my port is just for 1.x) <OriansJ>dddddd: you can independently verify that yourself rather easily (does cc_x86 produce identical output as M2-Planet --architecture x86 given your changes) <dddddd>I think so... I don't touch any non-aarch64 output. Also, doing something like test100 produces the same proof. <OriansJ>dddddd: it isn't just output, cc_x86 lacks some constructs that M2-Planet supports <OriansJ>such as initialized globals or sizeof() CONSTANTs <dddddd>OK, let me squash and so... then send you the crude patch so you can see what I did, generally. That'd clear some doubts up, I guess. <dddddd>Fun fact: ^ operator is not used by any test (It's not even implemented in the port, yet) <OriansJ>dddddd: to be honest, I was overly minimal in regards to tests for M2-Planet (very little code coverage) as a side effect of constantly being short on time <dddddd>Well, they cover what it's needed for itself. No ^ to test, that's fine. <OriansJ>dddddd: it also covers the entire mescc-tools set as well <OriansJ>That is why mescc-tools-seed builds M2-Planet before it even builds blood-elf <dddddd>more to the "fun" part I was trying (sorry) to explain, indeed. ^ is not _used_ (: <OriansJ>well that has more to do with outside of crypto; one generally gets quite far with just simple bit masking and bit shifting (see ceil_log2 in cc_core.c) <dddddd>test22 is passing even with an empty chmod() library function, by the way.