| lkcl | eek! yes SelectableInt is pretty fundamental, has to be some care taken there | 00:22 |
|---|---|---|
| lkcl | such as: | 00:22 |
| lkcl | python3 decoder/isa/test_caller_svp64_subvl.py >& /tmp/f | 00:22 |
| lkcl | return FieldSelectableInt(si=instance, br=self.__field).asint(msb0=True) | 00:23 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/selectable_int.py", line 139, in asint | 00:23 |
| lkcl | bit = self.si[key].value | 00:23 |
| lkcl | AttributeError: 'NoneType' object has no attribute 'value' | 00:23 |
| lkcl | missed a bit | 00:25 |
| lkcl | yield from self.translate_one(insn) | 00:25 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/sv/trans/svp64.py", line 879, in translate_one | 00:25 |
| lkcl | svp64_rm.extra3[idx].eq( | 00:25 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/selectable_int.py", line 487, in __get__ | 00:25 |
| lkcl | return FieldSelectableInt(si=instance, br=self.__field).asint(msb0=True) | 00:26 |
| lkcl | File "/home/lkcl/src/libresoc/openpower-isa/src/openpower/decoder/selectable_int.py", line 139, in asint | 00:26 |
| lkcl | bit = self.si[key].value | 00:26 |
| lkcl | AttributeError: 'NoneType' object has no attribute 'value' | 00:26 |
| lkcl | ok br is being set to a dict (not to a BitRange) | 00:54 |
| lkcl | - cls.__fields = dict(map(field, fields.items())) | 00:54 |
| lkcl | this ensured that the values of the fields were either a SelectableInt or a slice() | 00:55 |
| lkcl | instead what is being passed through to SelectableInt.__getitem__() is a tuple | 00:55 |
| lkcl | i've committed some debug-log messages (and an assert) showing where the error ends up | 00:57 |
| programmerjake | ...why type assertions are useful... | 01:04 |
| lkcl | ye, but you go to such an extreme jacob that it becomes massively irritating and literally doubles the size of the code | 01:06 |
| lkcl | making it unreadable in the process | 01:06 |
| lkcl | this particular code relies on type-detection in its arguments - __getattr__ must receive only either another SelectableInt or a slice | 01:07 |
| lkcl | and for some [as yet unknown] reason it's been passed a tuple | 01:08 |
| lkcl | it's quite a complex piece of code, providing MSB0-ordering and bit-level-addressable sub-selection of an underlying MSB0-ordered number | 01:09 |
| programmerjake | the lack of types my ide can figure out is massively irritating and doubles the time required to work on such code...e.g. most of the pipelining infrastructure | 01:17 |
| lkcl | we have gone over this ten, eleven, twelve, thirteen, fourteen times | 05:10 |
| lkcl | i have *no problem* with you putting the required types into a .pyi file that is for your own convenience | 05:10 |
| lkcl | and even committing that to the repositories | 05:10 |
| lkcl | as long as under no circumstances those types are added to any of the HDL | 05:11 |
| programmerjake | that doesn't work very well... | 05:11 |
| lkcl | well why did you not mention that before?? | 05:11 |
| lkcl | that is the first time you have ever responded and told me that | 05:12 |
| programmerjake | because I gave up... | 05:12 |
| lkcl | if you don't tell me then we can't work something out | 05:12 |
| lkcl | i assumed you were always using the .pyi files and were just ignoring me... because you didn't communicate that they weren't working well for you | 05:13 |
| programmerjake | as you can see from the total lack of .pyi files and the nmigen type annotations repo having it's last commit years ago | 05:13 |
| lkcl | how am i in *any way* supposed to be able to deduce that? | 05:14 |
| lkcl | come on, jacob | 05:14 |
| lkcl | i am not in the least bit interested in using any kind of IDE or any form of mouse-assisted "hints" | 05:14 |
| lkcl | so if i never use those tools, how am i supposed to "guess" that they're not working for you?? | 05:15 |
| lkcl | i have an ability to model most interactions (from doing remote debugging on mailing lists) | 05:15 |
| programmerjake | admittedly it took me several months to realize they don't work well, i only realized that gradually so there wasn't really a moment where I suddenly knew it wasn't working | 05:16 |
| lkcl | but that's impossible to do if i don't have *any* clue about how to use a tool | 05:16 |
| lkcl | ok. | 05:16 |
| programmerjake | so telling you didn't occur to me | 05:16 |
| lkcl | well, now you've told me. so that's good. | 05:16 |
| lkcl | i find sometimes it takes a while for things to crystallise as well | 05:16 |
| lkcl | i take it that's something to do with this? https://wingware.com/doc/edit/analysis-helping-pyi-files | 05:18 |
| programmerjake | one of the biggest reasons .pyi files don't work is because of the time cost of basically having to duplicate the whole public API and maintain it...also a .pyi file doesn't get used for type hinting in the file it's associated with, just when other code imports that file | 05:19 |
| lkcl | ah - that's different. | 05:20 |
| lkcl | https://fileinfo.com/extension/pyi | 05:20 |
| lkcl | apparently pycharm can check | 05:21 |
| klys_ | hi | 05:26 |
| programmerjake | afaict it does it basically the same way as vscode does -- which i'm using. | 05:27 |
| programmerjake | hi klys | 05:27 |
| klys_ | just trying to grok what I'm reading here | 05:27 |
| klys_ | "...just when other code imports that file" | 05:27 |
| programmerjake | so if you have a.py with type hints in a.pyi, the type hints are used in b.py that imports a, but are not used when editing a.py | 05:28 |
| klys_ | so something to do with the ide doesn't use the file you're working with? mebby it's a naive assumption tho got to start somewhere | 05:29 |
| programmerjake | in particular that is the behavior of the mypy type checker last i checked | 05:29 |
| klys_ | mypy, do you have a link to it? | 05:30 |
| programmerjake | which was used by vscode at the time | 05:30 |
| programmerjake | vscode has since changed to pyright, which is written in typescript | 05:30 |
| klys_ | does pyright do type checking the same way, palpably? | 05:30 |
| programmerjake | https://github.com/python/mypy | 05:31 |
| programmerjake | i have no reason to expect pyright to behave differently | 05:31 |
| programmerjake | https://github.com/microsoft/pyright | 05:32 |
| klys_ | so, you aren't describing a bug in one of the above | 05:33 |
| programmerjake | not afaict | 05:33 |
| programmerjake | though, lemme check | 05:33 |
| klys_ | would it offer some consolation to create a simple o.py which imports a.pyi (or x.pyi, etc.) and then use a.py with import o? | 05:36 |
| klys_ | or does the python source you're working with mirror the type hints you're using? | 05:37 |
| programmerjake | the python source mirrors the type hints because the type hints mirror the API of the source file | 05:38 |
| programmerjake | found https://github.com/python/mypy/issues/5028 | 05:38 |
| klys_ | sorry I can't really double check as I don't have a local vscode | 05:38 |
| programmerjake | mypy and pyright can be used from the command line or other editors with LSP support (e.g. vim, emacs, eclipse, etc.) | 05:39 |
| programmerjake | mypy is used through pyls if you want LSP support | 05:40 |
| klys_ | it's a didactic or textual issue, not a programming issue, if I am understanding it correctly | 05:40 |
| programmerjake | not sure... | 05:41 |
| klys_ | having to do with how you view and interface with your code in the ide, and having very little to do with compiled code | 05:42 |
| programmerjake | no, mypy just doesn't use a.pyi when type checking a.py, which makes writing code in a.pyi or a.py more error prone | 05:44 |
| klys_ | okay, thinking it's understood now, carry on! | 05:44 |
| Veera[m] | Hi, need help with coriolis | 06:25 |
| Veera[m] | example_cell="chip_r" | 06:26 |
| Veera[m] | cd alliance-check-toolkit/benchs/adder/cmos | 06:27 |
| Veera[m] | make lvx | 06:27 |
| Veera[m] | It is taking more than 2 hours in talos and still running | 06:27 |
| Veera[m] | web page says it will complete in 5mins!!!! | 06:27 |
| Veera[m] | does make lvx invoke GUI interface? | 06:28 |
| Veera[m] | bin/cougar -c -f chip_r chip_r_ext is running 100% cpu for 170mins! | 06:54 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 08:06 | |
| lkcl | klys_, ah! i've been trying to reach you for a few months - there is EUR available for you from NLnet | 08:14 |
| lkcl | but you have to submit a Request for Payment | 08:14 |
| lkcl | i can't send it to you, myself (aside from anything i don't have your bank account details) | 08:15 |
| lkcl | it's something like EUR 1,300 so is not an insubstantial amount | 08:17 |
| lkcl | the last email i sent you - i've not received a response to any of them - i said that if i do not hear from you i will have to assume that it's to be donated | 08:18 |
| lkcl | we have a deadline of beginning of October (about 7 weeks) | 08:19 |
| lkcl | anything submitted after that we *lose the money entirely* | 08:19 |
| ghostmansd[m] | lkcl, thanks for debug! The tuple likely comes from one of the fields classes, I'll check it now. | 08:38 |
| ghostmansd | OK found the reason. Yeah, we have to differentiate a special case for multi-dimensioned fields, like extra2 and extra3. | 09:38 |
| ghostmansd | Since we cannot quickly guess if we have a tuple of bits or a tuple of tuples of bits, the implementation used a trick: we expressed a tuple of tuples as a dict of tuples. | 09:39 |
| ghostmansd | I forgot to port this to new implementation, so yeah, it was broken. | 09:39 |
| ghostmansd | Now I backported it. However, with this in mind: there better should have been some better way. I'm not doing it now due to time constraints. However, we should think of this hierarchy more. | 09:41 |
| ghostmansd | src/openpower/decoder/isa/test_caller_svp64_subvl.py runs fine | 09:41 |
| ghostmansd | src/openpower/decoder/isa/test_caller_svp64.py is fine, too | 09:42 |
| ghostmansd | Luke, I'm going to merge this to master, please let me know if there are other tests I might need to consider. | 09:42 |
| ghostmansd | mmmmm.... had you already merged it to master??? | 09:43 |
| ghostmansd | ah now, got confused by git log | 09:44 |
| ghostmansd | s/now/no | 09:44 |
| ghostmansd | lkcl, how does one determine the function (LDST, BRANCH or whatever)? | 10:20 |
| ghostmansd | Ah I think I know... src/openpower/decoder/power_decoder2.py:1046 | 10:21 |
| *** octavius <octavius!~octavius@146.90.27.67> has joined #libre-soc | 10:39 | |
| octavius | Morning lkcl, seems you and dmitriy submitted RFPs for bug 884, can I do that as well? | 10:47 |
| octavius | I haven't been introduced to the new hidden system | 10:47 |
| octavius | Also for bug 758 (pypowersim), you did quite a bit of work, so perhaps we should split that one? | 10:49 |
| ghostmansd | it looks like we'll need to generate some helper stuff to determine the opcode function | 11:57 |
| ghostmansd | and we need this to distinguish between NORMAL/LDST/BRANCH/CROP | 11:58 |
| ghostmansd | for python code and pysvp64dis, this is simple: we now have insndb, and can loop through all entries and check the major opcode | 12:00 |
| ghostmansd | like this: https://pastebin.com/vG8GQmwc | 12:00 |
| ghostmansd | or, well, rather this: https://pastebin.com/t8HnY34Y | 12:06 |
| ghostmansd | Nah, why consider only major? https://pastebin.com/0ENTsfzs | 12:23 |
| ghostmansd | This grabs the database entry based on the whole instruction. | 12:24 |
| lkcl | ghostmansd, brilliant. that code's fast becoming voodoo-magic | 13:01 |
| ghostmansd | lkcl, you might opt checking pysvp64dis branch again :-) | 13:02 |
| lkcl | on it... | 13:02 |
| lkcl | ahh good, subvl test passed | 13:02 |
| ghostmansd | I already adopted the insndb so that it can lookup the opcodes on its own | 13:02 |
| ghostmansd | so you can simply open the insndb, pass it an opcode and get the record | 13:03 |
| lkcl | yes the unit is intended to tell you that. | 13:04 |
| lkcl | ALU/LDST/BRANCH/CROP | 13:04 |
| lkcl | which corresponds directly with which RM table to start from | 13:04 |
| lkcl | you can't only consider the MAJOR field. | 13:05 |
| lkcl | (EXTNNN bits 0-5) | 13:05 |
| lkcl | it does have to also be the XO field | 13:06 |
| lkcl | annoyingly | 13:06 |
| lkcl | octavius, yes of course 1 sec | 13:06 |
| ghostmansd | the insndb comnsiders both | 13:06 |
| ghostmansd | the opcode property is exactly the stuff we used in binutils | 13:06 |
| ghostmansd | that is, it considers bitsels and is aware of both value and mask | 13:06 |
| lkcl | great. that will allow power_decoder.py - PowerDecoder - to be done as a flat for-loop at some point instead of a hierarchical walk | 13:07 |
| lkcl | the only reason it's not a flat for-loop at the moment is precisely because there wasn't the pre-processing phase that is now in insndb | 13:08 |
| lkcl | octavius, i'm good. the idea is to get you some $. | 13:10 |
| lkcl | SelectableInt should itself have its own unit test | 13:11 |
| lkcl | and, err.. there isn't one for FieldSelectableInt, err... | 13:12 |
| ghostmansd | for FieldSelectableInt there should be | 13:13 |
| ghostmansd | I certainly saw something in this regard | 13:13 |
| ghostmansd | FieldSelectableIntTestCase | 13:13 |
| lkcl | ghostmansd, i'm going to run test_issuer.py which is a big one and if that passes it runs so damn much it's ok | 13:13 |
| lkcl | yep found it. duh | 13:14 |
| ghostmansd | Cool! Cool cool cool. | 13:14 |
| ghostmansd | .llong 0x054000007c410214 # sv.add | 13:14 |
| lkcl | give it 25 mins or so | 13:14 |
| lkcl | oooOoo | 13:14 |
| ghostmansd | Gradually, slowly, step-by-step, but we're moving towards disassembly. | 13:14 |
| ghostmansd | I'll add the unit recognition now, since it affects anything we do upon decoding, and then continue moving with the rest of the bits. | 13:16 |
| lkcl | i found a pep8 (>80chars) thing, committed. | 13:21 |
| lkcl | if (not isinstance(value, int) or | 13:21 |
| lkcl | (value < 0) or (value > ((1 << 32) - 1))): | 13:21 |
| lkcl | raise ValueError(value) | 13:21 |
| lkcl | i'm fussy about that because i have 12 to 14 80x65 xterms on-screen at once. | 13:21 |
| lkcl | klys_, one of the reasons why i'm strict about code-density is because i have short-term memory problems / a type of learning/memorisation difficulty. | 13:22 |
| lkcl | if the code's not in front of me (because i had to page-down page-up page-down page-up) i literally can't remember what i saw on the page-down in order to match it with the page-up | 13:23 |
| lkcl | i therefore frequently have to open the same file *twice* (!) in neighbouring xterms | 13:23 |
| lkcl | then there's function definitions which get nested in complex code-bases like this, often to an "alarming" depth, for someone not used to this size of codebase | 13:24 |
| ghostmansd[m] | I don't really bother checking these now | 13:26 |
| ghostmansd[m] | That said, perhaps we could have a git hook? | 13:26 |
| ghostmansd[m] | So that the code is not pushed if it doesn't pass this limitation | 13:27 |
| lkcl | basically if you do a "git diff" before a commit and it overruns the 80-char terminal then that's a visual red flag | 13:29 |
| lkcl | that of course assumes that you're using 80xNN terminals | 13:29 |
| lkcl | https://libre-soc.org/HDL_workflow/2020-01-24_11-56.png | 13:29 |
| ghostmansd[m] | lkcl, I've been thinking, perhaps we could output the unit along with the rest of our desc in binutils? | 13:31 |
| ghostmansd[m] | Ah no, I guess this wouldn't help that much. | 13:31 |
| ghostmansd[m] | Or wait... together with the mask... yes it would. | 13:32 |
| ghostmansd[m] | We still have 15 unused bits in svp64_desc. | 13:33 |
| ghostmansd[m] | Function has 15 distinct values... So this needs 4 bits. | 13:34 |
| ghostmansd[m] | So yeah, I guess, we'll look the record based on opcode/mask, then check the function field (obviously we'll have different values, not the ones Function has). | 13:36 |
| lkcl | ghostmansd[m], test_issuer.py passes (or, has the same errors it's had for the past few months) | 13:40 |
| lkcl | so a merge is fine | 13:41 |
| lkcl | Function.. 1 sec... yyyeah... i'd make it 5 | 13:42 |
| lkcl | i can foresee us adding 2 new pipeline types in the future. 3D, BITMANIP, other | 13:43 |
| ghostmansd[m] | Well if you extend this it'll be updated automatically | 13:43 |
| ghostmansd[m] | Because I made the code care of number of entries | 13:43 |
| ghostmansd[m] | And it calculates bits on its own | 13:43 |
| lkcl | mm... true... which is... ok. yep. | 13:44 |
| lkcl | you use offsetof() and friends, right? | 13:44 |
| lkcl | or... never mind, it'll be fine :) | 13:45 |
| lkcl | hoo f****g rah it's actually rained for the first time in 10 weeks here | 13:45 |
| lkcl | grass in the park opposite had actually gone beyond yellow and was going white | 13:46 |
| ghostmansd[m] | Nope, I mean the generator code | 13:46 |
| ghostmansd[m] | When we take enum and convert it to field | 13:46 |
| lkcl | ignore me - i was wittering to myself | 13:46 |
| ghostmansd[m] | Ok :-) | 13:47 |
| * lkcl head spinning, still haven't had time to do pack/unpack. dang | 13:47 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:14 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 14:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.248> has joined #libre-soc | 14:21 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.248> has quit IRC | 14:58 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@nat.222-104.maryno.net> has joined #libre-soc | 14:58 | |
| *** ghostmansd <ghostmansd!~ghostmans@nat.222-104.maryno.net> has joined #libre-soc | 15:18 | |
| *** ghostmansd <ghostmansd!~ghostmans@nat.222-104.maryno.net> has quit IRC | 15:25 | |
| *** ghostmansd <ghostmansd!~ghostmans@nat.222-104.maryno.net> has joined #libre-soc | 15:26 | |
| ghostmansd | programmerjake, lkcl, I wonder whether such statements are correct: rm_dec.rc_in.eq(rc_out) | 15:34 |
| ghostmansd | src/openpower/decoder/power_decoder2.py:1054 | 15:35 |
| ghostmansd | lkcl, I need few comments regarding everything since src/openpower/decoder/power_decoder2.py:1024 | 15:42 |
| ghostmansd | my question is, why don't we always use `fn = self.op_get("function_unit")`? | 15:42 |
| ghostmansd | The function_unit for the records we handle at line 1039 should already have LDST in this case, doesn't it? | 15:45 |
| ghostmansd | I'm asking since I obtain _MORE_ records if I check for function_unit... | 15:45 |
| ghostmansd | https://pastebin.com/ADjh1T2x | 15:46 |
| ghostmansd | The`"functions` set ends up being larger than `opcodes` | 15:47 |
| ghostmansd | the difference: https://pastebin.com/ykJ8ZDtP | 15:50 |
| *** ghostmansd <ghostmansd!~ghostmans@nat.222-104.maryno.net> has quit IRC | 15:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@nat.222-104.maryno.net> has quit IRC | 16:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.242> has joined #libre-soc | 16:09 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.242> has quit IRC | 16:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.242> has joined #libre-soc | 16:26 | |
| *** tplaten <tplaten!~isengaara@55d4a0fa.access.ecotel.net> has joined #libre-soc | 16:28 | |
| lkcl | ghostmansd[m], 1 sec on phone | 16:31 |
| ghostmansd[m] | no rush, take your time | 16:33 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 16:41 | |
| lkcl | frickin ell that was a long call | 17:02 |
| lkcl | okaay, right. | 17:04 |
| lkcl | to explain what op_get() does: this is an instruction decoder | 17:04 |
| lkcl | HOWEVER | 17:04 |
| lkcl | there exists an override mechanism | 17:04 |
| lkcl | where if there is an Illegal Instruction, we want to be able to execute a Trap instruction | 17:05 |
| lkcl | the easiest way to do that? | 17:05 |
| lkcl | ... override the decoded instruction so that it *becomes* a trap instruction | 17:05 |
| lkcl | ah i just talked about do_get(), not op_get() | 17:06 |
| lkcl | ignore all that :) | 17:06 |
| lkcl | op_get - you can see it is: | 17:06 |
| lkcl | def op_get(self, op_field): | 17:06 |
| lkcl | return getattr(self.op, op_field, None) | 17:06 |
| lkcl | this because PowerDecoder2 - like PowerDecoder - is *reconfigureable* | 17:07 |
| lkcl | you can create a PowerDecoder2 which deals with a *subset* of operations and thus has a *subset* of fields (by column) from the CSV files | 17:07 |
| lkcl | the reason is because if you decoded everything you end up with a mmmmaaaassssiiiivvve 300+ set of wires branching out to every single pipeline | 17:08 |
| lkcl | quantity 15 (so far, and likely to be a lot more) | 17:08 |
| lkcl | or | 17:08 |
| lkcl | what you could do is | 17:08 |
| lkcl | pass the instruction (qty 32 wires - 64 if SVP64) to those 15 pipelines, giving a much smaller fan-out | 17:09 |
| lkcl | and have *satellite* decoders at the last minute | 17:09 |
| lkcl | and that's why the entirety of PowerDecoder2 is so reconfigureable, and uses getattr(self.op, field_name, None) | 17:09 |
| lkcl | now | 17:11 |
| lkcl | given that i REMOVED the LD/ST-shift crap | 17:11 |
| lkcl | the override "is_major_ld" there can now *also* be removed | 17:11 |
| lkcl | it was an "early notification" to the SVP64-side of the decoder (rm_dec.fn_in) to detect a LD/ST operation | 17:12 |
| lkcl | i'll do that now | 17:12 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 17:22 | |
| *** tplaten <tplaten!~isengaara@55d4a0fa.access.ecotel.net> has quit IRC | 17:26 | |
| lkcl | ghostmansd[m], done https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=81e8161ab8656d1611493c323d319a03c4da748e | 17:28 |
| lkcl | strictly speaking the one further down - SVP64 FFT mode - should also not exist either | 17:29 |
| ghostmansd[m] | Perfect! Now this code really looks like what I expected. :-) | 17:30 |
| lkcl | yes. and also is in line with the spec saying "we DO NOT make different interpretations of 32-bit suffixes just because they are prefixed" | 17:30 |
| lkcl | i mean, you can see the god-awful mess it makes | 17:31 |
| lkcl | you have to do a partial-detect of the operation | 17:31 |
| lkcl | pass that to the SVP64.RM decoder | 17:31 |
| lkcl | which then comes *BACK* to the PowerDecoder2 to tell you how to decode the 32-bit operation! | 17:32 |
| lkcl | ehhhmmmm... no. | 17:32 |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.162.242> has joined #libre-soc | 17:42 | |
| *** ghostmansd <ghostmansd!~ghostmans@176.59.162.242> has quit IRC | 18:34 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 18:55 | |
| ghostmansd | Luke, recently I've been struggling why on regeneration of blobs do I have some instructions changed... and I found that some entries are duplicated. | 19:40 |
| ghostmansd | 0b0000,SHIFT_ROT,OP_RLCL,NONE,CONST_SH,RS,RA,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,rldicl,MDS, | 19:41 |
| ghostmansd | 0b0001,SHIFT_ROT,OP_RLCL,NONE,CONST_SH,RS,RA,NONE,CR0,0,0,ZERO,0,NONE,0,0,0,0,0,0,RC,0,0,rldicl,MDS, | 19:41 |
| ghostmansd | The only difference I see is the opcode. Did you mean rldicl., with RC? | 19:41 |
| ghostmansd | Same with the rest of instructions here. | 19:42 |
| ghostmansd | Another perfectly viable option is that I miss something. :-) | 19:42 |
| ghostmansd | openpower/isatables/minor_30.csv | 19:44 |
| ghostmansd | Not blobs, C code. | 19:45 |
| *** tplaten <tplaten!~isengaara@55d4a0fa.access.ecotel.net> has joined #libre-soc | 19:45 | |
| *** octavius <octavius!~octavius@146.90.27.67> has quit IRC | 19:54 | |
| ghostmansd | lkcl, here's what it takes to have a new enum in binutils: https://git.libre-soc.org/?p=openpower-isa.git;a=commit;h=783d7c6c2ab159b4ca38d6fa6254697e8151939f | 20:18 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.242> has quit IRC | 20:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 20:26 | |
| ghostmansd | Here's how we affect the code generation: https://bugs.libre-soc.org/show_bug.cgi?id=845#c15 | 20:31 |
| *** tplaten <tplaten!~isengaara@55d4a0fa.access.ecotel.net> has quit IRC | 20:33 | |
| ghostmansd | lkcl, would it be difficult to allow FieldSelectableInt accept _another_ FieldSelectableInt? | 20:55 |
| ghostmansd | This would help cases like FieldSelectableInt(insn.prefix.rm.mode, SVP64MODE.MOD2) | 20:56 |
| ghostmansd | Hm. Since bit width of FSI is always len(fsi.br)... One might refer to the same SI then, but just adjust the bits. | 20:58 |
| ghostmansd | OK yes, this seems to do the trick: https://git.libre-soc.org/?p=openpower-isa.git;a=commit;h=58a4537b6fb0fff3d8ec156994d3b46f6b280ea6 | 21:18 |
| ghostmansd | Hell I'm really surprised how many side work is there with binutils :-) | 21:19 |
| ghostmansd | Still, it seems this is highly re-usable, so I don't hesitate to do it | 21:19 |
| lkcl | pffh that's so difficult, adding function. | 21:34 |
| lkcl | hang on let's look at microwatt decode1.vhdl | 21:35 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/master/decode1.vhdl | 21:35 |
| lkcl | hang on paul's done a redesign | 21:36 |
| lkcl | https://git.libre-soc.org/?p=microwatt.git;a=blob;f=decode1.vhdl;h=2869c3911b2b61a919529e6da0f8f9eb300a0616;hb=bf4f5806849d42d8fa74953483391590136159ac#l184 | 21:36 |
| lkcl | ok it should be converted to "000-" | 21:37 |
| lkcl | mmm if fsi can take another fsi that's not exactly planned but it is not a surprise if it works | 21:39 |
| lkcl | horrendous in terms of resources.... | 21:39 |
| *** octavius <octavius!~octavius@146.90.27.67> has joined #libre-soc | 21:50 | |
| ghostmansd | Not really horrendous | 21:56 |
| ghostmansd | They refer the same SI | 21:56 |
| ghostmansd | Ony BR must be updated, but that's basically... | 21:56 |
| ghostmansd | + for (i, v) in br.items(): | 21:56 |
| ghostmansd | + _br[i] = fsi.br[v] | 21:56 |
| ghostmansd | https://git.libre-soc.org/?p=openpower-isa.git;a=shortlog;h=refs/heads/pysvp64dis | 21:57 |
| ghostmansd | cf. some recent commits; I supported further slicing for FSI | 21:58 |
| ghostmansd | As result, we can do https://git.libre-soc.org/?p=openpower-isa.git;a=commit;h=e5b39fe980824bee0aa478d3bb0257ee95c07548 | 21:58 |
| ghostmansd | Perhaps we can even make it work on elaborate() side, with the caveat that it must be a thin wrapper capable of providing info for nmigen | 21:59 |
| ghostmansd | But, at the same time, it should stay away from dependencies on nmigen | 22:00 |
| ghostmansd | Ideally, for binutils, this stuff should be generated, too | 22:00 |
| ghostmansd | At least all these fields, etc. | 22:00 |
| ghostmansd | But I don't have time to do it, so I'll simply repeat and adopt this code to C | 22:01 |
| ghostmansd | Likely it'll be not really readable, but at least it increases the chances to complete till October | 22:01 |
| ghostmansd | In fact, we have so little time that I think I'll gradually populate binutils with the code too | 22:03 |
| ghostmansd | OK enough for today | 22:03 |
| Veera[m] | lkcl: I ran build_full_4ksram_recon.sh. the bin/cougar is still running for 10 hrs. for cmos; make lvx it was running for 170mins instead of 5mins. | 22:07 |
| Veera[m] | lkcl: does powerpcle Talos capable of building coriolis | 22:08 |
| *** octavius <octavius!~octavius@146.90.27.67> has quit IRC | 23:09 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
