Tuesday, 2023-01-24

*** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc01:16
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:14
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc02:14
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC02:19
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:46
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc02:46
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc02:55
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC03:07
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC03:39
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc04:08
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has quit IRC04:23
*** toshywoshy <toshywoshy!~toshywosh@ptr-377wf33o3bnthuddmycb.18120a2.ip6.access.telenet.be> has joined #libre-soc04:23
*** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc04:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC04:58
*** ritish_ <ritish_!~Ritish@> has joined #libre-soc04:59
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc05:28
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:51
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:52
*** sai__ <sai__!~Ritish@> has joined #libre-soc07:03
*** ritish_ <ritish_!~Ritish@> has quit IRC07:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC07:22
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc07:44
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC07:47
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc07:48
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC08:01
*** sai__ is now known as Ritish08:19
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc10:00
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC10:36
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc11:00
*** octavius <octavius!~octavius@> has joined #libre-soc11:54
octaviuslkcl, I'm setting up ls2 on a different machine (to go through the steps again, following the **ls2 iwiki page**.11:59
octaviusAll scripts up to hdl-dev-ls2 look good (logs don't show any errors).11:59
octaviushdl-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
octaviusI 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@> has quit IRC12:05
*** octavius <octavius!~octavius@> has joined #libre-soc12:06
*** Ritish <Ritish!~Ritish@> has quit IRC12:06
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC13:06
*** ibot` <ibot`!~supybot@libre-soc.org> has joined #libre-soc13:15
*** mx08_ <mx08_!~mx08@user/mx08> has joined #libre-soc13:17
*** josuah_ <josuah_!~irc@> has joined #libre-soc13:17
*** markos_ <markos_!~Konstanti@static062038151250.dsl.hol.gr> has joined #libre-soc13:20
*** mx08 <mx08!~mx08@user/mx08> has quit IRC13:20
*** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has quit IRC13:20
*** ibot <ibot!~supybot@libre-soc.org> has quit IRC13:20
*** josuah <josuah!~irc@> has quit IRC13:20
*** markos <markos!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC13:20
*** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc13:21
lkclprogrammerjake, 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 avoid13:41
lkclghostmansd, for now, yes.13:41
lkcloctavius, 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-soc13:43
ghostmansdlkcl, for now yes what? :-)13:44
ghostmansdsorry, I'm missing which of the messages you reply13:44
lkcl> <ghostmansd> lkcl, as for SVP64 behaving as non-prefix: it breaks the least astonishment principle13:45
lkclbecause currently using EXT001.13:45
lkclwhen 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 different13:46
ghostmansdMy 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
lkclghostmansd, it's not that simple13:47
ghostmansdAgain something RTL-related?13:47
ghostmansdOK, what'd be the problem with adding a nop?13:47
lkclthe "punishment" for 64-bit alignment is increased binary size13:47
ghostmansdDo you expect nops to happen often?13:47
ghostmansdI mean, it's once per 64 bytes13:47
lkclwhich would destroy the premise that SVP64 reduces binary size13:48
ghostmansdbytes, not bits13:48
lkclwhen we are already under pressure from having to go to 64-bit13:48
lkclthat in turn puts pressure on the compiler toolchain to attempt to minimise the nops13:48
lkclbut the penalty at the decode phase of programmerjake's suggestion is show-stoppingly to completely compromise high-performance multi-issue decoding13:49
lkclso there is a hard upper limit (not doing what programmerjake suggested as it is catastrophic) based on HDL13:50
lkcland there is a soft lower-limit (driving force) to reduce binary size13:50
lkclthe compromise between those two is to prohibit alignment across a 16-word boundary.13:51
lkclwhich obviously a multiple of that fits into a L1 Cache Line size13:51
lkclthus the decoder may load an entire cache line, break that cache line down into (minimum) 16-word block sizes13:52
lkcland analyse all of them for multi-issue decoding and identification of instruction start-points13:52
ghostmansdwhat if prefix fits the cache but the suffix doesn't?13:52
ghostmansdBut nops are for this exact purpose13:53
lkclthat's the nightmare scenario that is catastrophically complex to deal with in hardware13:53
lkcla 16-word aligned rule solves the exact same thing13:53
lkclexcept it does actually allow for crossing 32-64-64-32 *within* a 16-word aligned boundary13:54
lkclthus reducing executable size13:54
lkclIBM is not expecting a significant number of 64-bit instructions to be interleaved with 32-bit13:54
lkclwe are anticipating a LOT of 32-bit instructions to be interleaved with 64-bit prefixed instructions13:54
ghostmansdIn our case there will be such a number13:54
ghostmansdIsn't it?13:55
lkclso the penalty of 64-bit alignment is far more severe than for IBM's EXT001 prefixing13:55
lkclsorry 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-bit13:55
lkclyes. overlap there :)13:56
ghostmansdBasically what you wrote below :-)13:56
lkcli answered at the same time you asked the question :)13:56
lkclso this would be fine:13:56
ghostmansdAsking the right question is the half of the answer13:56
lkclword 0   1   2   3 .... 1513:56
lkcl  | 32  | 64  .    | 64 ... |  32 |13:57
lkclbut this would be prohibited13:57
lkclword   ... 15 | (next 16-word line)   | 0   113:57
lkcl        64-bit starting position 15 of 1 cache line, crossing over to position 0 of the next13:58
lkclthat's the "prohibited" proposal13:58
ghostmansdOK... we should adopt the gas so that it doesn't perform the alignment for SVP6413:58
lkclthis same exact concept is what is already part of Power ISA Virtual Memory (at a 1 MB boundary - i think.)13:59
lkclthe hardware-complexity of crossing that boundary and detecting page-fault is so complex that it's permitted to throw a Page Fault exception14:00
lkcland let software deal with it14:00
lkclwell... 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 you14:00
lkcland it needs discussion with the OPF ISA WG anyway14:01
lkclthey ultimately are the ones that make the decision14:01
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC14:11
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:11
*** Ritish <Ritish!~Ritish@> has joined #libre-soc14:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:39
programmerjakelkcl: 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
programmerjakeit 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
programmerjakereducing 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
programmerjakeand 16-byte blocks quadruple the code-size penalty14:53
programmerjakes/8-byte blocks or smaller/smaller than 16-byte blocks/14:54
lkclprogrammerjake, no.15:33
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc15:36
programmerjakeso 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
programmerjakeimho you'll likely arrive at a solution basically identical to my keep-last-32-bits idea15:38
*** Ritish <Ritish!~Ritish@> has quit IRC15:38
programmerjakeand 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@> has quit IRC17:10
ghostmansdI offically announce: _insns array is a total killjoy, but I won't do anything around it for now.18:49
ghostmansdI spent several hours around dsld/dsrd just to find that this damn array needs "dsld." and "dsrd." entries as well.18:49
ghostmansdWe 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
ghostmansdI'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-soc18:54
ghostmansdThe insndb creation takes too much time: it has to parse all CSVs, all markdown, whole fields.text...18:55
ghostmansdWe always do it via `DB = Database(find_wiki_dir())` form.18:55
ghostmansdAny ideas how to make this cacheable?18:55
ghostmansdThat 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
ghostmansdThe only way I'm thinking of is some dirty play with metaclasses.18:57
ghostmansdBut perhaps there's some simpler and intuitive way, e.g. lru_cache equivalent on the class?18:58
ghostmansdSo that _different_ modules importing Database class could have processed it quickly.18:58
programmerjakeimho just set its metaclass to a class with lru_cache on its __call__19:02
programmerjakeclass Meta(type): @lru_cache(typed=True, maxsize=None) def __call__(self, *args, **kwargs): return super().__call__(*args, **kwargs)19:05
programmerjakeclass Database(Meta): ...19:05
ghostmansdYeah metacls.__call__ was exactly the stuff I've been thinking about, too...19:05
ghostmansdBut perhaps there's a simpler way?19:05
programmerjake^ seems simple enough to me...19:05
ghostmansdWouldn't caching class's __init__ be sufficient?19:05
ghostmansdI'm asking because I'm not that advanced in functools.lru_cache19:06
programmerjakeno, cuz __init__ isn't what decides which instance is returned19:06
ghostmansdAnd cached_property19:06
ghostmansdHm, right. What about __new__?19:06
programmerjake__init__ still gets run even if __new__ returns an existing object19:07
programmerjakecached_property is limited to properties19:07
ghostmansdYeah but lru_cache isn't19:08
ghostmansdFrankly, considering the huge amount of different formats I've been thinking of accumulating these into yaml/json/whatever as a _temporary_ file19:08
ghostmansdParsing this would have been simpler than iterating over all files again19:09
ghostmansdBut I bet Luke would say something about readable and maintainable CSVs, eh? lkcl19:09
programmerjakelru_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 retval19:10
programmerjakeso lru_cache isn't treated specially19:10
ghostmansdAh, fuck. So it also considers self, right?19:11
ghostmansdAnd will return different results on different selves19:11
ghostmansdEven if other parameters are the same...19:11
programmerjakeone other simple option is just assigning a global: DATABASE = Database(...) and just use the global rather than constructing a new instance anywhere19:12
programmerjakeghostmansd: yes19:12
ghostmansdThen metaclass is better since it hides the global19:14
ghostmansdOK I'll think about it. Thanks for advice and suggestions programmerjake!19:14
programmerjakethough 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
programmerjakeso imho the metaclass approach is best19:16
programmerjakethough imho you'll also want to run find_wiki_dir() from inside Database() so that gets cached too19:18
programmerjakeyou could name the metaclass CachedConstructor (it isn't technically a singleton since calling __call__ with different args gives different instances) and put it in nmutil19:20
ghostmansdThe latter is quite an unlikely scenario if nm stands for nMigen.19:23
ghostmansdI want this module to be as decoupled and standalone from nMigen as possible.19:23
ghostmansdIn fact, if it's coupled to nMigen, the whole thing is fucked up beyond the catastrophe.19:24
programmerjakeit 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-soc19:32
*** octavius <octavius!~octavius@> has joined #libre-soc20:25
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC21:24
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc21:25
ghostmansdlkcl, programmerjake, there're two updates on tasks21:49
ghostmansdAlso this: https://bugs.libre-soc.org/show_bug.cgi?id=964#c521:50
ghostmansdlkcl, is https://libre-soc.org/task_db active?22:04
*** octavius <octavius!~octavius@> has quit IRC22:13
programmerjakeghostmansd: 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 wrong22:17
programmerjakeplease post a good enough description that the specific tests you're talking about can be found22:18
programmerjakeFAILED 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
programmerjakeghostmansd[m]: yeah, imho this is a gitlab bug22:30

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