Mouse recommendations for RSI?

made a SubV / #riscv ISA reference sheet for all the common mnemonics and their values:

@akkartikAs for the last part, I could not implement JALR or cripple it to do only absolute jumps, but the RISC-V ISA is already so lean and it is closely in reach so it feels like a bit of a shame IMO.

I think it would be especially interesting to have a fully capable machine code language for RISC-V because the canon assembler already does a lot of lifting with pseudoinstructions (especially for jumps) so SubV could be very educational there.

Wrote more about #riscv far relative jumps with a detailed working example as well as the (wip) syntax for doing so in SubV:

https://git.s-ol.nu/subv/blob/master/JUMPING.md

(~10min read + ~5min think)

cc @akkartik @ekaitz_zarraga (I'm tagging you a lot, please feel free to disregard and/or let me know if you've had enough of this and I'll stop ;)

@ekaitz_zarraga @akkartik

ok, i'm still a bit conflicted on this, but maybe this is actually cleaner?It's tricky because I don't think there is a good natural intuition for this, so it mostly depends on how you are used to this off-by-one thing behaving in other contexts. But I definitely like that this is much clearer to read as a size.

@ekaitz_zarraga @akkartik hm, the +1 / inclusive ranging is not from python actually, I took that from Verilog and VHDL.

In python, slicing is [inclusive:exclusive], e.g.:

>>> a = [0,1,2,3]>>> a[0:3][0, 1, 2]

I guess for bits this would be flipped, so to take the lower 8 bit of a larger number (bits 7, 6, 5, 4, 3, 2, 1, and 0):

num[8:0]

@ekaitz_zarraga @akkartik The 1 would be either 1 or 0 in other contexts, but when it is 0 it would probably be left off. I think putting a literal 1 there is nice because it makes it more obvious that it takes up a bit:

size([H:L]) = (H - L) + 1size([1:H:L]) = 1 + (H - L) + 1

(the +1 is because bit-slice indices are inclusive)

I think the correct syntax for the Sub-V label-reference immediates (and similar ones) will be one of:

label+4/offlabel+4/off13label+4/off13/[12:1]

(from less to more verbose, with format.py filling in the gaps based on knowledge of the instruction)

The "+4" is a variable offset that can be omitted when unused also.

@akkartik @ekaitz_zarragamaybe instead of [:H:L] it should be [1:H:L] which can be read as "one sign bit, then all the bits from H to L, inclusive" and also it aligns somewhat better with python syntax

@akkartik @ekaitz_zarraga I bet this is hard to follow, but does this make sense to either of you by any chance?

I wanted to avoid having a separate syntax for that, but I think it might be necessary to add

label+4/off32/[:11:1]

where the extra ":" says to copy the sign bit in addition to the given slice.

When only

label+4/off

is specified, this kind of truncated 32 bit offset could also be used automatically on relevant instructions (maybe that's only JALR, I haven't even looked at most branches yet)

The thing that I am still undecided on is how to handle e.g. AUIPC+JALR here with respect to range-checking. My general idea would be that writing

label+4/off13/[12:1]

will cause an error if "label+4" doesn't fit in a 13-bit signed number. But when a AUIPC+JALR combo is used, the JALR instruction immediate should be a "sign-compressed" slice of the 32 bit complete offset.

@ekaitz_zarraga @akkartikyeah, that's what I've been doing for auipc now ;)

@akkartik btw it's very interesting to see you and the person who answered in the SO question to also misspell auipc as aiupc, which I have been struggling with a lot also!

I wonder what it is about those three vowels that makes it hard to remember the right way? To my german brain, "aui" should actually be more familiar ("au" is a bigram with a specific sound, and aui is pronouncable) whereas aiu is just letter soup.

@akkartik(typing this blind on my phone, so surely got some details wrong and the opcode instruction bits are missing. Also jalr's immediate argument is actually the [11:1] slice plus a sign bit)

I want to make it so you can optionally specify the exact slices as above, or just write label/off32 and it will get the slices right automatically (including sign extension)

@akkartik

Now that I took another look I figure out that it can be expressed very cleanly without grouping opcoded and without any opcode-specific logic in "survey" by allowing offsets in label-references:

# 32-bit relative jump# load upper 20 bits and add to PCauipc 5/rd/t0 label[31:12]/off32# jump, adding lower 12 bits jalr 0/rd/x0 5/rb/t0 label+4[11:0]/off32

the +4 is to account for the fact that PC was "captured" in the auipc instruction

@akkartikI still didn't arrive at Mu, but I'll try to catch up ;)

I was under the impression that the two-instruction relative long-jump aiupc+jalr could only work if SubV would recognize the two-instruction construct and generate the correct offsets in a "smart" way.

I think what I got wrong was that the PC is added in the "auipc" instruction, not when jalr is executed.

Got back into my SubV (#riscv assembler / machine-code language modelled after @akkartik's SubX) codebase this weekend.

I figured out pretty quickly that what seemed like a terrible problem and caused me to essentially drop it a year ago is actually... not a problem? So that's good news :)

Had to stop for now, but long jumps (absolute/relative with lui/auipc+jalr) can be expressed now.

You know what would be neat? An #activitypub server that can host multiple (small) instances.

Like if I want to have my own instance, and a bunch of my friends or some small groups that I am adjacent to but not necessarily a part of, the maintenance overhead of running e.g. a masto instance doesn't make that feasible to happen for each of those cases.

But if I could run one server, and then host people in their own space on common resources (storage, email api, image pipelines…) that'd work!

@csepp No! This looks very interesting!

(link for the lazy: https://github.com/tommythorn/Reduceron)