<stikonas>oriansj: hmm, I think in hex2 word version we don't yet have any way to process those pointers in .data? <stikonas>well, & is not there, I guess we have ! but that one does shifting <oriansj>I guess I failed to ensure %label and &label work for RISC-V <stikonas>yeah, I think WordStorePointer are still buggy <stikonas>possibly first consume_token in that function is extra... <stikonas>ok, got hex2 to run without error, let see if I don't have any off by 1 errors <stikonas>oriansj: I have one extra line in my patch <stikonas>added Clear_Scratch(scratch); before next consume_token <stikonas>so with that it runs but resulting kaem-optional-seed does not to anything, possibly pointer values are still incorrect... <stikonas>well, that needs more thourough debugging <stikonas>oh, that might be because my data is not word-aligned <oriansj>(one feature you might want to include in hex2 on such aligned architectures) <stikonas>yeah, I'm now looking where to use it... <stikonas>hmm, just padding alone didn't help... I'll write .hex0 and then compare with hex2 output <oriansj>don't forget the single null at the end of the string <stikonas>oriansj: I think calculated addresses are way too high <stikonas>and first pointer is 2451 0001 0000 0000 <stikonas>which should point to line 0000110 6f6f 7374 7274 7061 732d 6565 7364 502f <stikonas>so I guess first pointer should be something like 010e 0001 0000 0000 or something similar <stikonas>copy pasted too much from kaem-minimal, so used the wrong register <stikonas>so we'll have 485 byte hex0-seed and 361 byte kaem-optional-seed <stikonas[m]>It might be possible to cut some bytes from hex0-seed too <oriansj>and it appears my email has tempted yt. So perhaps a mescc-tools revolution? ***sm2n_ is now known as sm2n
***dongcarl1 is now known as dongcarl
***ChanServ sets mode: +o oriansj
<stikonas>I moved that hardcoded string to the end of file, so that updating it is trivial even if it is hardcoded (since then it wouldn't affect anything else in the file) <oriansj>oh didn't know you made a pull request there too <stikonas>in principle it might be good idea to pull in newer bootstrap seeds into stage0-posix... <stikonas>I'll probably take a look at hex0 next, it might be possible to reduce it by a few bytes <oriansj>and probably update the mescc-tools to make sure I didn't break the build too hard as well <stikonas>also hex0 does not have .M1 and .hex2 prototypes... it might be a good idea to produce them... <oriansj>a hex2 prototype can always be skipped. M1 is more of a trivial audit <oriansj>as it should be 1:1 with the hex0 and one needs only check the defines and that it looks correct in terms of instruction flow. <stikonas>yeah, M1 is not much change from .S file <stikonas>but hex2 might be useful to check jumps, anyway, it's not a hard requirement to have them <oriansj>true but hex2 files are more work to make than M1 files. So I understand if someone doesn't want to deal with the extra work. <oriansj>(although it can be used to make hex0 in an incremental fashion.) <stikonas>yeah, I found M1-> hex2 -> hex0 to be somewhat simpler than .S -> hex0 <stikonas>not sure about total time, but more sytematic, less error prone <oriansj>indeed. hence hex2 tends to only exist for hex0, hex1 and hex2 source programs in stage0-posix <stikonas>well, M1 is written in hex2 but that's in source, not prototypes <oriansj>and I'm finishing the required testing for the bootstrap-seeds update in stage0-posix <stikonas[m]>I'll do some smaller pr then (update hex0 sources in posix0 to match bootstrap-seeds) <oriansj>stikonas: RISC-V is your baby, I trust your judgement and decisions in regards to it. <stikonas>well, it's not really mine, more like collaboration <oriansj>stikonas: everything here is a collaboration to a degree quite rare in the world of FLOSS. but you certainly are solving a great many of the hard problems while I deal with the easy things on the sides. ^_^ <stikonas>somehow we have 2 copies of M1 defs in two different repos... <oriansj>well the stage0-posix defs tend to be the minimal sets needed to get to cc_* <oriansj>after that everything just uses M2libc <stikonas>those are full sets that should be sufficient for everything <stikonas>at least just one more program left to write in .hex0 dialect <oriansj>yep hex1 (or hex2 depending on how much work word support is in RISC-V) <oriansj>I probably should extract and make a single file hex2_word.c for High Level Prototypes so that you have a template to compare against <stikonas>well, you can do that, although, I'll be able to extract needed bits from hex2_word.c anyway <stikonas>but it might be good to have it as documentation <stikonas>I guess first thing is I need to word processing, so loop of 4 bytes... <stikonas>so shouldn't be too hard to write .S prototype <oriansj>there are two calling conventions of which I suggest you follow the second. 1) caller saves registers before call and restores after call 2) callee saves registers on entry and restores before return. <oriansj>you don't need to save registers that you intend to return values in. <stikonas>well, yes, I already modified hex1 code that I had before to save return addresses on the stack <oriansj>and it makes the code easier to follow and you less likely to step on a variable you'll need. <stikonas>well, at least those a* registers are supposed to be saved by callee... <oriansj>stikonas: the hardware isn't going to save the registers, you need to explicitly push them onto the stack <stikonas>oriansj: yes, I understand, that's what I did in kaem <oriansj>good. It is one of the most important lesson in writing big assembly programs. <stikonas>I think I mostly try to use those temporaries t* as variables that are used within the next line or two and before jumps, so don't need to save those <oriansj>stikonas: I know it is very tempting to think just follow convention but it can catch you with a very hard to trace bug. <stikonas>that's true... And assembly programs are not that easy to debug <stikonas>especially when architecture is non-native <oriansj>standardize on 1-2 registers for returns and make sure all other registers are in the state they were when the function was called before you do the return. <oriansj>and there are times you'll see such clever tricks violating that rule but trust me in that you'll thank yourself later for avoiding them. <oriansj>simple and reliable beats small and clever in bootstrapping 99/100 times