Tuesday, 2023-04-18

*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:54
*** sauce <sauce!~sauce@hollandaise.sauce.icu> has joined #libre-soc03:52
programmerjakelkcl: maybe mention extsb -- imho by the logic applied to *w insns word -> XLEN/2 it would sign extend the least significant XLEN/8 bits, which imho would be useful, similarly extsh, extsw extend XLEN/4 and XLEN/2 bits09:29
programmerjakesigning extending 1,2, and 4 bit fields in one instruction seems useful to me09:30
markossign-extend (8->16, 16->32, 32->64-bit) sounds like the movl instructions in Arm these are extremely useful when needing to increase accuracy in certain calculations, and are usually paired by the movn (narrowing)09:48
markoseg. the video data is in 8/16-bit but the calculations need to be done in 32-bit, so movl is used, then narrowed down with movn09:49
markosand because it's arm, you have a ton of those instructions, eg. qmovn (move with saturation), qmovun (move with saturation to unsigned), etc etc09:50
programmerjakepowerisa already has scalar sign extension instructions extsw/h/b, i'm just speculating how we might change them when given different srcelwid09:50
programmerjakecurrently we picked to always have extsb extend from 8 bits ignoring XLEN09:51
markosyes, I agree09:51
programmerjakewhich i think might be unnecessarily tying our hands09:51
markosyou might get packed data of 16-bit elements09:52
programmerjakeif you have 16-bit data and want to sign extend the lower 8-bits, with my speculative change you'd just use extsw with XLEN=1609:53
programmerjakeif you have 16-bit data and want to sign extend the lower 4-bits, with my speculative change you'd just use extsh with XLEN=1609:53
programmerjakeif you have 32-bit data and want to sign extend the lower 16-bits, with my speculative change you'd just use extsw with XLEN=3209:54
programmerjakeyeah, sometimes (bitfields and other stuff) you have 4 bit data09:54
markostbh I haven't seen such a use case, but if it's easy to do why not09:55
markosmost of the problems I've worked on are rather simpler09:55
markoseg. 8->16, 16->32, 32->6409:55
markosand you would need 2 instructions for those, or an extra option to take the lower/upper half of the original word09:56
programmerjaketraditionally 4-bit data would use (x << 60) >> 60 or similar to sign extend09:56
markosintel even has 8->32, 8->6409:57
markosin our case, one could create a set of 8 vector registers, straight from a single extend of 8->64 of a single source register with 8x8-bit elements09:58
programmerjakewell, scalar extsb is 8 -> 8/16/32/64, and extsh is 16 -> 16/32/64 since Power stores smaller ints in 64-bit regs09:58
programmerjakemy idea is to just proportionally shrink all sizes when using them on vectors with smaller element sizes09:59
markosyes, but that's scalar, what if you have packed 8-bit/16-bit data and want to sign-extend these elements? both intel and Arm provide such instructions for SIMD09:59
markossince we don't do SIMD, we could/should extend the functionality of the scalar functions to create vectors in this manner10:00
markosarbitrarily sized for that matter10:00
programmerjakeSVP64 allows setting different src/dest elwid, so just do whatever move/sign-extend op with different src/dest elwid10:00
markosso it's already possible?10:01
programmerjakenot 4-bit sign extension, but 8/16/32/64 -> any of 8/16/32/6410:01
markoseg. say I have 16x16-bit elements in packed mode, in 4 x 64-bit registers and I want to sign-extend them to 32-bit, that means I will need 8x 64-bit registers if they are still in packed mode10:03
markosis that possible now?10:03
programmerjakeeven in-place if you set reverse mode10:04
markosI'm constantly amazed by what SVP64 can do10:04
programmerjakeso, lkcl, what do you think of changing extsb/h/w to be:10:09
programmerjakeRA <- EXTSXL(RS, XLEN/N) for N = 8/4/2 rsspectively10:09
programmerjakeinstead of: RA <- EXTSXL(RS, N) for N = 8/16/32 respectively?10:09
programmerjakethat will strictly increase functionality10:10
programmerjakeactually i'll open a bug so we don't lose the idea10:11
markosprogrammerjake, I don't think it's possible to "sign" extend 1-bit numbers :)10:24
markosit would just have to be plain extend in such cases, even 4-bit is pushing it10:25
programmerjakeit totally is, you get either -1 or 010:25
markoswell possible in the mathematical sense, yes, but the usefulness of it is questionable though10:26
programmerjakesince imho a 1-bit 2s complement number has just the sign bit and nothing else10:26
programmerjakeit's quite useful, existing simd code really likes to use -1/0 for masks10:27
programmerjakethis makes a quick and easy way to generate those10:27
markosit's just 1 and 0 in masks, you don't treat the sign bit as a separate case10:27
markosdon't misunderstand me, I don't think it's a bad idea, far from it, I'm just referring to the "sign" naming10:28
programmerjakewell, 1-bit to 8-bit sign extension is basically just testing the lsb and splatting it to all 8 bits, whatever you call it it is commonly useful for traditional simd code10:28
markosyes I agree on that10:29
markosit's a way to emulate movemasks as on Intel10:29
programmerjakealso, do note the sign extension matches what verilog and probably vhdl do with 1-bit signed wires10:29
programmerjakeexcept intel takes it from the msb10:29
programmerjakeiirc arm uses the lsb for something like that10:30
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC11:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc11:26
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC11:41
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc11:42
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC13:39
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc14:39
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc14:40
lkclprogrammerjake, i like it. in fact i like it that much i'm going to include it in ls005 :)15:57
lkclalthough grevlut(i) will do a lot more than extsb/ew=816:19
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC17:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:16
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:36
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc17:36
*** octavius <octavius!~igloo@> has joined #libre-soc19:22
*** octavius <octavius!~igloo@> has quit IRC19:25
programmerjakelkcl: note that imho you waay overcomplicated the extsb pseudocode, i think it should just be: RT <- EXTSXL((RA), XLEN/8)19:51
programmerjakeit sign extends from the LSB 1/2/4/8-bits, not from the msb 1/2/4/8-bits of the lsb byte19:53
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:40
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC22:39
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc22:40
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC23:13
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc23:13
lkclthat is not its purpose23:18
lkclwithin the scope of this rfc.23:18
programmerjakei added the expanded pseudocode so you can easily see which bits go where, the short pseudocode is so people don't complain that it's much longer than necessary23:20
programmerjakei'll note you still have a syntax error with ]]23:20
programmerjakeimho having `in` as a temporary variable makes it more confusing hence why i removed it23:21
programmerjakee.g. you wrote if XLEN = 8  then RT <- in[7]] * 8 which has too many ]23:23

Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!