<dddddd>A fresh pair of eyes would be great for this bit of documentation I'm perpetrating with help of my broken english. Any comments are appreciated! <oriansj>fossy: I know but you'll get there ^_^ <oriansj>dddddd: in the phrase: the problem about immediates bits us; don't you mean bytes ;-p <dddddd>Not that fun I think, the bits all around are causing the problems, but bytes sounds more like bites indeed. Hard to choose :P <Hagfish>Create one independent definition per _needed_ operation, instead of + reuse common parts <Hagfish>also "preliminar" should be "preliminary" (did you really write all this without a spell checker? the english is great, over all) <oriansj>dddddd: the technical details look good. <dddddd>changed to preliminary. No spell checker, a bit of dictionary. <Hagfish>uses +as part of the generation of 'if', 'for', 'do' and 'while' +statements. <Hagfish>i think "uses" might need to be "used" <Hagfish>"A bit too invasive change to the codebase." <Hagfish>that might be valid english, but i'm not sure :) <Hagfish>i would feel more confident about "A bit too invasive a change to make to the codebase." (even though that is still a sentence fragment, or something) <dddddd>Nice, on the technical side I was a bit worried about not being correct in "the value returned from the function, if any, is on X0" <dddddd>... but I don't find any exception. <Hagfish>i wish i understood enough to spot technical mistakes too :) <Hagfish>"It's a lot of fun to came up with basic solutions" -> "... come ..." <Hagfish>" See how +unsurprising are the depths" <Hagfish>not technically wrong, but sounds a bit archaic/poetic. i think most english speakers would put the "are" at the end of the sentence <oriansj>dddddd: well; there is one exception but it would be if you called a void function that doesn't return anything but before the return does something like 1+2; which would result in it returning 3. but I am not certain of the best solution to that problem. <dddddd>thanks Hagfish, I'm looking at your suggestions. <dddddd>Something like that I was looking for, oriansj. I see how the expression is in the register in that moment. <Hagfish>"ommited" i think should be "omitted" <Hagfish>"X16, LR and BP contains" that should probably be "contain", if i understand correctly <Hagfish>"workaround the architectural restriction" i think "work around" is the verb, and "workaround" is the noun <Hagfish>anyway, the document is already great, so thank you for writing it <dddddd>No, thank you, that was great! (: <oriansj>dddddd: it of course is not valid C code (every good C compiler should complain about it) <dddddd>As in "work the architectural restriction around"? <oriansj>gcc however appears to think it means return 242?? and clang (does warn about it) returns 16 <oriansj>(one has to add -Wunused-value to get gcc to complain about it) <oriansj>I guess none of the standard C compilers have an issue with void functions returning values; how odd <oriansj>but they do have a problem with returning the value from a void function or assigning it <oriansj>atleast some sanity to that optimization I guess <dddddd>oriansj, to generate the proof hashes "make Generate-test-answers" does almost everything, AFAIU. Then, another hash need to be update, I did it by hand last time I think.. Sounds correct or I'm missing something? <dddddd>(this for every commit that changes the compiler or the generated output) <oriansj>make Generate-test-answers will update all of the hashes; test100's proof will need to be updated as it needs to match the x86 output of compiling M2-Planet. The command to fix that is: sha256sum test/test100/proof >| test/test100/proof.answer <dddddd>OK, that sounds familiar. Thanks for the confirmation. <oriansj>you'll hit an error on the first test100 after every compiler update <oriansj>which is a good thing (gives you a chance to compare the difference in output to see if it looks how you want) <dddddd>Makes sense. I was a bit worried about the "by hand" part. Who am I to change the hashes? :P <oriansj>dddddd: you are a real developer; who is changing how the world works <oriansj>It is now your duty to update the hashes to reflect what you honestly believe the checksums should be. <dddddd>which means doing it with the correct directory state. I'll try not to mess it. <oriansj>They just need to be an honest attempt at doing the right thing. <dddddd>I guess releases are critical, and some intermediate bad commit is not the end of the world. <oriansj>release just need extra testing and updating of the Changelog (post release) <oriansj>There isn't a Gnu project more than 10 years old that doesn't have atleast 1 broken release <oriansj>even guix had to do a quick new release after v1.0 <dddddd>I'm planning to include a line in the changelog at the end of the branch, I think that's expected. Also, the manpage to reflect the new option early on. <oriansj>any commit prior to the merge is fine <Hagfish>dddddd: "work the architectural restriction around"? no, sorry, i meant "work around the architectural restriction" <markjenkinsznc>i noticed something super minor in stage0 that I'm tempted to not even file an issue on. Sometimes it's worth it to have "won't fix" on record to discourage the next person, but I'm not sure this is even worth it, so I'll put it in the chat first <markjenkinsznc>stage1_assembler-2.s and stage1_assembler-2.hex1 (knight implementations) are different in one tiny way. <markjenkinsznc>stage1_assembler-2.hex1 being in hex1 doesn't have access to absolute addressing, so $stack is hard coded as 0x400, which is totally an acceptable and aesthetically nice place to start the stack <markjenkinsznc>but stage1_assembler-2.s uses an absolute reference to $stack and has a :stack label at the end of the file, and the address for this turns out to be a little bit before 0x400. <markjenkinsznc>so I end up with a binary that's different on the two bytes where 0x0400 is hard coded into the first instruction LOADUI R15 $stack when I use knightpies and run $ ./M1tobin.py stage0/High_level_prototypes/defs stage0/stage1/stage1_assembler-2.s -o stage0/roms/stage1_assembler-2; sha256sum stage0/roms/stage1_assembler-2 ; grep stage1_assembler-2 stage0/test/SHA256SUMS <markjenkinsznc>I'm not sure any change is required, as it's fine if stage0_assembler-2.s from a documentation perspective if stage1_assembler-2.s only different from stage1_assembler-2.hex1 in this regard. <markjenkinsznc>If there was a desire to fix, 3 approaches come to mind, 1) adding padding before $stack to get it to 0x400 which will have to appear in the hex1 version as well (changing the test/SHA256SUMS result), 2) changing to a less beautiful stack start in the .hex1 version to match the .s version, 3) changing the code if possible to use a relative @stack reference in both the .hex1 and .s <fossy>markjenkinsznc: that is important, actually <oriansj>markjenkinsznc: you are absolutely correct; a relative @stack is probably the best solution <oriansj>These sorts of differences are extremely important to eliminate <oriansj>as everything in the early stages must be beyound question <oriansj>actually @stack will not work; after the change of calculating of the difference from the end of the instruction rather than the beginning. <oriansj>So I am going to change it to hardcode the address 0x400 and include a comment about it ***nckx- is now known as nckx
<markjenkinsznc>Going to keep this around for awhile to keep my codebase compatible with stage0 Release_0.2.0 and Release_0.3.0 . But eventually knightpies will git submodule reference a future stage0 release and I'll drop it to keep my test suite clean <markjenkinsznc>hmmm, oops, I also committed additional test cases in the commit I just made, oh well, one thing that's nice about working in a public repo that has had other people's notice is I feel an obligation to not rewrite published history, so it gits me off the hook for my git commit perfectionism <markjenkinsznc>as for @stack, I did think that it could be offset wrong, but that SUB or ADD instructions or something could be added to adjust to the intended target... but that would be ugly, I think your patch to stage1_assembler-2.s is good for leaving the .hex1 alone <markjenkinsznc>one could go further than the good comment present and comment out the :stack reference in the .s file so as to make it's slight inaccuracy more clear <markjenkinsznc>as for keeping my knightpies test suite compatible with different stage0 releases, I am very pleased to see git submodule references to the related code bases. Having falling in love with python3 unittest.skipIf, I can see myself conditionally testing against files from those submodules if the user has them present and otherwise just skip such tests. That will come once M1.py and hex2tbin.py support other archs, though for now I'm included to <markjenkinsznc>focus on getting to the point where I can cc_x86.s (implemented in knight) and using M2-planet to machine generate a cc_knight.s (implemented in knight) which can be commented, made more human readable in terms of instructions used, and become a tool to build M2-planet in knight isa.