| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 00:51 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:51 | |
| klys_ | lkcl, it intrigues me that you would be donating to me, as I have not been working on libre-soc myself. | 01:28 |
|---|---|---|
| klys_ | lkcl, how come you have me as a recipient? I have not been working on your project. | 01:29 |
| programmerjake | i'd guess because you contributed in the past...contributions don't have to be code, they can be ideas too | 01:30 |
| klys_ | there is a legal problem I have with handling money. and I just spent 1500 but, if I were to receive enough to put my bank account over 2k then bam I lose the money | 01:30 |
| klys_ | I get a check every two weeks and so I would probably have a fiar chance of going over if you gave me 1300 like you said | 01:32 |
| klys_ | my next paycheck for work at deseret industries of provo arrives a week from friday. | 01:32 |
| klys_ | I have to pay careful attention to that because I am an insurance recipient (for now anyways) or else I lose my place of residence. | 01:33 |
| klys_ | also I need documentation if I get hired anywhere because the dep't. office needs all my figures. | 01:34 |
| klys_ | well, as long as programmerjake's here... | 01:35 |
| klys_ | have you figured anything out about that bug report from last night? | 01:35 |
| klys_ | it didn't look too promising except I remember there were a few suggestions in there | 01:36 |
| programmerjake | the .pyi bug? no, nothing new | 01:38 |
| klys_ | "Checking code based on stub files: no current solution, unless you get something using retype to work" | 01:38 |
| programmerjake | iirc i've been to DI in provo before... 5-10yr ago | 01:39 |
| klys_ | neat. I work in the back room sizing clothes. | 01:39 |
| programmerjake | also, if you get paid by nlnet, it would be a donation fron nlnet, not employment | 01:40 |
| klys_ | oh? well I worry about how long that would take to go through | 01:40 |
| programmerjake | in my experience, usually 1-3 weeks since submission | 01:41 |
| programmerjake | I'd imagine you could ask them to split the payment into a few pieces so you don't go over your $2000 limit... | 01:42 |
| klys_ | I have been building an Epyc 3 server system for my 4U rackmount eatx case. so far I have a dual-socket motherboard and 28-core cpu. ordered 256GB samsung a-class ram this week. | 01:42 |
| klys_ | next week I'll get a high end (~280w tdp) cooler and some heat spreaders for the ram. | 01:43 |
| programmerjake | nice! all my servers are mostly just old pc parts i had lying around -- amd fx 8-core and ryzen 2600x | 01:44 |
| klys_ | I can only do limited onlining with the current firewalled local wifi situation | 01:44 |
| klys_ | may end up getting a 2TB nvme disk and using it all for swapspace | 01:46 |
| programmerjake | hmm, you could probably bypass that with a wireguard vpn if you wanted to...rent a small cloud server somewhere and install wireguard on it | 01:46 |
| klys_ | I have a couple of vps servers up, one is http://show.ing.me/ and the other is https://words.showing.beauty/ | 01:47 |
| programmerjake | that's what I'm doing so build.libre-soc.programmerjake.tk is publicly accessible | 01:47 |
| klys_ | they are low-end vps service | 01:47 |
| klys_ | occasionally (like every week or so) I get outages | 01:48 |
| klys_ | it might help to script the reconnect, though bandwidth is limited to 50% of the carrier because only 7-bit ascii can pass the firewall. | 01:49 |
| programmerjake | wait, so you can't just use udp connections? sad firewall... | 01:50 |
| klys_ | yeah it does censorship and all that | 01:50 |
| programmerjake | wireguard runs over udp so it has very low additional latency, unlike most other vpns | 01:51 |
| klys_ | I should be moving sometime in the coming year and then I'll subscribe to internet access hopefully through comcast. | 01:51 |
| programmerjake | ok, hopefully you get decent internet, a lot of isps have pretty terrible reputations... | 01:52 |
| klys_ | yeah. so, the server is pretty half-baked for now, it might be a few months before I have something you could login to. | 01:52 |
| klys_ | of course, with a few extra bucks and a ulx3s 85f board you might get a bit more of my attention | 01:54 |
| programmerjake | oh, also, why would you need 2TB of swap?!! i have 32gb of ram and haven't needed swap at all on my desktop... | 01:54 |
| klys_ | because I'd be running complementary vm's for users of this ridiculously high-functioning system | 01:55 |
| klys_ | it's a dual socket system so it could conceivably have 64 more cores | 01:56 |
| programmerjake | and 128gb (iirc) of ram isn't sufficient? do you have 10000 vms or something? | 01:56 |
| klys_ | yea I want to high-ball the number of services I'm providing... :) | 01:57 |
| programmerjake | 128gb is 4gb/core | 01:57 |
| klys_ | also it's 2gb/thread | 01:57 |
| klys_ | or...with 28/56 let'sr ecalculate | 01:57 |
| programmerjake | more than my desktop which has 1.333gb/thread | 01:57 |
| klys_ | with 56 threads that's 4.5714 GB/core | 01:58 |
| klys_ | well per thread | 01:58 |
| programmerjake | 2TB is so absurdly high that unless you have a specific program in mind, i'd rather use it for more filesystem space | 01:59 |
| klys_ | there'll be another disk at this rate I'm sure | 02:00 |
| klys_ | the mobo has two mini-sas connectors | 02:01 |
| Veera[m] | <Veera[m]> "lkcl: I ran build_full_4ksram_re..." <- ahem: read lkcl mail and found the generating gds file* | 02:02 |
| klys_ | lkcl, I have been looking through my gmail account trying to find your correspondence and I'm drawing a blank. I also rummaged through my safe-mail account and no dice. pm me what you had for my email. | 02:15 |
| programmerjake | i was looking too, couldn't find anything... | 02:15 |
| klys_ | lkcl, perhaps you were thinking of kyle1 (kylel1), he hasn't talked with you since last year it seems. | 03:17 |
| klys_ | I was pouring through the logs and reviewed everything I have not pasted any email address nor the word "email" in the channel so far. | 03:18 |
| klys_ | only thing I can think is if it appeared in the chat for a meeting I attended last year sometime | 03:21 |
| klys_ | there seems to have been a meeting where we discussed pipelining? | 03:22 |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 03:26 | |
| klys_ | in any case if the email you have on file matches my hostmask, that email server would not be accepting messages because procmail was compromised a little while back. | 03:27 |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 03:27 | |
| klys_ | programmerjake, http://show.ing.me/swap-25apr2022.png | 03:41 |
| programmerjake | yeah, i'm firmly in the no swap camp if your ram's big enough | 03:58 |
| programmerjake | lkcl: I'm working on a formal proof of PLRU, but I'm running into an issue: how does `BITS` and `TLBSZ` correlate with the number of ways in the cache? I would have expected BITS to be the number of ways, but looking at the diagrams in plru.py and the math for calculating TLBSZ, that makes no sense...it's off by around a factor of 2. | 07:16 |
| programmerjake | I'm thinking whoever converted that botched the math, but I'm not 100% sure and I don't want to fix it and have our cpu unexpectedly change how many TLB or cache ways it has and costing a whole lot more/less... | 07:18 |
| programmerjake | https://git.libre-soc.org/?p=nmutil.git;a=blob;f=src/nmutil/plru.py;h=80c67571d42adcc48925181116acf23e445c1548;hb=6e8678a9beabcc1577a1d789a211c0272fda10f6 | 07:25 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has quit IRC | 07:28 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-188-32-220-156.ip.moscow.rt.ru> has joined #libre-soc | 07:41 | |
| *** octavius <octavius!~octavius@216.147.93.209.dyn.plus.net> has joined #libre-soc | 09:48 | |
| lkcl | programmerjake, i have absolutely no idea. it's a direct conversion from microwatt. therefore *please do not change it in any way shape or form* | 09:54 |
| lkcl | klys_, ahhh. yes i was. thank you. | 09:55 |
| lkcl | Veera[m], honestly i don't know. cougar does indeed take an insane amount of time, and can be terminated. as long as the ".gds" file has been created (chip_r.gds) that's the important bit | 09:56 |
| markos | lkcl, I just found this, I remember you were looking for DDR3 fpga implementation, but you probably already know of this https://github.com/ZiyangYE/General-Slow-DDR3-Interface | 09:57 |
| markos | and at the same place I also found this link: https://github.com/ZiyangYE/General-Slow-DDR3-Interface | 09:58 |
| markos | argh | 09:58 |
| markos | https://github.com/ultraembedded/core_ddr3_controller | 09:58 |
| lkcl | markos, nice! | 09:58 |
| lkcl | on the list/wiki they go... | 09:59 |
| markos | saw them mentioned on some retro forum, some people are keen on reimplementing ancient hardware on fpgas :) | 10:00 |
| markos | I wish I knew HDL/Verilog | 10:00 |
| lkcl | i collect them here https://libre-soc.org/shakti/m_class/DDR/?updated | 10:00 |
| lkcl | markos, honestly? really? no... you don't :) | 10:00 |
| markos | hahaha | 10:01 |
| lkcl | i "worked them out" - took about 6 months - the initial barrier to understanding was 3-4 weeks (ish) | 10:01 |
| markos | well, I've been doing software for the past 30 years, and just recently I realized that I actually like hardware too and have been keeping myself busy with retro computers, because they're easy to understand | 10:01 |
| markos | "easy" | 10:02 |
| lkcl | but it was gate-level diagrams (yosys "show top") that helped the most | 10:02 |
| markos | easier than today's computers at any rate | 10:02 |
| markos | I bought some books on electronics and verilog even, still waiting for me to read them, too busy these days | 10:03 |
| lkcl | yosys "show top" chucks the connections between basic boxes at you. and if you've done schematics (logic diagrams) or even heard of the educational program "scratch", they're just so much more ridiculously easy to understand | 10:04 |
| markos | well, electronics is easier I already have the physics background | 10:04 |
| lkcl | there you go | 10:04 |
| markos | it's a huge gap between electronics courses from almost 30y ago to reading and repairing full computers schematics | 10:04 |
| markos | but I *have* managed to repair a dozen spectrums and a couple of amigas :) | 10:05 |
| markos | so I'm on a right track,it just takes time | 10:05 |
| lkcl | things like verilog registers make no sense how/why they get created until you see the DFFs that result from using the right verilog statements | 10:05 |
| lkcl | nice! | 10:05 |
| lkcl | seriously, though, verilog/HDL is like the equivalent of a 10x microscope on top of computing in assembler | 10:06 |
| markos | I have a small lab with a digital oscilloscope and I can at least check if the signals are going to the chips, but it's just able to handle low frequencies (up to 20Mhz) | 10:06 |
| lkcl | then yosys "show top" is like another 10x microscope zoom on top of that | 10:06 |
| markos | lol | 10:06 |
| lkcl | pffh 20mhz is perfect for old computers | 10:07 |
| lkcl | ghostmansd, i got rid of the duplicates https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=97958abd1eae81b1cc74abd85d16c5d29fd75791 | 10:08 |
| lkcl | there were *multiple* matches in the microwatt decode1.vhdl 0001 and 0000 which yes, they're deliberately meant to go through to the same line | 10:09 |
| lkcl | but by converting to patterns i could replace them with "000-" etc. | 10:09 |
| lkcl | programmerjake, yeah i honestly don't fully understand the plru.py code - i did a verbatim/naive/direct/literal/faithful translation from microwatt as best i could | 10:13 |
| lkcl | https://github.com/antonblanchard/microwatt/blob/master/plru.vhdl | 10:13 |
| lkcl | unnnfortunately, vhdl has the ability to use variables (because it is basically ADA) | 10:13 |
| lkcl | i did my best to create actual intermediary signals so that nmigen would end up creating AST-expressions that got duplicated massively in an exponential fashion (sigh) | 10:14 |
| programmerjake | i figured out the issue, afaict you mistranslated vhdl's exponentiation operator as multiplication: https://github.com/antonblanchard/microwatt/blob/050185e2caabfb7a0ec11a433955fca18781d83a/plru.vhdl#L22 | 10:20 |
| programmerjake | afaict BITS is supposed to be the base-2 log of the number of ways, or similar | 10:23 |
| lkcl | ahh deep frickin joy. | 10:23 |
| lkcl | well spotted | 10:25 |
| programmerjake | and the inputs/outputs are encoded in binary, not unary | 10:25 |
| lkcl | nggggh that's going to impact the TLB/MMU ngggggggh | 10:25 |
| lkcl | but it's a bugfix so is good to do. | 10:26 |
| programmerjake | how about i copy plru.py and fix it in there, so we can convert plru users gradually? | 10:27 |
| programmerjake | lkcl: ^ sound good? | 10:29 |
| programmerjake | can move back to plru and change all imports back once all users have converted | 10:30 |
| programmerjake | move plru2.py over plru.py again | 10:30 |
| lkcl | programmerjake, yes that's a good idea | 10:32 |
| lkcl | although there's only the one | 10:32 |
| lkcl | at least it's nondisruptive | 10:32 |
| programmerjake | there's 2 users: the caches and the formal proof i'm writing | 10:33 |
| programmerjake | edited description to describe migration plans: https://bugs.libre-soc.org/show_bug.cgi?id=909#c0 | 10:37 |
| programmerjake | moving the caches to use plru2.py will be under a different task which someone can do later | 10:38 |
| * lkcl stressing out at the thought of dealing with that already :) | 10:39 | |
| programmerjake | lkcl, please don't put docstrings on the same line as a variable assignment, autopep8 will automatically move them back to a new line: https://git.libre-soc.org/?p=nmutil.git;a=commitdiff;h=38cb2af1a5a873a8b16ec887a2930a3fb8ab4ae0 | 10:47 |
| programmerjake | rest of that commit looks fine | 10:48 |
| programmerjake | iirc we went over this before... | 10:49 |
| * lkcl grumbles. they visually look cleaner. | 12:48 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 13:45 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 13:45 | |
| *** lx0 <lx0!~lxo@gateway/tor-sasl/lxo> has quit IRC | 14:07 | |
| lkcl | holy cow | 15:27 |
| lkcl | https://news.slashdot.org/story/22/08/17/2121228/hidden-hunger-stones-reveal-drought-warnings-from-the-past#comments | 15:27 |
| lkcl | boulders placed in rivers that are now dry, across europe, with carvings in them | 15:28 |
| lkcl | one has been revealed, from 1616, with the words "Wenn du mich seehst, dann weine" -- "If you see me, then weep," | 15:29 |
| *** octavius <octavius!~octavius@216.147.93.209.dyn.plus.net> has quit IRC | 15:54 | |
| *** tplaten <tplaten!~isengaara@55d4a0b9.access.ecotel.net> has joined #libre-soc | 18:22 | |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=288d0654462ce18b85b27e01bdb35e6ddf1671e3 | 19:09 |
| lkcl | @@ -127,10 +127,12 @@ class FieldSelectableInt: | 19:09 |
| lkcl | return self._op(xor, b) | 19:09 |
| lkcl | 19:09 | |
| lkcl | def __lt__(self, b): | 19:09 |
| lkcl | - return self._op(lt, b) | 19:09 |
| lkcl | + vi = self.get_range() | 19:09 |
| lkcl | + return bool(lt(vi, b)) | 19:09 |
| lkcl | ghostmansd, be careful with that one. it is highly likely that the Simulator - i.e. the pseudocode - critically relies on the result from lt/gt being a single-bit SelectableInt | 19:10 |
| lkcl | *not* a bool | 19:10 |
| ghostmansd | Yeah that's currently what I debug :-) | 19:10 |
| lkcl | doh :) | 19:10 |
| ghostmansd | It's likeky you read my mind | 19:10 |
| ghostmansd | I found that I broke the test_caller_svp64.py | 19:11 |
| lkcl | the Simulator has a trick where it generates code to explicitly turn things into a single-bit | 19:11 |
| lkcl | can't remember the name of the function. | 19:11 |
| lkcl | onebit()? | 19:11 |
| ghostmansd | And already can see that it's caused by the fact svp64.py is broken, too | 19:11 |
| ghostmansd | yeah there's such thing | 19:11 |
| lkcl | and the compiler very deliberately sprinkles lots of them about when it encounters boolean expressions | 19:12 |
| ghostmansd | that said...keeping it like other operators breaks the code, too | 19:12 |
| ghostmansd | iirc it fails on merge method | 19:12 |
| ghostmansd | since the result is 1-bit | 19:12 |
| lkcl | merge? que? do you mean concat()? | 19:13 |
| ghostmansd | Yeah return self.merge(vi) fails on expressions like FSI(666, 64) == 0b11 | 19:13 |
| lkcl | ermermerm... | 19:13 |
| ghostmansd | oops, should've used bitmap there | 19:13 |
| lkcl | 1 sec | 19:13 |
| lkcl | yes i would expect a comparison against a non-SelectableInt to fail | 19:14 |
| lkcl | try FSI(666,64) == SelectableInt(2, 0b11) | 19:15 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 19:15 | |
| ghostmansd | how would we simplify stuff like `if prefix.pid != 0b11:` work? | 19:15 |
| lkcl | everything in SelectableInt is very strictly bit-length-defined | 19:15 |
| ghostmansd | I mean, I _could_ ensure it's bit-length-enabled... | 19:15 |
| ghostmansd | but it's way too much to type :-) | 19:16 |
| lkcl | that's not optional, it's absolutely essential | 19:16 |
| ghostmansd | File "/home/ghostmansd/src/openpower-isa/src/openpower/decoder/selectable_int.py", line 340, in __getitem__ | 19:16 |
| ghostmansd | assert key < self.bits, "key %d accessing %d" % (key, self.bits) | 19:16 |
| ghostmansd | AssertionError: key 1 accessing 1 | 19:16 |
| ghostmansd | That's what I experienced | 19:16 |
| lkcl | (and a total pain in the ass to write pseudocode for, but hey) | 19:16 |
| lkcl | yep, that means you're trying to index something that's out of range of the strictly-defined length of the SelectableInt | 19:17 |
| lkcl | it's a valid error, in other words | 19:18 |
| ghostmansd | if prefix.pid != _SelectableInt(0b11, 2): | 19:18 |
| ghostmansd | this doesn't work either | 19:18 |
| lkcl | hang on - do you have a test that's committed already that i can run? | 19:18 |
| ghostmansd | But perhaps I fucked up the classes | 19:18 |
| ghostmansd | Well I have binary with svp64 instruction | 19:19 |
| ghostmansd | Without elf headers | 19:19 |
| ghostmansd | 0000000 00 00 40 05 14 02 41 7c | 19:19 |
| lkcl | can you add a simple test i can run? | 19:19 |
| ghostmansd | in a moment | 19:19 |
| lkcl | (helps as a unit test anyway) | 19:19 |
| lkcl | ok. | 19:19 |
| lkcl | i'll go out for a walk | 19:19 |
| lkcl | or watch some cute kittens on youtube baraban-tv channel or something | 19:20 |
| ghostmansd | lkcl, submitted the reproducer | 19:25 |
| ghostmansd | python3 src/openpower/sv/trans/pysvp64dis.py | 19:25 |
| ghostmansd | pysvp64dis branch | 19:26 |
| ghostmansd | I basically wanted to compare the FSI (this is exactly what we have as fields in the updated fields classes) | 19:27 |
| ghostmansd | Ah no it seems to work | 19:34 |
| ghostmansd | With changing to SelectableInt instead of plain int | 19:34 |
| ghostmansd | but only if I use bool() in __eq__/__lt__ | 19:35 |
| ghostmansd | anyway, please check the recent commit in that pysvp64dis branch | 19:35 |
| ghostmansd | it has the whole reproducer | 19:35 |
| ghostmansd | Yeah I think I fould the way to solve it. | 19:39 |
| ghostmansd | On one hand, I cannot use the usual merge() method with SI of one bit... | 19:39 |
| ghostmansd | the recent commit | 19:41 |
| ghostmansd | ...shows what on the other hand :-) | 19:41 |
| ghostmansd | so, in this regard, the stuff works with onebit() | 19:42 |
| ghostmansd | now it's time to understand what did I break with src/openpower/decoder/isa/test_caller_svp64.py | 19:42 |
| ghostmansd | I'll check svp64.py, likely I broke the the way we handle prefix or RM value | 19:43 |
| ghostmansd | It seems I broke the comparison somehow, according to logs. | 19:58 |
| ghostmansd | OK I found the issue | 20:14 |
| *** tplaten <tplaten!~isengaara@55d4a0b9.access.ecotel.net> has quit IRC | 20:24 | |
| ghostmansd | OK src/openpower/decoder/isa/test_caller_svp64.py also works | 20:40 |
| ghostmansd | That said, I don't yet fully understand what's broken | 20:40 |
| ghostmansd | Or, well, rather, why | 20:41 |
| *** octavius <octavius!~octavius@216.147.93.209.dyn.plus.net> has joined #libre-soc | 20:55 | |
| ghostmansd | lkcl, I submitted the minimal reproducer | 20:58 |
| ghostmansd | Notice the very first modified line: this is exactly what I had to fix so that test works. | 20:58 |
| ghostmansd | That said... I don't understand why it doesn't work when I switch to FSI instead of SI. | 20:59 |
| ghostmansd | This FSI should be a simple SI with br=range(SI.bits). | 21:00 |
| ghostmansd | That is, for me these two records should be identical | 21:02 |
| ghostmansd | SVP64RMFields(value=0x2da0, bits=24) | 21:02 |
| ghostmansd | FieldSelectableInt(si=SVP64RMFields(value=0x2da0, bits=24), br=BitRange([(0, 0), (1, 1), (2, 2), (3, 3), (4, 4), (5, 5), (6, 6), (7, 7), (8, 8), (9, 9), (10, 10), (11, 11), (12, 12), (13, 13), (14, 14), (15, 15), (16, 16), (17, 17), (18, 18), (19, 19), (20, 20), (21, 21), (22, 22), (23, 23)])) | 21:02 |
| ghostmansd | And I don't understand why the first works with FSI.eq but other doesn't. | 21:03 |
| ghostmansd | Fuck it's been almost 15 hours since I work, minus eating and other distractions. Enough for today. | 21:05 |
| ghostmansd[m] | lkcl, you already probably realized the ultimate goal beyond all this dubious activity. I want the fields to be shared by all code; also, some code will be dropped from consts.py module, and replaced with fields, too. I already moved the Instruction class and all its descendants to power_insn.py. There are also classes PrefixedInstruction and SVP64Instruction; the last one has the prefix inherited from the fields we hav | 21:14 |
| ghostmansd[m] | and will work with power_fields.py to decode the instructions. The goal is to also provide some stuff usable for the other code around here. | 21:14 |
| ghostmansd[m] | As it was done with the instruction records, I'd like to share the decoding part, too. | 21:15 |
| lkcl | ghostmansd[m], will take a look | 21:20 |
| lkcl | ghostmansd[m], for when you're awake (i.e. not today) | 21:49 |
| lkcl | can i suggest instead of allowing this: | 21:49 |
| lkcl | SelectableInt<--FieldSelectableInt<--FieldSelectableInt | 21:50 |
| lkcl | to do | 21:50 |
| lkcl | SelectableInt<--FieldSelectableInt (as is the case now) | 21:50 |
| lkcl | but | 21:50 |
| lkcl | if the double-referencing is attempted perform a *de-reference* of the fields-of-fields | 21:51 |
| lkcl | crushing the lookups *down* to only the *one* SI<--FSI | 21:51 |
| lkcl | the thing about FSI is that as you probably noticed it is *not* a copy of the SI it contains | 21:51 |
| lkcl | it *actually* allows for arithmetic *on the SI* | 21:52 |
| lkcl | but SI<-FSI<-FSI is far too complex (and slow) | 21:52 |
| lkcl | therefore if you can do a FSI<-FSI resolution of the indices *in the constructor*, down to just the one FSI, you end up using the well-tested code-path | 21:53 |
| lkcl | this was too strict: | 21:53 |
| lkcl | def __init__(self, value, bits=None): | 21:53 |
| lkcl | if isinstance(value, SelectableInt): | 21:53 |
| lkcl | if bits is not None: | 21:53 |
| lkcl | raise ValueError(value) | 21:53 |
| lkcl | i changed it to: | 21:54 |
| lkcl | # check if the bitlength is different. TODO, allow override? | 21:54 |
| lkcl | if bits != value.bits: | 21:54 |
| lkcl | raise ValueError(value) | 21:54 |
| lkcl | but... ngggh, i am sort-of feeling that it should be allowed (because it's a way to truncate the SI to a new bitwidth) | 21:55 |
| lkcl | and sort-of not | 21:55 |
| lkcl | commit 5bf3c705cc0736cf34456d173fc4c50da5aba037 | 21:56 |
| lkcl | "fix" error introduced in sv/trans/svp64.py by using svp64_rm.spr | 21:56 |
| lkcl | instead of spvp64_rm | 21:56 |
| lkcl | also did that ^ | 21:56 |
| ghostmansd[m] | lkcl, I've thought about this model with fields... | 21:58 |
| ghostmansd[m] | My feeling is that they should also get SI by reference | 21:58 |
| ghostmansd[m] | And then pass this SI to all the properties | 21:59 |
| ghostmansd[m] | This way, for example, given SVP64Instruction... | 21:59 |
| ghostmansd[m] | The prefix would be PrefixFields(insn[32:64]) | 22:00 |
| ghostmansd[m] | And also it should be allowed to use some field inside another field | 22:00 |
| ghostmansd[m] | That is, RM field inside Prefix should be somehow mapped to RM class... | 22:01 |
| ghostmansd[m] | There is never more than 1 indirection level with FSI | 22:02 |
| ghostmansd[m] | Whenever ones try to instantiate FSI from another FSI, indices are simply converted | 22:02 |
| ghostmansd[m] | So no, we don't invoke two __getitem__ methods if we instantiate FSI from FSI | 22:03 |
| ghostmansd[m] | We always operate on the SI directly | 22:03 |
| ghostmansd[m] | So the overhead can be neglected | 22:04 |
| lkcl | whewwww | 22:34 |
| *** octavius <octavius!~octavius@216.147.93.209.dyn.plus.net> has quit IRC | 23:33 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
