| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 00:04 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:18 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 02:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 03:14 | |
| *** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 06:59 | |
| *** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 07:53 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:16 | |
| ghostmansd | programmerjake, lkcl, I came to conclusion that the original assembly is wrong. | 08:57 |
|---|---|---|
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=HEAD#l1541 | 08:57 |
| ghostmansd | Let's assume I have instruction `sv.fdmadds 4,3,2,1`. | 08:58 |
| ghostmansd | If I print `v30b_newfields`, I get `4,3,2,1`. Fields do not get reordered. | 08:59 |
| ghostmansd | That is, fields which come as FRT,FRA,FRC,FRB are _not_ reordered into FRT,FRA,FRB,FRC, as prescribed by the specs. | 09:01 |
| programmerjake | looks to me as though that code is wrong, i'd expect it to match powerisa fma ops, i'd guess whoever wrote it forgot that FRB and FRC are swapped in the assembly syntax | 09:01 |
| programmerjake | i'll leave it to luke to figure out what to do, i'm going to sleep, it's 1 am here. | 09:05 |
| ghostmansd | Well, the quick fix is to swap the v30b_newfields[2] and v30b_newfields[3]. But this will break some tests: test_sv_ffadds_dct and test_sv_fpmadds_fft. | 09:05 |
| ghostmansd | Ah right, sorry, I always forget about the time zones. | 09:05 |
| ghostmansd | Good night! | 09:06 |
| *** Ritish <Ritish!~Ritish@115.97.41.186> has joined #libre-soc | 09:28 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 09:33 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 09:39 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 09:40 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 09:40 | |
| *** octavius <octavius!~octavius@92.40.169.72.threembb.co.uk> has joined #libre-soc | 09:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 09:53 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 09:53 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 09:56 | |
| lkcl | do not whatever you do modify the ordering. | 10:46 |
| lkcl | under no circumstances. | 10:46 |
| lkcl | the DCT/FFT code is incredibly complex and the consequences of any modification will result in a massive cascade | 10:47 |
| lkcl | i'm in no way prepared to go through that. it was many months in the first place. | 10:47 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:49 | |
| *** octavius <octavius!~octavius@92.40.169.72.threembb.co.uk> has quit IRC | 11:00 | |
| *** Ritish <Ritish!~Ritish@115.97.41.186> has quit IRC | 11:44 | |
| *** Ritish <Ritish!~Ritish@115.97.41.186> has joined #libre-soc | 11:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:54 | |
| *** Ritish <Ritish!~Ritish@115.97.41.186> has quit IRC | 12:25 | |
| *** octavius <octavius!~octavius@92.40.168.44.threembb.co.uk> has joined #libre-soc | 12:38 | |
| octavius | I was looking at the hello_world.c (from Microwatt, also used in ls2), and the readl/writel functions used to load/store from/to memory using the Power instructions lwzcix and stwcix. | 12:38 |
| octavius | Found these instructions in the spec (3.0C), section 5.4.1. | 12:38 |
| octavius | The spec says that these instructions produced defined results only if "the specified storage location is Caching Inhibited and Guarded." | 12:38 |
| octavius | Does this mean that the storage locations must not be connected to the CPU via a cache? | 12:38 |
| octavius | The programming note does say these ld/st instructions are "used to permit a control register on an I/O device to be accessed without permitting the corresponding storage location to be copied into the caches" | 12:38 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:27 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:00 | |
| lkcl | no, it means that *if* there is a cache it must be write-thru | 14:19 |
| octavius | Ah ok | 14:23 |
| *** octavius <octavius!~octavius@92.40.168.44.threembb.co.uk> has quit IRC | 14:28 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 14:32 | |
| *** octavius <octavius!~octavius@92.40.168.44.threembb.co.uk> has joined #libre-soc | 14:36 | |
| *** octavius <octavius!~octavius@92.40.168.44.threembb.co.uk> has quit IRC | 14:38 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:39 | |
| ghostmansd | lkcl, please stop these "in no way" | 14:44 |
| ghostmansd | Again: this contradicts to spec. | 14:44 |
| ghostmansd | Please fix the test accordingly, it is a show stopper. | 14:45 |
| ghostmansd | Unless the operand order is FRT,FRA,FRB,FRC, your assembler code is wrong, and so are the tests. | 14:46 |
| ghostmansd | You put FRB where FRC resides. Please consider investigating the topic before submitting the reply. | 14:47 |
| ghostmansd | The topic starts here: https://libre-soc.org/irclog/%23libre-soc.2023-01-20.log.html#t2023-01-20T08:57:32 | 14:50 |
| ghostmansd | If you have other options, like reordering the operands, let me know. | 14:54 |
| ghostmansd | Otherwise this is counterproductive and brings nothing useful to dicussion. | 14:54 |
| lkcl | i am not going to change the instruction nor the unit test because the cascade of dependencies is so vast and complex | 15:35 |
| lkcl | the unit test passes, therefore there has to be an absolute show-stopper reason | 15:36 |
| lkcl | there is a *convention* from IBM about the order of operands and what they mean | 15:36 |
| lkcl | if i made a mistake by not following that convention, then it's too late now. i'm not prepared to do the massive amount of work needed to change it | 15:38 |
| lkcl | the reason is that these instructions are closely inter-related and also tied in to the REMAP system | 15:38 |
| markos | won't IBM themselves complain about the spec not being followed? | 15:43 |
| ghostmansd | Well, they likely won't, these instructions are ours | 15:53 |
| ghostmansd | And that's the exact reason why I asked whether we can change the operands order for the first place | 15:54 |
| ghostmansd | But it appears that "no ways" start before even reading the discussion. | 15:54 |
| ghostmansd | I'm adding a big FIXME. And leaving it with you. | 15:55 |
| markos | well, I'm of the opinion that such changes need to happen early if at all | 15:55 |
| ghostmansd | I don't have either time or patience to deal with it now. | 15:55 |
| markos | I wouldn't mind doing the fix myself on dct/fft, if anything it would help me get me understand this part of the code, which I want to anyway, if I am to contribute anything back to it | 15:56 |
| markos | argh, s/help me get me/help me/ | 15:57 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 16:06 | |
| *** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 16:07 | |
| ghostmansd | markos, the latest commit into insndb branch shows what happens: https://git.libre-soc.org/?p=openpower-isa.git;a=blobdiff;f=src/openpower/decoder/power_insn.py;h=1939acbfaed14afa1025e17ca88f182601f312f0;hp=a53e2195b7874bacb60475c93322f84ff6f01e5a;hb=b2dff8d50464e374577a8279298d90d378960450;hpb=8b434d31042fa489b4a19dade4bbc5a170265dfa | 16:12 |
| ghostmansd | The logic you see here follows the original assembler from master branch: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=c61e92833d696d46c50bf715c898b33a3100aa49;hb=refs/heads/master#l1541 | 16:13 |
| ghostmansd | Now, starting from this line: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/power_insn.py;h=1939acbfaed14afa1025e17ca88f182601f312f0;hb=1939acbfaed14afa1025e17ca88f182601f312f0#l620 | 16:14 |
| ghostmansd | We add several custom instructions which have some operands with special logic which needs to be explicitly enabled. | 16:14 |
| ghostmansd | ffmadds et al. use FMAOperandFRB class for FRB operand and FMAOperandFRC for FRC operands | 16:15 |
| ghostmansd | These all come from openpower/isa/svfparith.mdwn tables; when we parse this file, we obtain a list of operands (including "static" ones, like Rc) | 16:16 |
| ghostmansd | Each of these operands then is wrapped into some class implementing assembly/disassembly logic. | 16:16 |
| ghostmansd | And some operands are custom. They can be custom for a specific instruction (custom_insns array), some can be always specific (custom_fields), and some are always specific and marked as immediates (that is, they are used together in X(Y) syntax). | 16:26 |
| ghostmansd | But, before changing this part, please discuss it with Luke. | 16:26 |
| markos | not going to change anything yet, anyway, would have to study the code extensively to understand how it works, before that happens | 16:30 |
| *** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 16:33 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:42 | |
| ghostmansd[m] | markos, sure! Ping me if you need some help or have some issues with the assembly part. | 17:04 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:15 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:43 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:57 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 17:59 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 18:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:45 | |
| lkcl | markos, well in the case of the dual-butterfly ones, i think a case can be made that it doesn't matter. or, because implicit-FRS/RS is involved, those conventions can be discarded | 20:17 |
| lkcl | BUT | 20:17 |
| lkcl | there is actually a reason: | 20:17 |
| lkcl | by arranging the registers in the order in which they are arranged | 20:17 |
| lkcl | one single svshape instruction - specifying which of the 4 shapes apply to which of 5 registers - can cover *more than one instruction* | 20:18 |
| lkcl | if the registers are rearranged "to suit conventions" it requires *TWO* svshape instructions | 20:18 |
| markos | as usual, if there is a reasoning to break convention then it's fine, conventions are made to be broken anyway :) | 20:19 |
| lkcl | given that that represents a whopping 33% increase in instructions in a couple of cases, that's "a good case for disregarding whatever historic conventions were used formerly" | 20:19 |
| markos | my volunteering was just in the case that it was made by accident and you don't want to mess with the particular part of the code, it's not that I *want* to fix it | 20:20 |
| lkcl | ghostmansd, it's that i have to recall a massive stack of heavily in-depth coding which because of my memory problems it takes far longer to recall what was even done than you or anyone else would expect | 20:21 |
| markos | even if IBM complained for breaking convension, avoiding 33% increase in instruction count is a pretty good argument to be made | 20:21 |
| lkcl | that was a 3-instruction case (maybe 4), where the extra svshape instruction obviously increases to 4 (maybe 5) | 20:22 |
| lkcl | there's a couple like that in the DCT/FFT code, where by a really nice coincidence as i was designing ffmadds (etc.) a result turned out to be in exactly the right-named register as an input operand needing exactly the same svshape... | 20:23 |
| lkcl | the required svshape could be assigned to FRB *once and only once* | 20:23 |
| lkcl | (or whatever) | 20:23 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:23 | |
| markos | perhaps it would be best to add this note there to avoid revisiting the issue in the future? | 20:24 |
| lkcl | some similar logic went into the design of the LD/ST and shift-and-mask instructions as far back as the early 90s when Power ISA was first designed | 20:24 |
| lkcl | they had absolutely no way they could duplicate a shift-and-mask unit inside LD/ST - far too many gates | 20:25 |
| lkcl | so they arranged RA RB RC RS and RT to be "broadcast lanes" | 20:25 |
| lkcl | then *micro-coded* LD/ST as a *pair* of operations | 20:25 |
| lkcl | first operation: get the data | 20:25 |
| lkcl | second operation: broadcast the *unaligned* data onto one of the "operand lane" buses as a *direct* input to the shift-and-mask pipeline, BYPASSING the register file but using the exact same input | 20:26 |
| lkcl | this is why you have the weird register names in the first place | 20:27 |
| lkcl | sorry | 20:27 |
| lkcl | operand names | 20:27 |
| lkcl | ghostmansd, regarding those mappings: i cannot talk about what is being discussed confidentially in the OPF ISA WG. that's as much as i can say until a new revision is released | 20:31 |
| lkcl | we _can_ talk again about the mappings when the new revision is released. | 20:32 |
| ghostmansd[m] | At this point, I want to ensure that things work (they already mostly do, but some tests still need to be fixed). If I find some issue in the underlying code, I will for now resort to following the same behavioral patterns as the old code did. | 21:56 |
| ghostmansd[m] | But still I cannot avoid raising these topics, because sometimes these topics are real issues. | 21:56 |
| ghostmansd[m] | However, one point. Before answering to any thread, please _read_ it. I literally spent three months of debugging and developing this, and I cannot treat the reply "in no way" or "I don't have time to explain yet" as a satisfactory one. | 21:59 |
| ghostmansd[m] | This is unethical considering all the time I spent and all the efforts and patience I had. | 22:01 |
| ghostmansd[m] | Even restraining from reply would have been better. | 22:01 |
| ghostmansd[m] | That said, no hard feelings, just please keep this in mind. Thank you. | 22:02 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 22:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 22:58 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!