<oriansj>it'll become more important as you approach cc_* <stikonas>yes, as the number of functions and complexity is growing... <oriansj>first pass stuff is simple enough to be clever and do neat optimizations but those will bite you hard later on. I learned that the hard way when I was trying to do FORTH in assembly. <oriansj>one could say writing a FORTH was the most painful learning experience in assembly programming I have ever had. But what it taught me (don't be clever), I'll never forget when working in assembly.. <stikonas>well, at least by the time we need to write cc_* we won't have to manually hexify... <oriansj>yep and you should have some good assembly programming habits down that'll be useful for the rest of your programming career <stikonas>well, so far I didn't have to use assembly... <stikonas>but yes, it's still a good idea to have some assembly skills/habit <oriansj>stikonas: if you know how to program in assembly and port M2-Planet to that architecture, you'll develop a feel for the why and how of compilers. <oriansj>which makes debugging and understanding issues much easier. <stikonas>I suspect I might need AMD64 more than risc-v though... But I guess there are a lot of similarities <stikonas>different assembly dialects are more similar than assembly vs C <oriansj>stikonas: there is far less differences at that level than you would expect. <stikonas>well, I already noticed that... After all I did look a lot at other architectures when writing risc-v stuff <oriansj>mostly it is just syscall numbers and what registers need to be used for syscalls. The rest is identical. <stikonas>I guess most of the difference is actually in binary layer... How all those instructions are encoded <oriansj>and what arbitrary restrictions the hardware force us to work around. <oriansj>like needing to do multiple instructions to load a 32bit immediate or not enough registers or really messed up stack support. <oriansj>AArch64 needs one to avoid using the stack pointer when working with the stack because '"reasons"' <oriansj>load relative immediate and jump over tends to be popular in RISC architectures. I think PowerPC makes that even more complicated. <xentrac>I think "don't be clever" is the most important lesson of Forth :) <xentrac>21:41 <@oriansj> standardize on 1-2 registers for returns and make sure all other registers are in the state <xentrac> they were when the function was called before you do the return. <xentrac>not sure the callee-saves-everything calling convention is the optimal calling convention :D <xentrac>I mean, whatever calling convention you use, it's important to follow it. but following a calling convention that has a few callee-clobbers registers can be significantly less of a hassle. you can just use them freely whenever, as long as you don't have a call in the middle <xentrac>it's pretty convenient for things like doing an address calculation or a little bit of arithmetic <oriansj>xentrac: it is definitely not the optimal calling convention in terms of CPU efficiency but it is optimal in terms of least number of bugs when writing by hand. <oriansj>but I have to agree after 6weeks of full time debugging to just get 1500 working lines of assembly that "don't be clever" is definitely the most important lesson of FORTH. <xentrac>is it? I mean, if a register is callee-saved, you have a bug if the callee forgets to save it. but if a register is caller-saved, you have a bug if the caller forgets to save it. the only difference is that leaf subroutines can't have the second kind of bug, right? <xentrac>I guess there's a second difference, which is that if you have several calls in the same subroutine, each one is a place where you can forget to save a caller-saved register <xentrac>but usually you don't actually save "caller-saved" registers, you just don't use them for values that need to survive a call <xentrac>I'll think about your advice when I write a bunch of assembly, though. I think you have more experience writing working assembly programs than I do ;) <oriansj>well callee-saved just needs a single saving of the registers you are going to change during the running of the function at the start (except for R0 and possibly R1 if you are returning values in them) and a mirror clean up prior to the return. <oriansj>no other cognative overhead required. <oriansj>So when you start using another register, add a push at the start and a pop before the return. Boom, no longer need to care <oriansj>and once I finish verifying mescc-tools for AArch64, there will be an update for stage0-posix using the new hex2 and M1 with baseline RISC-V support. <xentrac>right, I mean, caller-saved doesn't need any saving most of the time. no pushes, no pops, no worries. you just can't use the register across calls; if you want the value in it you have to store it somewhere before making the call <oriansj>xentrac: which is why it is easier for Compilers to do and honestly works beautifully there. <oriansj>xentrac: thank god we don't have to give a shit about any of that ***jackhill_ is now known as jackhill
<Hagfish>wow, that actually looks like it could improve things <Hagfish>it even mandates transparency logs for software <Hagfish>more like transparency pogs, amirite? <Hagfish>i guess it probably has the design goal that everyone will keep using language-specific package managers, which i think is an antipattern that software needs to move away from <stikonas>how are they going to achieve immutable logs? <vagrantc>yeah, signatures just allow a framework for "trust us, or them, or someone, but do just go ahead and trust them" <stikonas>are they going to store signature in bitcoin blockchain...