04:17 <wewd> question about the compressed instructions: if you have them available is there ever a reason not to use them? don't they almost always improve runtime performance and code size?

04:17 <wewd> also, C.NOP and probably more instructions could use 8-bit. Why don't they?

04:33 <sorear> there's no need to compress NOPs for performance and code size because you can just delete the NOPs instead. C.NOP exists for alignment purposes, if you want to consume space equal to an odd number of 2-byte instructions you need C.NOP

04:33 <sorear> an 8-bit NOP would be useful if and only if there were other 8-bit instructions

04:35 <wewd> oh, C.NOP is in fact the only instruction that could use 8 bits I guess

04:36 <sorear> could some instructions be 8-bit? maybe, but adding more instruction lengths results in a multiplicative increase to the complexity of instruction decoding. it's rather telling that the variable length instruction encoding was specified in 2014, yet ten years later there are no standard extensions using any size other than 16/32 bits and AFAIK no non-standard instructions either

04:36 <wewd> hmm yeah

04:36 <sorear> Hwacha used the 64-bit encoding as part of the vector unit instruction set, but the Hwacha vector instruction set is not a RISC-V superset and contains *only* 64 bit instructions, so I don't think it counts

04:38 <sorear> if you need to align something to a boundary, say because the tuning profile includes -falign-loops=4, it's probably better to decompress one instruction than to add a c.nop, depending on the implementation

04:39 <sorear> it's also useful to disable compressed instructions for a small block of code to make instruction lengths predictable, so that lengths match or pointer arithmetic can be used; examples are the Linux ALTERNATIVE() macro and some uses of Duff's device

04:40 <sorear> probably the biggest reason not to use them is not having them, or not wanting to commit to always having them

04:41 <sorear> does any of this help for your use case?

04:43 <wewd> makes sense

04:43 <wewd> yes

04:43 <wewd> it answers my questions

07:40 <pabs3> https://alastairreid.github.io/riscv-spec-issues/ https://news.ycombinator.com/item?id=40185065

12:15 <OwlWizard> do any of you know wether there has been any work done on risc-v sockets?

14:20 <Tenkawa> Ok.. the sdcard wouldn't try to boot at all.. I got an emmc to try to boot with the stock build of a vendor sdcard image but its still doing that same lock/disappeaiing act as before so unless I can find some way to completly eradicate OpenSBI and U-Boot from the nand I think its going to be stuck because I'm fairly certain this is the date of the build that made it inoperable (U-Boot SPL 2021.10 (Mar 14 2024 - 19:21:18 +0800)) I don't think

14:21 <Tenkawa> er I don't think its doing anything afterwards

14:24 <Tenkawa> It might not be using nand/spi at all looking

14:24 <Tenkawa> LPDDR4: 8G version: g8ad50857.

14:24 <Tenkawa> U-Boot SPL 2021.10 (Mar 14 2024 - 19:21:18 +0800)

14:24 <Tenkawa> Trying to boot from MMC1

14:24 <Tenkawa> OpenSBI v1.2

14:24 <Tenkawa> because it hangs after this (which it does) that has me suspicous

15:39 <drewfustini> Esmil: what do you think of https://github.com/revyos/thead-kernel/blob/lpi4a/drivers/clk/thead/clk-light-fm.c ?

15:40 <drewfustini> Esmil: I'm starting to wonder if that is a better base than the th1520 clk series that Yungtao Li originally created and I posted

15:41 <drewfustini> It at least seems more complete than https://lore.kernel.org/linux-riscv/20240426-th1520-clk-v2-v2-0-96b829e6fcee@tenstorrent.com/

15:41 <Esmil> drewfustini: i think so. but i'd still look into converting that to using the generic gate and mux implementations already in linux

15:42 <drewfustini> You think the vendor clk-light-fm is a better starting point?

15:42 <Esmil> ..but at least the data on clock parents etc. looks much more complete

15:42 <Esmil> yeah

15:43 <drewfustini> Thanks, I was starting to feel that way as I tried to improve Yangtao's code in the series I posted.

15:45 <drewfustini> I was having trouble deciding if the gates, dividers and muxes should actually be all in a single clock array index namespace.

15:48 <Esmil> i haven't looked closely at that driver yet, but from the datasheet it looked like it makes sense to have a driver for each of the memory ranges listed on page 205

15:49 <drewfustini> Yeah, that does seem like an appropriate way to organize

15:50 <drewfustini> With in those subsystem groups, do you think that the dividers, gates and muxes should be separate clock arrays too?

15:51 <Esmil> yes

15:51 <drewfustini> Thanks. The code I posted just has one array for AP_SUBSYS which I was starting to find confusing

15:52 <drewfustini> I couldn't see a way to use the generic mux and gate register functions if everything was just in one clock array

15:52 <Esmil> from the data sheet it looks like each of those ranges have one or two PLLs that takes the 24MHz oscillator as input and then the rest of the clocks ccontrolled from the same range are derived from those PLLs

15:57 <drewfustini> Yes. And I remember your comment about how FOUTVCO and the FOUTPOSTDIV could be modelled as separate clocks

15:57 <Esmil> right. i think even the driver you just linked does that

15:58 <Esmil> hmm.. maybe only for the VIDEO_PLL

23:29 <drmpeg> Got one of those ginormous Waveshare heat sinks for the VF2. Building Linux now.