<stikonas>oh, actually maybe not, maybe it's just base address there... <oriansj>stikonas: it got the calculation correct assuming your first executed instruction was after :_start <stikonas>yeah, that's right, I remember checking that size <oriansj>the TODO was to check if RISC-V made a deviation from the ELF standard like PowerPC did and put the address of where the e_entry address was stored instead. <oriansj>as that was an open question before hex0 got working. <oriansj>and by the looks of it the answer is no <oriansj>so absolutely yes the TODO comment can be removed <stikonas>at some point I should replace Development/*.hex2 headers with proper one with labels... <oriansj>although the ELF documentation says p_filesz and p_memsz "May be 0." what it doesn't say that means it *WILL NOT* be loaded into memory at all and Linux will be more than happy to truncate your shit. <oriansj>well ideally you would just have a standard elf.hex2 which all M1 and hex2 files use so that you don't have to keep manually tweaking ELF headers <oriansj>in theory hex2.hex1 should be the last file you write that would have a hand written elf healder <oriansj>(not counting the undone catm of course) <stikonas>although, I guess it's first used to prepend the header <oriansj>which will allow you to combine that standard ELF header with M1 outputs and hand written hex2 files <oriansj>stikonas: it is needed for AArch64 to indicate to use the aligned or non-aligned offset calculation <stikonas>and %ELF_end>ELF_base means that if end of file is not aligned to word(?) size then zeros are added <oriansj>so it could be used in RISC-V in the fashion of ^~label ^!label ^@label ^$label ^%label ^&label <oriansj>stikonas: no %ELF_end>ELF_base means the number of bytes of size the elf header is (changes if you add in the segment header in too) <oriansj>^~label would be the number of words between the instruction and the label <oriansj>think of ^ as just toggle the Aligned variable to on and later when I deal with the pointer do something different <oriansj>because the Aligned variable is set to true <oriansj>there is a big difference between < ^ and > <oriansj>< means pad to word alignment (probably very useful for RISC-V), ^ means next pointer needs to be the special word aligned form (or honestly any special behavior your want for your architecture) and > is for calculating the number of bytes differences between the addresses of any two labels <oriansj>mescc-tools is a subtle assembly language for dealing with all the ugly architecture specific behavior needed for bootstrapping. <stikonas>yeah, and even then for risc-v we had to invent more... <stikonas>but with . I think the whole thing is quite flexible <oriansj>it needs to be to put up with the crazy shit instruction set developers seem to shove into their crap <oriansj>one might even say M1 and hex2 have had a rather extensive evolution path, to a degree which was honestly unimaginable when I first began. <oriansj>yet here we are and I am excited to see what enhancements are discovered over the next 5 years. <stikonas>and it's actually smaller than AMD64 version ***ChanServ sets mode: +o janneke_
***ChanServ sets mode: +o janneke
<stikonas>argh, I accidentally committed catm.hex2 for riscv... Will remove it later... <oriansj>stikonas: e_entry generally is &_start or &start so that you can put the :start or :_start anywhere in your assembly program you want and it will still be the first instructions executed. <stikonas>oriansj: oh you mean instead of ELF_text ? <stikonas>that was what other arches were doing... <stikonas>oriansj: ok, pushed another commit to PR <stikonas>if I understood your intention correctly... <oriansj>stikonas: you are right is exactly what the other architectures are doing. I really should fix that in M2libc as it is incorrect behavior if someone doesn't put :_start first right after the ELF header <oriansj>guess it dropped off my radar by accident. it is a real potential bug for ELF headers <oriansj>thank you for helping me to remember to fix that <oriansj>We standardized on _start for M2libc to match wath binutils uses <stikonas>yeah, I think I waw _start before too in various places <stikonas>that's why I picked _start rather than start <oriansj>and fixed M2libc (now to fix mescc-tools examples as well) <oriansj>ok mescc-tools fixed. Now to clear out the issue in stage0-posix <oriansj>(the AArch64 updates always take so long to validate) <oriansj>and single byte writes on a MicroSD card <oriansj>the speed diffference between assembly hex2 and M2-Planet compiled hex2 is like night and day. <oriansj>stikonas: raspberryPI with microsd card <stikonas>well, yes, assembly programs write one byte at a time <stikonas>well, for risc-v I was only working on qemu... <stikonas>unless you count my solder iron (and that is riscv-32 not riscv-64) <oriansj>stikonas: you probably would qualify for hardware through their development program <stikonas>well, maybe at some point I'll buy some SoC... <oriansj>I have one of the first batch RISC-V boards they ever sold on CrowdSupply if you want it. <stikonas>that's fine... I'll just buy at some point <stikonas>soon I think there will be quite a few more boards on the market <stikonas>they put ECC mostly into server boards... <oriansj> or workstations (Intel xeons in CAD systems sort of thing) <oriansj>I straight up refuse to buy any more hardware with more than 8GB of RAM that doesn't have ECC working. <oriansj>I'd rather have 4GB of ECC than 8GB of maybe it might not corrupt your shit RAM. <oriansj>siraben: well first to know the details of your memory sudo dmidecode --type memory <oriansj>To get kernel-detected PCI and ECC RAM errors: <siraben>also new timezone if anyone needs to ping me; central US time <siraben>stikonas: yeah, but masks are required again due to delta <oriansj>well on guix and debian it would be the package called dmidecode <stikonas>well, here masks are no longer "required" but most people still use them <siraben>especially with out of state tourists <stikonas>in UK basically the only restrictions are when you cross border (needs those expensive PCR tests) <oriansj>well nashville is a bit RED in regards to these sorts of things. <siraben>nashville technically votes left every season <siraben>but it is a blue county in a sea of red <stikonas>in UK tories (right) are blue and labour (left) are red, so colours are swapped, but there are more parties here despite first past the post system <oriansj>RET***D Extremely Dangerous (plague carriers) <siraben>amazing how utterly wrong this turned out <oriansj>well I was in the group that did the simple math of if everyone does basic PPE for 4 weeks virus has no potential hosts => problem done. <oriansj>but no, it became a political football and now there are people dying in hospitals claiming it is all a hoax <stikonas>well, somehow nobody was able to manufacture PPE at the beginning, so there was a bit of shortage <stikonas>but yes, PPE is probably even more effective than vaccine (which is already quite effective), those N99 PPE can catch almost all particles. <siraben>the fact that the virus wasn't deadly enough allowed misinformation to spread like fire <oriansj>stikonas: I have OCD and was stocked prior to COVID hitting the US. (a bit overstocked due the birth of my child around that time) <siraben>wasn't SARS a two-digit mortality rate? <stikonas>anyway, it was easier to detect it because it was only transmissible after you had symptoms <stikonas>and there was also MERS virus after SARS, but that had fairly low R number and couldn't spread easily <siraben>it's been eye-opening how unnecessary being in-person is for certain activities <oriansj>My response when the shortages appeared was to make gift baskets with 40 N95s and a liter of hand sanitizer and give out to my 10 closest neighbors. Figured it would up my survival odds if shit went sideways. <oriansj>the only thing I really missed out in 2020 was the annual picnic+BBQ I throw to share the veggies and truit that is harvested in my garden. <stikonas>oriansj: wouldn't your Aarch64 test run much faster if you allocate a small tmpfs for it? <stikonas>then at least sdcard overhead will be gone <oriansj>stikonas: actually I tested that just last week and the results were far less impressive than hoped. It was only a 10% speed increase. I'm guessing the big performance bottle neck is in the simulated syscalls (which M2libc does very few of) <stikonas>on my rockpro64 it takes maybe a minute or two to run the whole thing <oriansj>stikonas: probably better virtualization performance too <oriansj>on my x200 laptop it takes 29seconds <oriansj>(Taurinus X200 because buying libreboot laptops is why harder than it should be) <oriansj>janneke: haven't heard anything from you for a while. How goes the RISC-V porting of MesCC? <stikonas>I guess I should push at least non-debug elf header to m2libc <oriansj>stikonas: mescc-tools has sample ELF-Headers to help people doing new ports to be able to make some simple tests for M1 and hex2 to work out issues before they do more serious work in hex2 or M1 <oriansj>M2libc is where the ELF headers that M2-Planet uses when it does builds <oriansj>although I problably eliminate the mescc-tools ELF-headers and switch to using the M2libc ELF headers instead. <stikonas>yeah, fewer duplicate files would be better <oriansj>So put your ELF-headers in M2libc and I'll just update mescc-tool's M2libc submodule <stikonas>well, so far I only tested non-debug header... <stikonas>on and I'll update M1 defs file a bit... <stikonas>it's good to have RS2_X aliases for bit shifting... <stikonas>because shift amount is in place of second source register <oriansj>stikonas: unless we tweak M1 to just have a single dedicated to that special immediate case <stikonas>well, if we can achieve something with defines, I think it's fine <stikonas>e.g. if you are shifting by 17, you just issue RS2_X17 <oriansj>which instruction format is the bitshifts? <stikonas>but the shift amount is used instead of second source register <stikonas>well, maybe can use a shorter string than RS2_X... <oriansj>stikonas: !@$~%& followed by a number in M1 just become a block passed to hex2 <oriansj>so $5 could very easily just become just R format in express_word <stikonas>well, yes, that would work, I was just thinking it's a bit confusing to have same char for 2 different types <oriansj>that is why hex2 might support numbers for labels but M1 makes such input impossible <oriansj>but you are right it might be confusing <stikonas>that would basically generate the same thing for hex2... <oriansj> well .5 would expand in M1 into something like .00005000 <oriansj>and then hex2 would just deal with the .00005000 input <oriansj>but that is something for you to decide if that is what you want stikonas <oriansj>and feel free to pick any of the following characters: !$&. for this format inclusion <fossy><stikonas> fossy: anything else in config.log? <fossy>Yeah, __gmpz_init not defimed <fossy>grepping for that in /usr/lib and in strings shows nothing <fossy>im looking at gmp build files now <stikonas>are you changing prefix too at the same time? <stikonas>maybe that broke things rather than kernel <fossy>yeah I am, I think that is pretty likely. <fossy>Im trying in chroot to rule it out