| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc | 01:16 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:14 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 02:14 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 02:19 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:46 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 02:46 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 02:55 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 03:07 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 03:39 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 04:08 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC | 04:23 | |
| *** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc | 04:23 | |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 04:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 04:58 | |
| *** ritish_ <ritish_!~Ritish@116.72.126.30> has joined #libre-soc | 04:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 05:28 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:51 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:52 | |
| *** sai__ <sai__!~Ritish@116.72.113.244> has joined #libre-soc | 07:03 | |
| *** ritish_ <ritish_!~Ritish@116.72.126.30> has quit IRC | 07:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 07:22 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 07:44 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 07:47 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 07:48 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 08:01 | |
| *** sai__ is now known as Ritish | 08:19 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:00 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 10:36 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 11:00 | |
| *** octavius <octavius!~octavius@92.40.169.207.threembb.co.uk> has joined #libre-soc | 11:54 | |
| octavius | lkcl, I'm setting up ls2 on a different machine (to go through the steps again, following the **ls2 iwiki page**. | 11:59 |
|---|---|---|
| octavius | All scripts up to hdl-dev-ls2 look good (logs don't show any errors). | 11:59 |
| octavius | hdl-dev-ls2 fails because of setuptools (get_version() got an unexpected keyword argument 'fallback_version'), which was the same TypeError I had last week. Now my bodge last week was to manually install a newer version of setuptools_scm, **I WILL NOT DO THIS** in this case. | 11:59 |
| octavius | I seem to remember you removed the dependency on setuptools_scm, is this not the case? I have not seen any recent commits that have done this. | 11:59 |
| *** octavius <octavius!~octavius@92.40.169.207.threembb.co.uk> has quit IRC | 12:05 | |
| *** octavius <octavius!~octavius@92.40.169.207.threembb.co.uk> has joined #libre-soc | 12:06 | |
| *** Ritish <Ritish!~Ritish@116.72.113.244> has quit IRC | 12:06 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:06 | |
| *** ibot` <ibot`!~supybot@libre-soc.org> has joined #libre-soc | 13:15 | |
| *** mx08_ <mx08_!~mx08@user/mx08> has joined #libre-soc | 13:17 | |
| *** josuah_ <josuah_!~irc@46.23.94.12> has joined #libre-soc | 13:17 | |
| *** markos_ <markos_!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc | 13:20 | |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 13:20 | |
| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 13:20 | |
| *** ibot <ibot!~supybot@libre-soc.org> has quit IRC | 13:20 | |
| *** josuah <josuah!~irc@46.23.94.12> has quit IRC | 13:20 | |
| *** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 13:20 | |
| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc | 13:21 | |
| lkcl | programmerjake, that's exactly the kind of complication in hardware at a critical juncture which is under severe gate-latency pressure that is precisely what IBM's 64-bit-alignment rule is there to avoid | 13:41 |
| lkcl | ghostmansd, for now, yes. | 13:41 |
| lkcl | octavius, no. can you do it. edit setup.py in lambdasoc. feel free also to commit it. | 13:42 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:43 | |
| ghostmansd | lkcl, for now yes what? :-) | 13:44 |
| ghostmansd | sorry, I'm missing which of the messages you reply | 13:44 |
| lkcl | > <ghostmansd> lkcl, as for SVP64 behaving as non-prefix: it breaks the least astonishment principle | 13:45 |
| lkcl | because currently using EXT001. | 13:45 |
| lkcl | when using another major opcode the decision is entirely up to us. actually, not true: it's up to the OPF ISA WG, but we can propose reasonable and rational arguments for doing something different | 13:46 |
| ghostmansd | My point is, even if it uses a different prefix, it stills quacks like duck. | 13:46 |
| lkcl | (as long as, programmerjake, they do not compromise multi-issue execution) | 13:46 |
| ghostmansd | s/prefix/opcode | 13:46 |
| lkcl | ghostmansd, it's not that simple | 13:47 |
| ghostmansd | Again something RTL-related? | 13:47 |
| ghostmansd | OK, what'd be the problem with adding a nop? | 13:47 |
| lkcl | the "punishment" for 64-bit alignment is increased binary size | 13:47 |
| ghostmansd | Do you expect nops to happen often? | 13:47 |
| ghostmansd | I mean, it's once per 64 bytes | 13:47 |
| lkcl | which would destroy the premise that SVP64 reduces binary size | 13:48 |
| ghostmansd | bytes, not bits | 13:48 |
| lkcl | when we are already under pressure from having to go to 64-bit | 13:48 |
| lkcl | that in turn puts pressure on the compiler toolchain to attempt to minimise the nops | 13:48 |
| lkcl | but the penalty at the decode phase of programmerjake's suggestion is show-stoppingly to completely compromise high-performance multi-issue decoding | 13:49 |
| lkcl | so there is a hard upper limit (not doing what programmerjake suggested as it is catastrophic) based on HDL | 13:50 |
| lkcl | and there is a soft lower-limit (driving force) to reduce binary size | 13:50 |
| lkcl | the compromise between those two is to prohibit alignment across a 16-word boundary. | 13:51 |
| lkcl | which obviously a multiple of that fits into a L1 Cache Line size | 13:51 |
| lkcl | thus the decoder may load an entire cache line, break that cache line down into (minimum) 16-word block sizes | 13:52 |
| lkcl | and analyse all of them for multi-issue decoding and identification of instruction start-points | 13:52 |
| ghostmansd | what if prefix fits the cache but the suffix doesn't? | 13:52 |
| lkcl | exactly | 13:52 |
| ghostmansd | But nops are for this exact purpose | 13:53 |
| lkcl | that's the nightmare scenario that is catastrophically complex to deal with in hardware | 13:53 |
| lkcl | a 16-word aligned rule solves the exact same thing | 13:53 |
| lkcl | except it does actually allow for crossing 32-64-64-32 *within* a 16-word aligned boundary | 13:54 |
| lkcl | thus reducing executable size | 13:54 |
| lkcl | IBM is not expecting a significant number of 64-bit instructions to be interleaved with 32-bit | 13:54 |
| lkcl | we are anticipating a LOT of 32-bit instructions to be interleaved with 64-bit prefixed instructions | 13:54 |
| ghostmansd | In our case there will be such a number | 13:54 |
| ghostmansd | Isn't it? | 13:55 |
| lkcl | so the penalty of 64-bit alignment is far more severe than for IBM's EXT001 prefixing | 13:55 |
| lkcl | sorry what number were you referring to? | 13:55 |
| ghostmansd | > IBM is not expecting a significant number of 64-bit instructions to be interleaved with 32-bit | 13:55 |
| lkcl | yes. overlap there :) | 13:56 |
| ghostmansd | Basically what you wrote below :-) | 13:56 |
| ghostmansd | Yeah | 13:56 |
| lkcl | i answered at the same time you asked the question :) | 13:56 |
| ghostmansd | Yep | 13:56 |
| lkcl | so this would be fine: | 13:56 |
| ghostmansd | Asking the right question is the half of the answer | 13:56 |
| lkcl | word 0 1 2 3 .... 15 | 13:56 |
| lkcl | | 32 | 64 . | 64 ... | 32 | | 13:57 |
| lkcl | but this would be prohibited | 13:57 |
| lkcl | word ... 15 | (next 16-word line) | 0 1 | 13:57 |
| lkcl | 64-bit starting position 15 of 1 cache line, crossing over to position 0 of the next | 13:58 |
| lkcl | that's the "prohibited" proposal | 13:58 |
| ghostmansd | OK... we should adopt the gas so that it doesn't perform the alignment for SVP64 | 13:58 |
| lkcl | this same exact concept is what is already part of Power ISA Virtual Memory (at a 1 MB boundary - i think.) | 13:59 |
| lkcl | the hardware-complexity of crossing that boundary and detecting page-fault is so complex that it's permitted to throw a Page Fault exception | 14:00 |
| lkcl | and let software deal with it | 14:00 |
| lkcl | well... i'm perfectly fine with leaving it as-is for now (letting gas insert nops) as it doesn't make any difference and is less work for you | 14:00 |
| lkcl | and it needs discussion with the OPF ISA WG anyway | 14:01 |
| lkcl | they ultimately are the ones that make the decision | 14:01 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.216> has joined #libre-soc | 14:11 | |
| *** Ritish <Ritish!~Ritish@202.131.158.114> has joined #libre-soc | 14:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.174.216> has quit IRC | 14:39 | |
| programmerjake | lkcl: that second alternative i posted of saving the last 32-bits of the previous fetch cycle is much less expensive, and will be needed anyway for all cpus that don't fetch and decode at least a full 64-byte block at once, since 64-bit insns can cross between fetch granules. | 14:50 |
| programmerjake | it also neatly resolves the issue with crossing a page boundary because the cpu simply stores that last 32-bits while the TLB fetch and possible page table walk is occurring for the next fetch granule. | 14:50 |
| programmerjake | reducing to 16-byte blocks that the assembler is not permitted to have 64-bit instructions cross still doesn't fix the issue for any cpus that fetch 8-byte blocks or smaller. | 14:52 |
| programmerjake | and 16-byte blocks quadruple the code-size penalty | 14:53 |
| programmerjake | s/8-byte blocks or smaller/smaller than 16-byte blocks/ | 14:54 |
| lkcl | programmerjake, no. | 15:33 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:36 | |
| programmerjake | so then how do you propose to handle instructions that cross fetch-granules? since the fetch-granules are highly likely to be smaller for some cpus than whatever arbitrary cutoff size you pick (16 or 64-bytes) | 15:37 |
| programmerjake | imho you'll likely arrive at a solution basically identical to my keep-last-32-bits idea | 15:38 |
| *** Ritish <Ritish!~Ritish@202.131.158.114> has quit IRC | 15:38 | |
| programmerjake | and do remember we can't pick a smaller cutoff size than 64-bytes for existing ext001 instructions which we will want to implement (e.g. padd) | 15:40 |
| *** octavius <octavius!~octavius@92.40.169.207.threembb.co.uk> has quit IRC | 17:10 | |
| ghostmansd | I offically announce: _insns array is a total killjoy, but I won't do anything around it for now. | 18:49 |
| ghostmansd | I spent several hours around dsld/dsrd just to find that this damn array needs "dsld." and "dsrd." entries as well. | 18:49 |
| ghostmansd | We should literally beat the crap out of this code. We already have everything needed; there's no need to manually insert all records or sync with any CSV. | 18:52 |
| ghostmansd | I'll think of refactoring this code once I'm done with asm. The only thing which prevents me is the fact that we should have insndb as a singleton, or at least have it cached. | 18:54 |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 18:54 | |
| ghostmansd | The insndb creation takes too much time: it has to parse all CSVs, all markdown, whole fields.text... | 18:55 |
| ghostmansd | We always do it via `DB = Database(find_wiki_dir())` form. | 18:55 |
| ghostmansd | Any ideas how to make this cacheable? | 18:55 |
| ghostmansd | That is, we always use the path returned by `find_wiki_dir()`. Any ideas how to make the whole class instance cacheable to avoid passing the instance between all the modules we have so far? | 18:57 |
| ghostmansd | The only way I'm thinking of is some dirty play with metaclasses. | 18:57 |
| ghostmansd | But perhaps there's some simpler and intuitive way, e.g. lru_cache equivalent on the class? | 18:58 |
| ghostmansd | So that _different_ modules importing Database class could have processed it quickly. | 18:58 |
| programmerjake | imho just set its metaclass to a class with lru_cache on its __call__ | 19:02 |
| programmerjake | class Meta(type): @lru_cache(typed=True, maxsize=None) def __call__(self, *args, **kwargs): return super().__call__(*args, **kwargs) | 19:05 |
| programmerjake | class Database(Meta): ... | 19:05 |
| ghostmansd | Yeah metacls.__call__ was exactly the stuff I've been thinking about, too... | 19:05 |
| ghostmansd | But perhaps there's a simpler way? | 19:05 |
| programmerjake | ^ seems simple enough to me... | 19:05 |
| ghostmansd | Wouldn't caching class's __init__ be sufficient? | 19:05 |
| ghostmansd | I'm asking because I'm not that advanced in functools.lru_cache | 19:06 |
| programmerjake | no, cuz __init__ isn't what decides which instance is returned | 19:06 |
| ghostmansd | And cached_property | 19:06 |
| ghostmansd | Hm, right. What about __new__? | 19:06 |
| programmerjake | __init__ still gets run even if __new__ returns an existing object | 19:07 |
| programmerjake | cached_property is limited to properties | 19:07 |
| ghostmansd | Yeah but lru_cache isn't | 19:08 |
| ghostmansd | Frankly, considering the huge amount of different formats I've been thinking of accumulating these into yaml/json/whatever as a _temporary_ file | 19:08 |
| ghostmansd | Parsing this would have been simpler than iterating over all files again | 19:09 |
| ghostmansd | But I bet Luke would say something about readable and maintainable CSVs, eh? lkcl | 19:09 |
| programmerjake | lru_cache is effectively just def fn(a,r,g,s): try: return already_seen[(a,r,g,s)] except: retval = ...normal body...; already_seen[(a,r,g,s)] = retval; return retval | 19:10 |
| programmerjake | so lru_cache isn't treated specially | 19:10 |
| ghostmansd | Ah, fuck. So it also considers self, right? | 19:11 |
| ghostmansd | And will return different results on different selves | 19:11 |
| ghostmansd | Even if other parameters are the same... | 19:11 |
| programmerjake | one other simple option is just assigning a global: DATABASE = Database(...) and just use the global rather than constructing a new instance anywhere | 19:12 |
| programmerjake | ghostmansd: yes | 19:12 |
| ghostmansd | Then metaclass is better since it hides the global | 19:14 |
| ghostmansd | OK I'll think about it. Thanks for advice and suggestions programmerjake! | 19:14 |
| programmerjake | though the downside of the global approach is everything's run on import, so any prints or logs will sometimes make other programs such as debuggers or IDEs not work correctly since they're trying to import those modules just to see which symbols they have and printing their results on stdout, which conflicts with the prints from running Database() | 19:16 |
| programmerjake | so imho the metaclass approach is best | 19:16 |
| programmerjake | though imho you'll also want to run find_wiki_dir() from inside Database() so that gets cached too | 19:18 |
| programmerjake | you could name the metaclass CachedConstructor (it isn't technically a singleton since calling __call__ with different args gives different instances) and put it in nmutil | 19:20 |
| ghostmansd | The latter is quite an unlikely scenario if nm stands for nMigen. | 19:23 |
| ghostmansd | I want this module to be as decoupled and standalone from nMigen as possible. | 19:23 |
| ghostmansd | In fact, if it's coupled to nMigen, the whole thing is fucked up beyond the catastrophe. | 19:24 |
| programmerjake | it wouldn't be coupled to nmigen beyond being in the package of utilities for nmigen, which has become more of a package of utilities for libre-soc | 19:32 |
| *** octavius <octavius!~octavius@92.40.169.207.threembb.co.uk> has joined #libre-soc | 20:25 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:25 | |
| ghostmansd | lkcl, programmerjake, there're two updates on tasks | 21:49 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=947#c3 | 21:49 |
| ghostmansd | https://bugs.libre-soc.org/show_bug.cgi?id=987#c1 | 21:49 |
| ghostmansd | Also this: https://bugs.libre-soc.org/show_bug.cgi?id=964#c5 | 21:50 |
| ghostmansd | lkcl, is https://libre-soc.org/task_db active? | 22:04 |
| *** octavius <octavius!~octavius@92.40.169.207.threembb.co.uk> has quit IRC | 22:13 | |
| programmerjake | ghostmansd: note that links to specific lines of a job log don't actually work since gitlab only loads the last 500kB of the log so all the line numbers are wrong | 22:17 |
| programmerjake | please post a good enough description that the specific tests you're talking about can be found | 22:18 |
| programmerjake | e.g. | 22:19 |
| programmerjake | FAILED src/openpower/decoder/isa/test_caller_alu.py::TestALU::test - AssertionError: 2 != 3 : ca mismatch (sim != expected) 'addmeo 3, 4' | 22:19 |
| ghostmansd[m] | programmerjake, since the link was clickable, and URL contained the specific line, I assumed it would work. Yeah that's the only test (as long as the results in the CI are printed correctly). | 22:29 |
| programmerjake | ghostmansd[m]: yeah, imho this is a gitlab bug | 22:30 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!