<oriansj>stikonas: do you mean cc_* crashes or the generated output? <stikonas>possibly my offsets are wrong in collect_argument <stikonas>so something went wrong in that second deep function... <stikonas>yeah, I think one of these offsets is off by 8 <stikonas>hence inserting random char *c = ret "fixes" it <stikonas>ok, I think there is some mess up in collect_local_fresh <stikonas>at least M2-Planet now shows something proper when I type M2 --help <stikonas>(M0 still crashes on cc_riscv64 output), so I build M2-Planet with M1 <oriansj>it is easiest to debug cc_* by knowing what it is supposed to produce; So adding RISC-V support to M2-Planet is probably the best course of action. <oriansj>M1 isn't expected to be buildable by cc_*; only M2-Planet <oriansj>it looks like you mixed the AArch64 and AMD64 function argument offsets <oriansj>I think I find a bug in function_call. The push onto stack order is wrong. It needs to be temp, then the function return pointer, then base pointer, then and only then do you copy the stack pointer to the base pointer register. <oriansj>then collect_local_fresh isn't supposed to be 16 but rather 8 <oriansj>because that 16 is what is going to give you the absolute wrong value in that second function <oriansj>and because most architectures don't zero memory when they pop it, what is in that address is probably what last was in that stack position. <oriansj>The reason why AArch64 is only +1 register size in that case is because unlike all the other architectures it doesn't have an implicit push when it does a call <oriansj>which would have the +2 register size offset to compensate for that value. <oriansj>So AArch64 has to preserve the link register while setting up for a function call <oriansj>and submitted a lightning talk proposal. Hopefully they like that <oriansj>and I am open to suggestions for other conferences to try to give a stage0 talk provided they allow remote <xentrac>usually the way lightning talks work at conferences I've been to is sort of barcampish <xentrac>someone puts up a flipchart or outlines an area on the blackboard that says "LIGHTNING TALKS SIGN UP HERE" and people walk by and write stuff in it <xentrac>and then when the time comes for the lightning talks the emcee goes down the list, calling on each person who signed up when the previous speaker finishes or runs out of their 5 minutes <pabs3>I'd definitely suggest LCA, fairly technical stuff gets presented there <pabs3>DebConf would be another option, but that is past already for this year <xentrac>are there any architectures that do zero memory when they pop it? <oriansj>xentrac: well every architecture which memory has destructive reads by default <oriansj>but more specifically knight zeros on pops unless you use the load auto increment/decrement instructions like pop <xentrac>I don't know of any memory which has destructive reads by default <xentrac>I mean core reads are destructive at the level of the actual cores, but the hardware restores that for you, doesn't it? <oriansj>well no, you need to issue a write while you still have the value after the read. <oriansj>So either the architecture had an implicit write or an explicit one or the value went to default after read <oriansj>micorcode ensuring that the write is done, I also wouldn't consider hardware but rather software. <oriansj>and knight just skipped doing the write back in their microcode to save some space and it resulted in a clean stack with no previous values after they are popped as a nice side effect. <xentrac>oh, really? I thought it was the memory controller that did it <oriansj>knight didn't have a separate memory controller <xentrac>surely it had the sense amplifiers as close as possible to the core planes, not socked away within the CPU <oriansj>for example by the AOS instruction on the PDP-6 the hardware simply incremented the value between the read phase and the write phase of a single memory cycle <xentrac>I just realized today that in general you can inline longjmp() as mov (%eax), %esp; ret <xentrac>though setjmp() may or may not be a little hairier depending on your calling convention <oriansj>certainly simple to implement but honestly something one should avoid for ease of understanding of the code. <xentrac>well, it definitely has its downsides, but sometimes people like exception handling :) <oriansj>I haven't seen a case yet in bootstrapping where it had to be used for exception handling. And M2-Planet + mescc-tools certainly handle a great many possible exceptions. <xentrac>you never *have* to use setjmp/longjmp <xentrac>at least if you can change all the code <oriansj>or are willing to abort fast and early <xentrac>you can just set a flag in memory or in a register that everything checks <xentrac>or do you mean that sometimes that's too slow? slowness is not the complaint I have with it myself <oriansj>my only issue with it is that people tend to abuse it in ways that make code harder to reason about. <xentrac>I think longjmp pretty much invariably makes code harder to reason about <oriansj>hence why M2-Planet doesn't support it; despite how easy it would to do so. While goto does exist <xentrac>it's a bit arcane and usually a big headache to implement ***ChanServ sets mode: +o janneke
<theruran>so is Chicken Scheme closer to being bootstrapped from stage0 since it can be built with tcc? trying to decide between Chicken and Guile to write that Ada compiler <stikonas>theruran: guile can also be bootstrapped from stage0 <theruran>so no big binary blob needed? syntax-case is the last hold-out? <theruran>ok thank you. that is great! is it being reviewed or scheduled for upstream? <stikonas>hmm, blood-elf might also need some changes for risc-v...