| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 00:17 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:22 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:54 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 02:09 | |
| sadoon[m] | <programmerjake> "in theory mounting a ext4..." <- True, I'm constructing a disk image which should work fine | 05:06 |
|---|---|---|
| ghostmansd[m] | lkcl, could you, please, remind, why do we "split" registers by type (s and d) in remap? | 06:38 |
| ghostmansd[m] | The records are in form s:X;b:Y. | 06:39 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 06:40 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:06 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:14 | |
| ghostmansd | lkcl, I've started checking svshape2 | 08:59 |
| programmerjake | lkcl: discovered we forgot fp min/max, see #923 | 08:59 |
| ghostmansd | My first remark is, offs is a bad name, it's way too broad and likely will interfere with something in binutils. | 09:00 |
| programmerjake | i'm going to try to get to bed sorta on-time, so gn all | 09:00 |
| ghostmansd | How about SVo or SVO? | 09:00 |
| ghostmansd | I'll use this form in binutils for now. | 09:05 |
| ghostmansd | SVO | 09:05 |
| ghostmansd | It's a pity that 23 bit for yx ix occupied... | 09:07 |
| ghostmansd | We split XO field. This is not something traditionally present; I only managed to find XX3 instructions from VSX which do it. I suspect this was already discussed and this is the only option, but still: could this be contiguous? | 09:26 |
| ghostmansd | SVM2 has this form: |0 |6 |10|11 |16 |21 |24|25 |26 |31 | | 09:34 |
| ghostmansd | There's nothing though which uses bit 31. Is it reserved for future extensions? | 09:34 |
| programmerjake | setvl uses that for Rc iirc...maybe it's reserved for consistency? | 09:36 |
| programmerjake | i'd have to look | 09:36 |
| ghostmansd | Perhaps. I think it's just and adopted from some other insn. | 09:43 |
| ghostmansd | Or reserved for future extension purposes. | 09:43 |
| ghostmansd | We also lack all bitmanip instructions from opcode 22. Should these be added, too? | 09:50 |
| ghostmansd | Also, do we have some way to identify whether the 32-bit instruction is present only in SVP64? I guess it's "unofficial" field, right? | 09:53 |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc | 11:45 | |
| lkcl | ghostmansd, "s:" means "source" and "d:" means "destination". source will be in1/2/3 or CRin, dest will be out1/out2 or CRout *or* CR0/CR1 (for Rc=1) | 11:59 |
| lkcl | programmerjake, yep indexed/offset makes sense for DSP/AV level | 12:00 |
| ghostmansd[m] | I know what these mean :-) | 12:01 |
| ghostmansd[m] | What do these affect? | 12:01 |
| lkcl | ahh :) | 12:01 |
| ghostmansd[m] | I always traverse all operands | 12:02 |
| ghostmansd[m] | Regardless of in/out | 12:02 |
| lkcl | ok, so this needs some explanation of Twin-Predication | 12:02 |
| lkcl | you know about predicate masks in other Vector/SIMD ISAs? | 12:02 |
| ghostmansd[m] | Not at all | 12:02 |
| lkcl | ok. | 12:02 |
| lkcl | so you have a sequence of operations (on elements) | 12:02 |
| lkcl | you want to skip some of them | 12:02 |
| lkcl | how would you do that? | 12:02 |
| ghostmansd[m] | That's why I asked for high level introduction to common vector ISA concepts | 12:02 |
| ghostmansd[m] | What do you mean by skip? | 12:03 |
| ghostmansd[m] | Let's perhaps choose some insn, say add | 12:03 |
| lkcl | not write out element 5 for example | 12:03 |
| lkcl | sv.add/pm=r3 *RT,*RA,*RB | 12:03 |
| lkcl | where VL=8 | 12:03 |
| lkcl | at *runtime* you know that you *do not* want to write out to element 5. | 12:03 |
| ghostmansd[m] | And let's literally translate what we mean here? | 12:04 |
| lkcl | you want it left alone | 12:04 |
| ghostmansd[m] | What does this insn do? | 12:04 |
| ghostmansd[m] | Add all elements from vector RA to vector RB and put to RT? | 12:04 |
| lkcl | when VL=8 it *conditionally* performs 8 adds | 12:04 |
| ghostmansd[m] | So we have vec of 8 elements | 12:04 |
| lkcl | checking *each bit* of r3 to decide whether the *element* operation is allowed to be carried out | 12:05 |
| lkcl | for i in range(VL): | 12:05 |
| lkcl | if r3[1<<i]: GPR(RT+i) = GPR(RA+i) + GPR(RB+i) | 12:05 |
| lkcl | the crucial bit is that *conditional* check | 12:05 |
| ghostmansd[m] | Aha, good | 12:05 |
| lkcl | in SIMD ISAs this is termed "PredicatedSIMD" | 12:06 |
| ghostmansd[m] | So that's mask what to check | 12:06 |
| lkcl | it's absolutely standard fare for pretty much every single 3D GPU on the planet. | 12:06 |
| ghostmansd[m] | If bit X is set, do op on bit X | 12:06 |
| ghostmansd[m] | It's not like that I used it :-) | 12:06 |
| lkcl | if bit X is set do op on *element* X | 12:06 |
| ghostmansd[m] | Seriously, I lack fundamental concepts | 12:06 |
| ghostmansd[m] | Oops, yes, element X | 12:06 |
| ghostmansd[m] | Sorry, I meant this | 12:07 |
| lkcl | not a problem, it's pretty easy to explain. | 12:07 |
| lkcl | so the next step up from that - which you will *not* find in any other ISA - is: Twin-Predication | 12:07 |
| ghostmansd[m] | Aha, OK | 12:07 |
| lkcl | for that you have now effectively *two* for-loops, twinned/entwined inside each other | 12:07 |
| lkcl | one predicate mask is for the SOURCE operands | 12:08 |
| lkcl | the other predicate mask is for the DESTINATION operands | 12:08 |
| lkcl | and they *both* can "skip", completely independently | 12:08 |
| lkcl | so | 12:08 |
| lkcl | let's say that we have sv.add/sm=r3/dm=r10 *RT,*RA,*RB | 12:08 |
| lkcl | that VL=4 | 12:08 |
| lkcl | that r3=0b0111 | 12:09 |
| lkcl | and r10=0b1101 | 12:09 |
| lkcl | the *SOURCE* indices will be | 12:09 |
| lkcl | hang on | 12:09 |
| lkcl | the for-loop to VL will go | 12:09 |
| lkcl | [0 1 2 3] | 12:09 |
| lkcl | the SOURCE indices will be | 12:09 |
| lkcl | [0 1 2 X] where X is "skip" | 12:10 |
| lkcl | the DESTINATION indices will be | 12:10 |
| lkcl | [0 X 2 3] (again X is "skip") | 12:10 |
| lkcl | which thunks down to | 12:10 |
| lkcl | src: [0 1 2] | 12:10 |
| lkcl | dst: [0 2 3] | 12:10 |
| lkcl | and thus you will have the following operations performed | 12:10 |
| lkcl | ADD r0,r0,r0 | 12:11 |
| lkcl | ADD r1,r2,r2 | 12:11 |
| lkcl | ADD r2,r3,r3 | 12:11 |
| ghostmansd[m] | Wow | 12:11 |
| lkcl | :) | 12:11 |
| ghostmansd[m] | That's really cool | 12:11 |
| lkcl | yes. | 12:12 |
| lkcl | it basically combined "VGATHER" and "VSCATTER" into one | 12:12 |
| lkcl | the src has been "GATHERED" | 12:12 |
| ghostmansd[m] | Funny though that someone who has that little knowledge about vectors does incorporate their support to binutils, eh? | 12:12 |
| lkcl | the dst has been "SCATTERED" | 12:12 |
| lkcl | uh-huhn :) | 12:12 |
| lkcl | well it's surprisingly little actually needed, because it's just data-manipulation | 12:13 |
| lkcl | ok so are you with me so far? | 12:13 |
| ghostmansd[m] | Ok, so we basically need these for predicates? | 12:13 |
| lkcl | yes | 12:13 |
| lkcl | but | 12:13 |
| ghostmansd[m] | Because, well, remap doesn't use it | 12:13 |
| ghostmansd[m] | I mean src/dst | 12:13 |
| lkcl | for supporting the src-indexing and dst-indexing in hardware and in Simulators as a Finite State Machine | 12:13 |
| lkcl | you need *TWO* separate indices | 12:13 |
| lkcl | one called srcstep | 12:14 |
| lkcl | the other called dststep | 12:14 |
| lkcl | you can't possibly do Twin Predication without keeping track separately of the amount that src is incrementing (or skipping) - where src is in the for-loop | 12:14 |
| lkcl | from dst | 12:15 |
| lkcl | and | 12:15 |
| lkcl | finally to answer your question | 12:15 |
| lkcl | d: refers to the need to use *dststep* | 12:15 |
| lkcl | and s: refers to the need to use *srcstep* | 12:15 |
| lkcl | in hardware. | 12:15 |
| lkcl | wek | 12:16 |
| lkcl | well... ahh... you _say_ REMAP doesn't need/use predication... but... ah... :) | 12:16 |
| lkcl | it's emerged very recently that the different REMAP types might need it. but it will be in SPRs. | 12:16 |
| lkcl | i take it you are presently running around screaming as your brain has melted | 12:18 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:27 | |
| ghostmansd[m] | Aaaaah no please not yet another remap journey | 12:37 |
| ghostmansd[m] | But other than that... it's really cool | 12:37 |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 12:42 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 12:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 12:50 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.225> has joined #libre-soc | 12:53 | |
| lkcl | :) | 12:54 |
| lkcl | brain-overload is a common syndrome with SV. including me. | 12:54 |
| lkcl | it's only sheer bloody-minded persistence of development/review of accumulated concepts that's got this far | 12:55 |
| lkcl | so, ghostmansd[m], transcendentals is probably the most sensible thing to look at. | 12:55 |
| lkcl | it's pretty boring / by-the-numbers | 12:55 |
| lkcl | (which is a refreshing change) | 12:56 |
| ghostmansd[m] | Ok will check | 13:03 |
| ghostmansd[m] | https://libre-soc.org/irclog/%23libre-soc.2022-09-08.log.html#t2022-09-08T08:59:19 | 13:03 |
| ghostmansd[m] | lkcl could you please also check this thread too? I think I will complete this today. | 13:04 |
| lkcl | SVo is great. | 13:05 |
| ghostmansd[m] | This task to me is like hanging to an investigators | 13:05 |
| ghostmansd[m] | Ok I'll update it when I get to it | 13:09 |
| ghostmansd[m] | Don't waste time on this :-) | 13:10 |
| lkcl | if you can add these assertions into binutils-svshape | 13:10 |
| lkcl | assert SVrm not in [0b1000, 0b1001], \ | 13:10 |
| lkcl | then that's one task closed and an RFP can be submitted | 13:10 |
| lkcl | https://bugs.libre-soc.org/show_bug.cgi?id=911 | 13:11 |
| ghostmansd[m] | Sure, this will need a custom callback IIRC | 13:13 |
| ghostmansd[m] | I will get to this in the evening | 13:13 |
| lkcl | ack | 13:13 |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 14:26 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 14:27 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.225> has quit IRC | 15:15 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@nat.222-104.maryno.net> has joined #libre-soc | 15:16 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@nat.222-104.maryno.net> has quit IRC | 15:19 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.225> has joined #libre-soc | 15:19 | |
| *** tplaten <tplaten!~isengaara@55d4441e.access.ecotel.net> has joined #libre-soc | 16:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.160.225> has quit IRC | 16:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:27 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:43 | |
| ghostmansd[m] | lkcl, I'm confused. Task 911 is about svshape2, but there's no SVrm field at all. Do you mean another task? | 16:45 |
| *** octavius <octavius!~octavius@224.147.93.209.dyn.plus.net> has joined #libre-soc | 17:17 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 17:28 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc | 17:41 | |
| lkcl | ghostmansd, sorry - svshape2 sits *inside* the two reserved values of svshape's SVRM=[0b1000, 0b1001]. | 17:43 |
| lkcl | therefore it is *svshape* that must be checked to stop ob1000 and 0b1001 from being allowed | 17:43 |
| lkcl | (and svshape2 must set the XO to 0b100---1somethingsomething] | 17:44 |
| ghostmansd | svshape needs changes | 17:52 |
| ghostmansd | Holy fuck how I hate MSB0 | 17:52 |
| ghostmansd | Sooo annoying to count these bits and at the same time convert ranges to mask | 17:53 |
| ghostmansd | You know what? I won't do it in the future. This is already a sufficient reason to generate the code. | 17:53 |
| ghostmansd | The split XO makes it particularly difficult. | 18:00 |
| ghostmansd | Only if I put the svshape2 opcode before svshape it works in disassembly. | 18:01 |
| ghostmansd | I will keep it like this and add checks in callbacks. | 18:02 |
| ghostmansd | Just to clarify. The field SVrm is present only in svshape for now, and I will ban 0b1000 and 0b1001 for this field entirely. | 18:03 |
| ghostmansd | In the unlikely scenario that we have SVrm in another instruction where these values are permitted, we'll have to introduce another field, preferably named differently. I already had to rename yx field to yx10, due to the fact binutils already have yx field with different description. | 18:05 |
| ghostmansd | Luckily we're not the first to employ this trick. | 18:06 |
| ghostmansd | OK I think this is done, I'll submit the patch. It's tricky a bit due to split XO field and these 0b1000/0b1001 overlaps, but otherwise is pretty straightforward. | 18:36 |
| lkcl | whewww | 18:38 |
| lkcl | i have no problem renaming yx to something else (xy?) | 18:38 |
| lkcl | and there was that other one, SVo | 18:38 |
| ghostmansd | Called it yx10 | 18:38 |
| * lkcl head spinning writing an rfc | 18:39 | |
| ghostmansd | SVo is renamed, I'm almost done with the patch for openpower-isa, but I'll push it to standalone branch to make sure nothing's broken. | 18:39 |
| ghostmansd | For yx10, we're not the only ones playing such dirty games with idiotic names, so I think we're safe. | 18:40 |
| lkcl | ack | 18:40 |
| lkcl | mmm i'd just rather not have them | 18:40 |
| lkcl | https://libre-soc.org/openpower/sv/rfc/ls001/ | 18:40 |
| ghostmansd | Hm. Luke https://libre-soc.org/openpower/sv/remap/#svshape2 lists also inv field. | 18:41 |
| ghostmansd | So the range for SVo is not 6..9, but rather 6..8. | 18:41 |
| ghostmansd | I think fields.text is the higher priority and the docs are simply not updated yet. Is this assumption correct? | 18:42 |
| ghostmansd | How about calling yx for SVM2 SVM2d? | 18:44 |
| ghostmansd | Or SVM2yx | 18:44 |
| ghostmansd | Chose SVM2yx for now | 18:49 |
| ghostmansd | lkcl, openpower-isa branch svshape2-fixup | 19:02 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 19:07 | |
| lkcl | a bit long | 19:10 |
| *** octavius <octavius!~octavius@224.147.93.209.dyn.plus.net> has quit IRC | 19:12 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 19:38 | |
| *** octavius <octavius!~octavius@224.147.93.209.dyn.plus.net> has joined #libre-soc | 19:52 | |
| ghostmansd[m] | Ideas are welcome :-) | 20:06 |
| ghostmansd[m] | I've already submitted to binutils, but I have a feeling that I'll have to update the patch anyway | 20:07 |
| ghostmansd[m] | And, even if not, should the good name come to our heads, I'll update anyway | 20:07 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 21:05 | |
| *** octavius <octavius!~octavius@224.147.93.209.dyn.plus.net> has quit IRC | 21:11 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 22:09 | |
| *** octavius <octavius!~octavius@224.147.93.209.dyn.plus.net> has joined #libre-soc | 22:15 | |
| lkcl | SVyx and SVo is good. btw you forgot to alter the pseudocode. variables used that don't exist: baaaad | 22:26 |
| lkcl | :) | 22:26 |
| lkcl | test_caller_*.py underway, 15min | 22:26 |
| ghostmansd | Ah yes | 22:43 |
| ghostmansd | Sorry | 22:43 |
| ghostmansd | CR_index = 7-(BA>>2) # top 3 bits but BE | 22:43 |
| ghostmansd | bit_index = 3-(BA & 0b11) # low 2 bits but BE | 22:43 |
| ghostmansd | CR_reg = CR{CR_index} # get the CR | 22:43 |
| ghostmansd | I cannot find equivalent for this in src/openpower/decoder/power_svp64_extra.py | 22:44 |
| ghostmansd | It seems that by the time we enter SVP64CRExtra spec is already 3-bit | 22:44 |
| ghostmansd | On the other hand, I think the pseudocode below is complete | 22:45 |
| ghostmansd | return ((BA >> 2)<<6) | # hi 3 bits shifted up | 22:45 |
| ghostmansd | (spec[1:2]<<4) | # to make room for these | 22:45 |
| ghostmansd | (BA & 0b11) # CR_bit on the end | 22:45 |
| ghostmansd | # scalar constructs "00 spec[1:2] BA[0:4]" | 22:45 |
| ghostmansd | return (spec[1:2] << 5) | BA | 22:45 |
| ghostmansd | I'll use that one | 22:46 |
| ghostmansd | A question on this: how to check? Some particular insn you have in mind? | 22:46 |
| ghostmansd | lkcl ^ | 22:46 |
| lkcl | ghostmansd, 1 sec let me check.... probably isel? | 23:27 |
| lkcl | isel RT,RA,RB,BC | 23:28 |
| lkcl | yep, that's BC | 23:28 |
| lkcl | BC there is *5* bit, remember, though | 23:28 |
| ghostmansd | Yeah | 23:29 |
| lkcl | so for that you take the top 5 bits... | 23:29 |
| ghostmansd | I got that from pseudocode :-) | 23:29 |
| lkcl | 1 sec... on svp64extra... | 23:29 |
| lkcl | ah right - i cheated :) | 23:29 |
| lkcl | because they're identical (BA 5-bit and BFA 3-bit) if you drop the bottom 2 bits | 23:30 |
| lkcl | can use SVP64CRExtra by chopping off 2-bits from BA, running the top 3-bits through SVP64CRExtra, then putting the bottom 2-bits *back* on the LSBs | 23:30 |
| ghostmansd | aha | 23:31 |
| lkcl | all good on svshape2-fixup btw (rebased into master already) | 23:32 |
| ghostmansd | how long ago this has been tested? | 23:34 |
| ghostmansd | File "/home/ghostmansd/src/openpower-isa/src/openpower/sv/trans/svp64.py", line 657, in crf_extra | 23:34 |
| ghostmansd | (rname, str(extras[extra_idx])) | 23:34 |
| ghostmansd | NameError: name 'rname' is not define | 23:34 |
| ghostmansd | tried pysvp64asm on this code | 23:34 |
| ghostmansd | sv.isel 4, 1, 2, 31 | 23:34 |
| ghostmansd | sv.isel 4, 1, 2, 63 | 23:34 |
| ghostmansd | sv.isel 4, 1, 2, *31 | 23:34 |
| ghostmansd | sv.isel 4, 1, 2, *63 | 23:34 |
| lkcl | doh | 23:35 |
| lkcl | 1 sec | 23:35 |
| ghostmansd | aha, I know | 23:35 |
| ghostmansd | I'll push the fix | 23:35 |
| lkcl | ack | 23:36 |
| ghostmansd | missing arg | 23:36 |
| lkcl | ah you see what happened, there? | 23:36 |
| lkcl | 31 has LSBs that cannot fit into the numbering of EXTRA2/3 | 23:36 |
| lkcl | https://libre-soc.org/openpower/sv/svp64/#index13h1 | 23:37 |
| lkcl | 13.3 and 13.4 | 23:37 |
| lkcl | ok sv.isel is almost certainly an EXTRA2, because it is 4-operand | 23:37 |
| lkcl | openpower/isatables/RM-1P-3S1D.csv:isel,NORMAL,,1P,EXTRA2,d: | 23:37 |
| lkcl | yyep | 23:37 |
| lkcl | so that means 13.4 CR EXTRA2 | 23:38 |
| ghostmansd | OK, and something extra3? | 23:38 |
| ghostmansd | (these are the same with GPR/FPR though, the code is shared) | 23:38 |
| ghostmansd | or, well, the same | 23:38 |
| lkcl | and the scalar numbering can *only* go up to CR15 | 23:38 |
| lkcl | but | 23:38 |
| lkcl | ermermermerm... | 23:38 |
| lkcl | you have to chop off the bottom 2 LSBs of the number 31 | 23:39 |
| lkcl | 31>>2 = 7! | 23:39 |
| lkcl | so that should be perfectly fine | 23:39 |
| lkcl | buuuuuug.... | 23:39 |
| lkcl | good .long 0x05400000; isel 4, 1, 2, 31 # sv.isel 4,1,2,31 | 23:39 |
| lkcl | good .long 0x05400040; isel 4, 1, 2, 31 # sv.isel 4,1,2,63 | 23:40 |
| ghostmansd | I assume you already pushed it? | 23:40 |
| lkcl | bad sv.isel 4, 1, 2, *31 | 23:40 |
| lkcl | let's work it out | 23:40 |
| ghostmansd | I mean pysvp64asm fix | 23:40 |
| lkcl | no, haven't changed anything. | 23:40 |
| ghostmansd | if you managed to obtain the assembly | 23:40 |
| lkcl | ok so that is a 31. | 23:41 |
| lkcl | shifted down by 2 is 7. | 23:41 |
| lkcl | ah | 23:41 |
| lkcl | i know | 23:41 |
| lkcl | Note that Vectors may only start from CR0, CR8, CR16, CR24, CR32... | 23:41 |
| lkcl | is CR7 in that list? | 23:41 |
| lkcl | no it is not | 23:41 |
| lkcl | so this is a correct assertion. | 23:41 |
| ghostmansd | ah OK the same as with regs | 23:41 |
| lkcl | you need to use CR8 | 23:41 |
| lkcl | yes but lovingly-confusingly you have to shift CR8 *back* up by 2, then put the 2 LSBs on (you picked 0b11) | 23:42 |
| lkcl | so... 35 | 23:42 |
| lkcl | if you try sv.isel 4,1,2,*35 it should work | 23:42 |
| lkcl | .long 0x054000c0; isel 4, 1, 2, 3 # sv.isel 4,1,2,*35 | 23:42 |
| lkcl | ta-daaa | 23:42 |
| lkcl | now let's try 63 - same logic | 23:42 |
| ghostmansd | how do you manage to get asm working?? | 23:43 |
| lkcl | 63>>2 = 15 | 23:43 |
| lkcl | by avoiding the bug :) | 23:43 |
| lkcl | 1 sec | 23:43 |
| ghostmansd | ah OK | 23:43 |
| ghostmansd | I pushed the fix to master | 23:44 |
| lkcl | ok so let's go back to sv.isel 4, 1, 2, *63 | 23:46 |
| lkcl | 63>>2=15 | 23:46 |
| lkcl | 15 is not in the list CR0,CR8,CR16,.... | 23:46 |
| lkcl | so let's pick CR16 instead | 23:46 |
| lkcl | shift that up by 2 | 23:46 |
| lkcl | 64 | 23:46 |
| lkcl | and OR with 0b11 | 23:46 |
| lkcl | 67. | 23:46 |
| lkcl | let's try that | 23:46 |
| lkcl | .long 0x05400080; isel 4, 1, 2, 7 # sv.isel 4, 1, 2, *67 | 23:47 |
| lkcl | ta-daaaa | 23:47 |
| ghostmansd | cool | 23:47 |
| ghostmansd | thank you! | 23:47 |
| ghostmansd | I'll try some code I have on these | 23:47 |
| ghostmansd | fuck insndb can't find isel | 23:50 |
| ghostmansd | or well, strictly speaking, match the opcode | 23:51 |
| ghostmansd | isel 0x54000007c8117de FieldsOpcode(value=0x7c00001e, mask=0xfc0007fe) | 23:52 |
| ghostmansd | the first hex is what we want to match, then goes what we had for isel | 23:52 |
| ghostmansd | OK I think I'll sort it out tomorrow, 2 AM here | 23:53 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!