IRC channel logs
2023-06-08.log
back to list of logs
<oriansj>I wonder if the Power engineers regret having multiple separate conditional registers <muurkha>I think that makes superscalar a lot easier <oriansj>well it saves a couple registers as one only needs 4bits for conditional outputs instead of using up a whole 64bits of register space. <oriansj>(or 5 bits if you need separate carry/borrow bits) <oriansj>(or 8 bits if you want to plan for future floating point conditions) <muurkha>saves a couple of registers compared to which alternative? <muurkha>I meant easier than having a single flags register <muurkha>but a single flags register obviously uses less flip-flops than several of them <oriansj>but some RISC architectures use The Integer registers to store the condition (RISC-V included) <muurkha>in between those instructions there is notionally a flags register intermediating <oriansj>yes but you can do conditionals by just doing subtraction and comparing against R0 <muurkha>there's just one instruction; there isn't a comparison result stored in some other register <muurkha>but you don't need to do the subtraction <muurkha>you don't need to do the subtreaction and then compare the difference against r0 <muurkha>you can just do something like blt t1, t2, 3b <oriansj>true, it is possible to avoid but there are times you will want to store a compare before doing jump <muurkha>I don't think it's just possible to avoid, I think avoiding it is always easier <muurkha>admittedly you've probably written more RV64 code than I have <oriansj>actually when implementing M0, doing pushf and popf made things cleaner <muurkha>so likely I'm just not thinking of something obvious <oriansj>store the condition of if the first char is negative prior to reading the rest of the string into an int <muurkha>then you can test it to see if it's negative later in the same way you did the first time <oriansj>that would have made it uglier but entirely valid <muurkha>probably the same number of instructions since it's 3-address code <muurkha>not overwriting a register doesn't take any extra instructions over overwriting one <oriansj>well as RISC-V doesn't have push and pop, it would consume 4 more instructions (to preserve and restore an extra register) <muurkha>(though it might require more bytes) <muurkha>oh, well, usually you use a non-call-preserved register for those things, but even preserving a call-preserved register only takes two instructions, not 4 <muurkha>sd s3,24(sp) to save it and then ld s3,24(sp) to restore it <muurkha>you do have to reserve 8 bytes more space, but that doesn't require more code, it just requires changing addi sp,sp,-64 (and its inverse in the epilogue) to use an 8-bytes- <muurkha>I came across a fun paper the other day that describes some simple hacks to OpenRISC that got significant speedups on an in-order implementation, and one of them was sort of adding an autoincrement/decrement addressing mode. I think they are equally applicable to RISC-V <oriansj>true, one can certainly do a single add/subtract at the start and end of an assembly function to fix the stack pointer prior to storing values onto the stack and after restoring values from the stack back into registers; so for functions that are already storing a couple values onto the stack, it would only cost 2 additional instructions <muurkha>yeah, that's the normal thing to do! <muurkha>of course it does mean that the *first* register you save does cost you 4 insns; the OR10N paper describes how to sort of fix that, though in a way that would break the standard RISC-V ABI I think <muurkha>because on RISC-V with the standard ABI your stack is supposed to always be 16-byte-aligned IIRC? that way interrupt handlers can assume the stack is 16-byte aligned? but maybe I'm remembering that wrong <muurkha>OR10N is the microarchitecture from the paper I linked above <stikonas>well, in mescc we use a couple of RISC-V registers to simulate condition flags <stikonas>that's probably a waste of registers in general <stikonas>but we don't really care about that in bootstrapping <oriansj>we might not be optimally efficient but we get 90% without too much work (in C and above) <oriansj>in that paper, the openrisc loop registers seem like something that would be a problem in OoO <muurkha>they don't affect execution except when it reaches the end address <muurkha>the problem with flags registers is that like half of all instructions you run overwrite them, but only partly <muurkha>so unless you do fancy tricks your data dependency graph of instructions is a sad little straight line, like the family tree of an inbred royal housse <muurkha>with movs and jmps hanging off the side like bastard children <oriansj>hmm, odd though; a full set of loop registers could be used to speed up loop unrolling to an abusive degree but only a handful of numeric functions in bootstraping would benefit from such things <oriansj>good point on the memcpy (also in calloc; which I heavily use) <muurkha>(why a GUI? because you don't want to depend on plausibly backdoored machines to navigate your bootstrap codebase) <oriansj>I was pondering a bootstrap cpu architecture which would be trivial as possible to implement but also make bootstrapping to C easy <oriansj>muurkha: one does not need a GUI to edit code <oriansj>for things like emacs and vim absolutely; editors likes SET not so much <muurkha>you may be interested in this comment from a few weeks ago by a friend of mine who uses ex <muurkha>I just haven't tried using it so I don't know how effective a development environment it is <oriansj>muurkha: it is if you have nothing better, it can get the job done <oriansj>and can be written in a few hundred bytes of hex <oriansj>but it taught me, if you are forced to use any editor for a week. Then any editor is fine <oriansj>and if you only have a hex monitor or hex assembler, you can write SET in about half a day and everything after that is so much faster. <oriansj>part of me we tempted to get an ed for mescc-tools-extras <muurkha>I think that if you have a monitor you can do a lot better than ed, probably in less code <muurkha>ed is carefully optimized for a 110-baud teletype <oriansj>muurkha: well ed is actually quite nice relative to a minimal hex monitor (no readline support after all) <muurkha>sorry, I meant a video display monitor, not a monitor in the sense of a small program that lets you look at memory and invoke code <pabs3>might be work thinking about what to do with bootstrapping.miraheze.org <stikonas[m]>We haven't really used that wiki very productively anyway... <pabs3>hmm, api.php isn't enabled on it, so git-remote-mediawiki doesn't work <pabs3>I think oriansj did copy the wiki elsewhere... <rkeene>Fossil has a wiki and a bunch of other stuff integrated, which syncs along the code <Harzilein>rkeene: alas it shares with cvstrac the opinionated bit that the wiki isn't versioned i think? <Harzilein><pabs3> hmm, api.php isn't enabled on it, so git-remote-mediawiki doesn't work <Harzilein>pabs3: not activated, or sitting at a weird location? i think there's a special page that points to it <rkeene>Harzilein, The wiki is versioned <rkeene>Wiki (and Wiki history) is also synced <Harzilein>rkeene: interesting, even cvstrac no longer appears opinionated on that.