| programmerjake | sinpi is how the user can work around fp not being able to represent large multiples of pi | 00:00 |
|---|---|---|
| programmerjake | to some extent, anyway | 00:00 |
| programmerjake | e.g you still can't compute sinpi(2^1000+0.5) since the input will be rounded to 2^1000 before sinpi ever sees it | 00:02 |
| programmerjake | but sinpi still correctly computes sinpi(2^1000) = 0 | 00:03 |
| programmerjake | lkcl: what do you think of adding support for XER.SO but not changing any existing uses of XER[SO]...that way we can write XER.SO if we like in new instructions | 00:04 |
| programmerjake | i was also thinking the parser could translate XER[SO] to XER.SO internally | 00:05 |
| programmerjake | so the markdown stays XER[SO] but behaves like XER.SO and we don't need a SO constant | 00:06 |
| programmerjake | the translation would probably be for indexing any all-caps variable with any single all-caps name...no compound expressions...we'd have to watch out for things like V[XLEN] tho | 00:07 |
| lkcl | as long as the original syntax may be auto-generated i don't mind | 00:08 |
| programmerjake | k, sounds good! | 00:08 |
| lkcl | please please remember at all times that this is literally the specification for the Power ISA. all and any changes require a massive (implicit) cost to propose the corresponding changes to the ISA WG | 00:09 |
| programmerjake | one other thing i thought of: adding an explicit syntax that translates to subscript, rather than using v[] which conflicts with when the pdf uses [] literally | 00:18 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 01:17 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 01:30 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:47 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 02:47 | |
| programmerjake | I changed ISACallerHelper to take an initial required FPSCR value, but I left the two properties in because that's what XLEN does presumably to handle the case when FPSCR is changed in self.namespace | 06:13 |
| programmerjake | testing... | 06:14 |
| programmerjake | lkcl, as part of implementing all the bfp_* functions needed by fcvt*, I need to add a class that's unlike SelectableInt in that it has an effectively infinite size (bigger than 256-bits needed in some cases), it is not an integer, and it is MSB0, and sliceable, so I'm creating a new class for that. | 06:16 |
| programmerjake | this is for significand in the floating-point working format | 06:17 |
| programmerjake | also the bfp_* class ^ needs an infinite number of trailing zeros or an infinite number of trailing ones ... you can think of it as a bit-reversed python int | 06:23 |
| programmerjake | actually, I think I'll implement it as a bit-reversed python int... | 06:24 |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has quit IRC | 08:00 | |
| *** Ryuno-KiAndrJaen <Ryuno-KiAndrJaen!~ryuno-kim@2001:470:69fc:105::14ed> has quit IRC | 08:00 | |
| *** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC | 08:00 | |
| *** sadoon[m] <sadoon[m]!~sadoonsou@2001:470:69fc:105::2:bab8> has quit IRC | 08:00 | |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has quit IRC | 08:00 | |
| *** pangelo[m] <pangelo[m]!~pangeloma@2001:470:69fc:105::3ec5> has quit IRC | 08:00 | |
| *** vaino[m] <vaino[m]!~vainomatr@2001:470:69fc:105::3:5474> has quit IRC | 08:01 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has quit IRC | 09:26 | |
| *** programmerjake <programmerjake!~programme@2001:470:69fc:105::172f> has joined #libre-soc | 09:40 | |
| *** markos_ <markos_!~markos_@static062038151250.dsl.hol.gr> has joined #libre-soc | 09:54 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has joined #libre-soc | 09:54 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 10:06 | |
| *** psydroid <psydroid!~psydroid@user/psydroid> has joined #libre-soc | 10:15 | |
| *** sadoon[m] <sadoon[m]!~sadoonsou@2001:470:69fc:105::2:bab8> has joined #libre-soc | 10:15 | |
| *** Ryuno-KiAndrJaen <Ryuno-KiAndrJaen!~ryuno-kim@2001:470:69fc:105::14ed> has joined #libre-soc | 10:15 | |
| *** octavius <octavius!~octavius@92.40.169.164.threembb.co.uk> has joined #libre-soc | 11:15 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 11:38 | |
| lkcl | programmerjake, no please don't proceed with things like that without discussing it! | 12:00 |
| lkcl | there already exists a mechanism for "unlimited length SelectableInt" | 12:00 |
| lkcl | search for "256" in SelectableInt and simply increase that number. better: put it as a constant rather than a magic-number | 12:01 |
| lkcl | i'm sorting that out now | 12:05 |
| lkcl | all that's needed to have an infinite number of trailing 1s is to use EXTS. job done. | 12:07 |
| *** cesar <cesar!~cesar@2001:470:69fc:105::76c> has joined #libre-soc | 12:18 | |
| *** pangelo[m] <pangelo[m]!~pangeloma@2001:470:69fc:105::3ec5> has joined #libre-soc | 12:19 | |
| *** vaino[m] <vaino[m]!~vainomatr@2001:470:69fc:105::3:5474> has joined #libre-soc | 12:19 | |
| lkcl | i'm increasing it to 1024 and adding a new const EFFECTIVELY_UNLIMITED | 12:28 |
| lkcl | EXTS was designed *over two years ago* to always return effectively unlimited numbers, and all operations call check_extsign to perform lazy-sign-extension to the *actual* bit-length once it is known | 12:30 |
| lkcl | there is *no need* to add entirely new classes, please remember to consult and ask *before* going ahead with radical decisions that take up a lot of your valuable time | 12:30 |
| lkcl | ok unit tests passed after extending to 1024 | 12:31 |
| lkcl | it would be much better to have that at the absolute bare-minimum size that cannot be confused with anything (257, 258) as it places a large execution burden on CPUs | 12:34 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 12:39 | |
| *** octavius <octavius!~octavius@92.40.169.164.threembb.co.uk> has quit IRC | 13:24 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 13:36 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 13:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 14:10 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.220> has joined #libre-soc | 14:12 | |
| *** knar <knar!~knar@2401:4900:1f26:2e8:afdc:414d:d111:8c4> has joined #libre-soc | 14:13 | |
| knar | hello, so i have been dwelling in errors while installing cavatools. | 14:20 |
| knar | here is what i did. | 14:20 |
| knar | $git clone https://github.com/phaa-eu/cavatools | 14:20 |
| knar | then cloned all the 4 repos into a directory riscv-tools. | 14:20 |
| knar | checkedout risv-opcodes to relavant commit. | 14:20 |
| knar | cavatools needed riscv-isa-sim to be built so on to that repo. | 14:20 |
| knar | set RISCV env to the riscv-tools directory i just created. | 14:20 |
| knar | $ mkdir build | 14:20 |
| knar | $ cd build | 14:20 |
| knar | $ ../configure --prefix=$RISCV | 14:20 |
| knar | $make | 14:20 |
| knar | then i get this error | 14:20 |
| knar | https://imgur.com/a/DD6YsuU | 14:20 |
| knar | ig im not able to make out what the env variables should be set to. | 14:21 |
| knar | any help would be much appreciated | 14:21 |
| knar | also I found out riscv-opcodes have changed their filenames of the opcodes so had to go back to a commit in 2021 to get the required format needed for cavatools | 14:22 |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:00 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:05 | |
| lkcl | knar, in all honesty none of us here have compiled it, and yes cavatools was developed around 2021. for the time-being you are on your own, it would be very helpful if you could make sure to take notes and put them in the wiki and/or bugtracker | 15:19 |
| lkcl | if you need a bugzilla account and do not already have one please let me know if you are happy with the Charter https://libre-soc.org/charter/ then PM me an email address and i will create an account for you | 15:20 |
| *** knar <knar!~knar@2401:4900:1f26:2e8:afdc:414d:d111:8c4> has quit IRC | 15:21 | |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:39 | |
| vaino[m] | Hello everyone, I'm a student from Finland, very interested in hardware. I'm hoping to deepen my knowledge following the developments here and maybe contribute once I get the hang of this stuff. Looking forward to interacting with you all. :) | 15:40 |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 15:44 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.56.220> has quit IRC | 15:51 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 15:52 | |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 16:03 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:04 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has left #libre-soc | 16:04 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:04 | |
| lkcl | vaino[m], cool! welcome! | 16:26 |
| lkcl | we have people from all over the world - six timezones i think (!) | 16:27 |
| lkcl | you know we have NLnet grants so you can not just "help" you can actually get paid for it | 16:30 |
| lkcl | what course are you doing at university? (i assume you're at uni?) | 16:31 |
| vaino[m] | I've read about the grants, I think that's wonderful :D I just finished high school actually, and I've applied for courses centred around electrical engineering and what they call "digital systems and design" | 16:43 |
| vaino[m] | I don't have much experience in all this hardware stuff like HDLs, my knowledge ends at assembly language and some basic circuitry :P | 16:45 |
| lkcl | oh nice | 16:45 |
| lkcl | well as we are all software engineers we treat HDL as "yet another programming language" | 16:46 |
| lkcl | and if you've done circuit design esp. logic gates then that's basically all that HDL is: "AWayInAProgrammingLanguageToExpressLogicGates" | 16:47 |
| lkcl | i didn't have any experience in HDL four years ago at all | 16:47 |
| vaino[m] | I see, that's neat, it's almost like all these mathematical languages in a sense | 16:51 |
| vaino[m] | for nmigen, is there a suggested simulator for testing code? is there one used preferentially | 16:52 |
| vaino[m] | if that's how it works :P | 16:52 |
| vaino[m] | Ah I see seems like nmigen has its own simulator | 16:53 |
| lkcl | nmigen contains its own si... yes :) | 16:58 |
| lkcl | there's a tutorial page / find-other-stuff page https://libre-soc.org/docs/learning_nmigen/ | 16:59 |
| lkcl | some of those you now have to use archive.org to find them (sigh) | 16:59 |
| lkcl | the devscripts should get you up-and-running very quickly | 17:00 |
| lkcl | https://libre-soc.org/HDL_workflow/devscripts/ | 17:00 |
| lkcl | follow the instructions precisely and exactly and to the letter! | 17:00 |
| lkcl | don't whatever you do try to get creative or go "i'm using OS distro X, i don't have to listen to that advice" | 17:01 |
| lkcl | if you do that, i look forward to your reaction in 3 weeks time :) | 17:01 |
| lkcl | but if you follow the instructions and it takes longer than 3 hours to get everything running, come back to us immediately ok? | 17:02 |
| lkcl | you've a system with a minimum of 16 GB RAM? | 17:02 |
| lkcl | 8 GB will be painful but just about ok | 17:03 |
| vaino[m] | yes, i do | 17:03 |
| lkcl | ok awesome | 17:03 |
| vaino[m] | thank you for the resources by the way, I appreciate it :) | 17:03 |
| lkcl | no problem :) | 17:04 |
| lkcl | btw if you stick around and want to consistently do useful stuff we can justify getting you an FPGA board | 17:04 |
| vaino[m] | sounds great, I'll see what I can do, I'll have a lot of free time to study this stuff very soon :) | 17:06 |
| lkcl | awesome. btw we have tuesday meetings online at 19:00 UTC, usually goes on randomly for 1hr30m all sorts of topics (it's an open discussion), if you're interested i can PM you the URL? | 17:08 |
| lkcl | (or email me lkcl@lkcl.net and i can add you to the google calendar-invite) | 17:09 |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:19 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:23 | |
| vaino[m] | Sure, I'll be available by then, could you PM me the link? Thanks | 17:28 |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:54 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:57 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:08 | |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:12 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:15 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:16 | |
| ghostmansd[pc] | markos, please avoid committing debug printouts :-) | 18:16 |
| markos_ | usually I don't commit them, but must have missed one, where was that? :) | 18:17 |
| ghostmansd[pc] | if needed, please use util.log | 18:17 |
| ghostmansd[pc] | power_insn.py :-) | 18:17 |
| ghostmansd[pc] | I'll revert these if they're not needed anymore, OK? | 18:17 |
| markos_ | ah yes, indeed, apologies :) | 18:18 |
| markos_ | yes, please go ahead and remove them | 18:18 |
| ghostmansd[pc] | done, thanks :-) | 18:20 |
| ghostmansd[pc] | BTW, I totally understand why you added them there | 18:20 |
| ghostmansd[pc] | that's one of the most gory places | 18:20 |
| ghostmansd[pc] | probably the most gory except of registers remapping | 18:20 |
| ghostmansd[pc] | that one still beats anything else by factor of magnitude | 18:21 |
| markos_ | trying to make out what's going on in there was hard :) | 18:21 |
| *** ghostmansd[pc] is now known as ghostmansd | 18:21 | |
| ghostmansd | no surprise, now imagine how hard was actually writing this :-D | 18:21 |
| ghostmansd | any ideas on simplifying this crap are always welcome :-) | 18:22 |
| markos_ | I would really love to have a UI for all this info, something that parses all those logs and presents them in a readable fashion, like some CPU simulators | 18:22 |
| markos_ | well, not simplifying | 18:22 |
| markos_ | but grouping in a more presentable way | 18:22 |
| markos_ | doesn't have to be a GUI | 18:22 |
| ghostmansd | you mean, about the whole information we can get from these shiny CSVs et al.? | 18:22 |
| markos_ | even curses style interface | 18:22 |
| markos_ | in the past I've used some GUI CPU simulator from Freescale | 18:23 |
| markos_ | I think it was called, simG4? simG5? | 18:23 |
| markos_ | can't remember the name | 18:23 |
| ghostmansd | like, "this insn has X operands and these bits are go like this" | 18:23 |
| ghostmansd | or do you mean logging? | 18:23 |
| markos_ | it presented a full simulation of the CPU, the currently executed program, separate places with real time info for the registers, current states, etc | 18:24 |
| ghostmansd | (what we have is not a logging, to be honest) | 18:24 |
| markos_ | that was in a UI | 18:24 |
| markos_ | window based, but it ran on Linux | 18:24 |
| ghostmansd | aaaah I get what you mean | 18:24 |
| markos_ | you could literally step into each instruction, like a debugger but much more low level | 18:24 |
| ghostmansd | yeah guessing this all from logs is hard | 18:24 |
| markos_ | it showed info about "bubbles" in the pipeline, how many cycles each instruction lost waiting for the next instruction to be decoded, or from data to be fetched from memory/L1/L2 cache, etc | 18:25 |
| markos_ | it was really powerful | 18:25 |
| markos_ | and allowed for some really careful hand tuning of the assembly code to avoid stalls, and make sure that every unit would not be left un(der)utilized | 18:26 |
| markos_ | though this was tuned to specific hardware models of the CPU, but you could select from a list | 18:26 |
| markos_ | really really powerful | 18:26 |
| markos_ | we could have something similar, I mean most of the info is there, we could just export it in a certain way (JSON?), and provide a dumb UI that just presents the info in a certain way | 18:27 |
| markos_ | realtime view of the registers/schedulers/memory/etc | 18:27 |
| markos_ | I suck at UI stuff so someone else has to do it though :-P | 18:28 |
| markos_ | lkcl, what do you think? | 18:28 |
| markos_ | we could extend pypowersim to do that, unless cavatools can do that stuff already | 18:28 |
| ghostmansd | +1 for that idea | 18:29 |
| ghostmansd | even if cavatools has the UI, having an option to export this stuff is a nice option | 18:30 |
| ghostmansd | we kinda have the basic building blocks in our simulator... I mean, any Python stuff can at least be pickled | 18:31 |
| *** octavius <octavius!~octavius@92.40.169.164.threembb.co.uk> has joined #libre-soc | 18:31 | |
| markos_ | I mean even Z80 has a ton of nice GUI simulators, why can't we :D | 18:32 |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 18:32 | |
| octavius | vaino[m], thanks for your interest! | 18:34 |
| octavius | Currently I'm working on a tutorial for Microwatt simulation (a basic scalar subset POWER core, from which Libre-SOC had much inspiration...), and hopefully a video should be available by the end of the week. | 18:34 |
| octavius | If you have trouble with nMigen, just post here, I'll try to help when I can. | 18:34 |
| octavius | (also when you see the dev list emails, my name is Andrey). | 18:34 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 18:36 | |
| *** ghostmansd[pc] is now known as ghostmansd | 18:36 | |
| *** knar <knar!~knar@2401:4900:1f26:2e8:dee5:c516:e182:de03> has joined #libre-soc | 18:42 | |
| lkcl | ghostmansd, but but i love power_insn.py! | 18:43 |
| lkcl | markos_, that's what cavatools curses-console does. | 18:43 |
| markos_ | excellent | 18:43 |
| lkcl | and also the plan is to have the model-simulator output a brain-dead-simple markdown output file | 18:44 |
| lkcl | with each "stage" as a column | 18:44 |
| markos_ | markdown? for post/offline processing? sounds like a strange format choice, but ok | 18:45 |
| markos_ | I would expect something like csv/json and then some processing on those to generate what you want | 18:46 |
| lkcl | just a table. | insn | stage1 | stage2 | stage3 |... | 18:46 |
| lkcl | csv would work too | 18:46 |
| markos_ | well, if markdown does the job, why not | 18:46 |
| markos_ | what would the cell in each stage be? | 18:47 |
| lkcl | what-the-model-stage-specifies | 18:47 |
| lkcl | in *this* model which is the *first* model | 18:47 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/cyclemodel/inorder.py;hb=HEAD | 18:47 |
| lkcl | stage1=fetch | 18:48 |
| lkcl | stage2=decode | 18:48 |
| lkcl | stage3=issue | 18:48 |
| lkcl | stage4-and-above is execute | 18:48 |
| markos_ | in another simulator, I've seen a vertical table, with cycles as the left column, and each unit (ALU/FPU/Vector/Load/Store) in its own column, | 18:48 |
| markos_ | that shows the utilization of each unit, per cycle | 18:49 |
| lkcl | that doesn't allow for showing pipeline progression | 18:49 |
| markos_ | ofc that's hardware specific, some cpus might have more than one units of each | 18:49 |
| markos_ | no indeed | 18:49 |
| lkcl | which will have to be the next model and/or have multiple entries per cell | 18:50 |
| markos_ | well, at least ideas are not something we're going to run out of :) | 18:51 |
| programmerjake | there is: https://ftp.libre-soc.org/power-cpu-sim/ | 18:52 |
| programmerjake | you'll need to enable javascript and webassembly | 18:53 |
| vaino[m] | octavius, nice to meet you :) I'd gladly watch that video once it's out. | 18:54 |
| programmerjake | (generally enabled by default in modern browsers) | 18:54 |
| markos_ | ah nice! yes, something similar, though imho, it would easier to show cycles vertically | 18:55 |
| markos_ | but yes, it's nice, didn't know we had something like that already | 18:55 |
| programmerjake | just edit the command line to remove --transpose then...top text box | 18:56 |
| markos_ | curious, what's using webassembly? | 18:56 |
| markos_ | cool! | 18:56 |
| programmerjake | oh, it's written in rust and c++ | 18:57 |
| programmerjake | it simulates a register-renaming OoO superscalar cpu, but it has no decoder and only supports like 5 instructions | 18:58 |
| programmerjake | lkcl told me to quit working on it cuz it's written in rust/c++ | 18:59 |
| programmerjake | iirc | 18:59 |
| markos_ | ah so it's a separate project? it doesn't use pypowersim output? | 19:00 |
| *** psydroid <psydroid!~psydroid@user/psydroid> has quit IRC | 19:00 | |
| programmerjake | it has a full command line interface, so, e.g. you can give --help to see what commands it supports, iirc you can also compile the code to an x86 or other binary if you like | 19:01 |
| lkcl | yes it is - an unfunded one that is so large that it should have had an NLnet Grant application created and approved to fund it *before* even starting the work | 19:01 |
| markos_ | yeah, I think I remember, I think it would be worth to have something that parses the output of the existing pypowersim and visualize it, but this is an entirely new project | 19:01 |
| markos_ | and we would have to maintain both -plus cavatools- with any change in the ISA | 19:01 |
| programmerjake | yes, it has a hardcoded instruction trace input https://salsa.debian.org/Kazan-team/power-cpu-sim/-/blob/2839027af17e1e7b5ade7caa24c5e2bf82f35a04/c-src/main.cpp#L34 | 19:02 |
| lkcl | the idea is to add about 5 lines of code to pypowersim to get it to output the current instruction into a log file. | 19:02 |
| lkcl | (plus the PC, plus the address of load/store if there is one) | 19:03 |
| markos_ | the more data the better, as long as we can process and visualize it, log files as they are right now are pretty much unreadable unless you're looking for a very specific piece of information | 19:03 |
| lkcl | actual contents of memory and actual contents of regfiles are paradoxically utterly irrelevant for the model | 19:03 |
| lkcl | which is why a total rewrite (from scratch) of yet another simulator should never have had time spent on it | 19:03 |
| lkcl | to get an actual useful model you *need* the sequence of instructions for analysis | 19:04 |
| markos_ | they are irrelevant for the model, but are very relevant if you're using the simulator to debug actual code | 19:04 |
| markos_ | like I was doing for example | 19:04 |
| lkcl | and we already have such a tool: called "pypowersim" | 19:04 |
| lkcl | yes. this is very specific, it is needed for making commercial justification presentations | 19:04 |
| lkcl | a secondary (just as important) goal is to spot blackspots (stalls) | 19:05 |
| programmerjake | the rust/c++ simulator i wrote behaves very much like the in-order python pipeline simulator you're currently writing, it simulates register dependencies, not actual data computation | 19:05 |
| programmerjake | except that the in-order cpu simulator is much less like modern high-end cpus and what we want libre-soc's cpu to finally end up as | 19:07 |
| programmerjake | so the program i wrote is right now more representative of our final cpu | 19:08 |
| programmerjake | since in-order cpus can't do OoO superscalar | 19:08 |
| programmerjake | and our final cpu will be OoO superscalar (but using a different algorithm) | 19:10 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.140> has joined #libre-soc | 19:26 | |
| lkcl | okaay two new unit tests for data-dependent fail-first, one vli one without | 19:33 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.140> has quit IRC | 19:33 | |
| lkcl | store is trickier: for VLI=0 it requires the workaround to explicitly test the data to be stored *before* even *attempting* the store | 19:34 |
| lkcl | the alternative - to shadow-hold the memory-write - is kinda odd | 19:34 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.9> has joined #libre-soc | 19:34 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:39 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 19:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.164.9> has quit IRC | 19:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:44 | |
| ghostmansd[m] | lkcl, thank you for your kind words on insndb! | 19:45 |
| ghostmansd[m] | I'm refactoring some of its chunks to make it be better usable for inorder.py and pysvp64asm | 19:46 |
| ghostmansd[m] | But not much, mostly decoupling common bits | 19:46 |
| lkcl | funnily enough the only thing needed is to identify the registers | 19:47 |
| lkcl | and that's done through ISACaller... okok now called ISAPages (see decoder/isa/all.py after re-running pywriter) | 19:47 |
| lkcl | fixedarith_instrs = {} | 19:48 |
| lkcl | fixedarith_instrs['addi'] = instruction_info(func=op_addi, | 19:48 |
| lkcl | read_regs=OrderedSet(['RA']), | 19:48 |
| lkcl | uninit_regs=OrderedSet(), write_regs=OrderedSet(['RT']), | 19:48 |
| lkcl | that's good enough for now | 19:48 |
| lkcl | no need to use insndb at all for this | 19:49 |
| lkcl | when SVP64 is added that's a different matter | 19:49 |
| lkcl | buuut.... even there, it *may* be possible to get away with not needing it by outputting to the log file the reg nums *after* parsing | 19:49 |
| ghostmansd[m] | Don't we have to check GPR/FPR/CR? | 19:50 |
| ghostmansd[m] | And, also, immediates | 19:50 |
| lkcl | that can be done by name (as it is somewhere inside... errr... i forget where) | 19:50 |
| lkcl | "if name in ['RA', 'RB'...] -> GPR | 19:50 |
| lkcl | actually | 19:50 |
| lkcl | "if name.startswith("R") -> GPR | 19:51 |
| lkcl | it's *that* level of basic | 19:51 |
| lkcl | nnope | 19:51 |
| lkcl | immediates can be utterly ignored | 19:51 |
| lkcl | they are irrelevant as far as register hazard checking is concerned | 19:51 |
| lkcl | which is the first top-priority task for the model | 19:52 |
| lkcl | you can see, i created a set() inside inordermodel.py | 19:52 |
| lkcl | and already put in the code to check "are we waiting for another ALU to write to this reg? if so stall" | 19:53 |
| ghostmansd[m] | I'll check in about an hour, right now putting a daughter to bed :-) | 19:53 |
| lkcl | ok :) | 19:53 |
| ghostmansd[m] | If we have stuff like "add 1,2,3" as input, how do we get if name starts with R? | 19:55 |
| ghostmansd[m] | If and only if we have say "add r1,r2,r3", we can know this | 19:56 |
| ghostmansd[m] | But our disassembly does not follow this convention (not unless we ask it politely) | 19:57 |
| programmerjake | i think lkcl means the field name not the asm code | 19:57 |
| ghostmansd[m] | I understand | 19:58 |
| ghostmansd[m] | But, again: without relying on CSVs, we do not know field name | 19:59 |
| programmerjake | e.g. where isacaller passes input registers into the compiled pseudocode function | 19:59 |
| lkcl | ghostmansd[m], same as it is done in ISACaller. strip the name, use that as the lookup | 19:59 |
| ghostmansd[m] | Hmmm | 19:59 |
| lkcl | search "self.instrs" in ISACaller | 19:59 |
| ghostmansd[m] | Ok I'll check it, thanks! | 19:59 |
| lkcl | the awkward bit is the duplication of all the nonsense of "." in the name etc. etc. | 20:00 |
| lkcl | you will see a hell of a lot of bullshit in ISACaller, which should be put into a common function | 20:01 |
| ghostmansd[m] | Anyway, I'll complete some stuff in insndb, since I already started it and it's useful per se. Basically providing assemble/disassemble methods to be reused, assemble is the same it's done in pysvp64asm and disassemble is... You get the idea. | 20:01 |
| programmerjake | like here: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=0807e47a42e17359dbabf7d871acdfde9fef516f;hb=HEAD#l2059 | 20:01 |
| lkcl | yehyeh. hurrah | 20:01 |
| ghostmansd[m] | I think we'll need these later | 20:01 |
| programmerjake | lkcl: imho we still need the Fraction-based class since it doesn't behave like SelectableInt | 20:03 |
| ghostmansd[m] | Still not entirely obvious how create_args works | 20:03 |
| ghostmansd[m] | What are the inputs and the outputs | 20:04 |
| ghostmansd[m] | I see it outputs list of names | 20:04 |
| ghostmansd[m] | Are these RA, FRT, et al.? | 20:04 |
| programmerjake | ghostmansd: yes, they match the function arguments and return values in the compiled pseudocode | 20:05 |
| programmerjake | those names come from info.read_regs and info.uninit_regs | 20:06 |
| ghostmansd[m] | OK, assuming I have an input "add 1,2,3". How do I get an idea where is RT and RA and whatever else unless I have parsed CSV or unless there was another module which parsed CSV told me this info? | 20:08 |
| ghostmansd[m] | I should either have an additional input which tells me operand names, or I should parse the instruction on my own. | 20:09 |
| ghostmansd[m] | Am I missing something, guys? | 20:09 |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:09 | |
| programmerjake | lkcl: the Fraction-based class has unlimited range in both directions -- toward more significant bits and toward less significant bits, SelectableInt stops at bit 0. also mul/div behave differently. those are all needed for bfp_* functions | 20:10 |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:11 | |
| *** knar <knar!~knar@2401:4900:1f26:2e8:dee5:c516:e182:de03> has quit IRC | 20:11 | |
| programmerjake | ghostmansd, i think the idea is to add code to isacaller that produces an instruction trace, you can just plain include input_names in the trace to use later | 20:12 |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:12 | |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:13 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:13 | |
| programmerjake | just include whatever info you need, maybe `info` itself | 20:13 |
| *** gmsd <gmsd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:14 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:14 | |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:15 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 20:15 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 20:15 | |
| ghostmansd | F*ck hexchat is probably the dumbest IRC client I've ever seen | 20:16 |
| ghostmansd | Always disconnecting, always keeping the nickname occupied | 20:16 |
| ghostmansd | programmerjake, everything above still counts as an additional input :-) | 20:16 |
| ghostmansd | OK, so, the trace MUST be generated by something like ISACaller, right? | 20:17 |
| ghostmansd | and this trace can be in any form I find appropriate | 20:17 |
| programmerjake | so, you don't actually need the list of which of RA/RB/etc. it reads but instead which physical registers the instruction reads/writes since those are what are actually used for dependency tracking | 20:17 |
| programmerjake | probably a list, yeah | 20:18 |
| programmerjake | though something that can go in a file is nice too | 20:18 |
| ghostmansd | Yeah I've been thinking about a file | 20:19 |
| ghostmansd | And basically it boils down to "now something reads GP register numbered 0" | 20:19 |
| programmerjake | maybe add tracing to ISACaller.get_input? that's where reg reads actually occur iirc so it has the right reg nums | 20:19 |
| ghostmansd | and "now something writes GPR numbered 0 and reads from GPRs numbered 6 and 7" | 20:19 |
| ghostmansd | Like this? | 20:20 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=0807e47a42e17359dbabf7d871acdfde9fef516f;hb=HEAD#l2333 | 20:20 |
| programmerjake | yes | 20:20 |
| programmerjake | though you'll probably also want the asm string so users can see what's currently running | 20:21 |
| ghostmansd | Hm... Hm hm hm... | 20:21 |
| ghostmansd | OK I think I understand | 20:21 |
| programmerjake | actually, it might be better to trace directly in the GPR class, since that's not the only place gprs are read/written | 20:22 |
| ghostmansd | A dumb question: how do I run ISACaller? | 20:22 |
| programmerjake | same thing with FPR and others | 20:23 |
| ghostmansd | Say I have some instruction, e.g. "add 1,2,3" | 20:23 |
| ghostmansd | And I want to add some code to ISACaller which produces the trace. | 20:23 |
| ghostmansd | Then I want to feed the insn to ISACaller. | 20:23 |
| ghostmansd | Sorry, never ever run it other than indirectly. | 20:24 |
| programmerjake | simplest way: invoke just like all the unit tests do -- see https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_bigint.py;h=7df7a457558a5b837be83dc2d0de436ab661936e;hb=HEAD | 20:24 |
| programmerjake | since that requires zero extra thought :) | 20:24 |
| programmerjake | though you could look through the unit tests, some invoke isacaller more directly | 20:25 |
| ghostmansd | > since that requires zero extra thought :) | 20:25 |
| ghostmansd | I admire your style sir! | 20:26 |
| ghostmansd | :-D | 20:26 |
| ghostmansd | Perfectly fits my needs | 20:26 |
| ghostmansd | Ah yeah I recall some tests instantiated ISACaller | 20:26 |
| ghostmansd | Probably even one written by me... | 20:26 |
| ghostmansd | Too long ago to remember | 20:26 |
| programmerjake | one that calls it more directly: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_svp64_dct.py;h=0e3796b47a47a6aa80a8cb718a5684a84992a533;hb=HEAD | 20:27 |
| programmerjake | run_tst, not ISACallerHelper shenanigans | 20:28 |
| programmerjake | run_tst defined here (after looking through multiple layers of importing imports...sigh) https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_runner.py;h=b84354cc099cfba908629b9c17b903990fc79388;hb=HEAD | 20:30 |
| ghostmansd | Thanks programmerjake! | 20:33 |
| ghostmansd | I think that was a great start | 20:33 |
| programmerjake | yw! hopefully that's what luke intended... | 20:34 |
| lkcl | programmerjake, ah a class that is *external* and *non-intrusive* to SelectableInt - i.e. requires absolute flat-out zero modification of SelectableInt - as long as it is not thousands of lines of code - i am fine with | 20:36 |
| lkcl | it's when you write code that is five times longer than anything anyone else would ever write, placing anyone else in the team under a huge maintenance burden, that's when it's a problem | 20:37 |
| lkcl | ghostmansd, yes you did the.... ah.... bcd instructions i think? or it was around that time | 20:37 |
| programmerjake | yeah, all it does is hand out SelectableInt when sliced, otherwise doesn't interact with SelectableInt iirc | 20:37 |
| lkcl | then i don't have a problem with it, especially if it just overrides one single function, that's perfect | 20:38 |
| programmerjake | :) | 20:38 |
| lkcl | ghostmansd, here's one | 20:39 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/test_caller_setvl.py;h=163a5afe6d68293da4d2fe29b8abdca144f83cfe;hb=HEAD#l20 | 20:39 |
| programmerjake | can you review the new branch? https://git.libre-soc.org/?p=openpower-isa.git;a=shortlog;h=refs/heads/support-fields | 20:39 |
| lkcl | - def __init__(self, XLEN): | 20:39 |
| lkcl | + def __init__(self, XLEN, FPSCR): | 20:39 |
| lkcl | great | 20:39 |
| programmerjake | https://bugs.libre-soc.org/show_bug.cgi?id=1072#c17 | 20:40 |
| programmerjake | thx! | 20:40 |
| lkcl | ah strictly speaking these need to go | 20:40 |
| lkcl | - def FRSP(FRB, FPSCR): | 20:40 |
| lkcl | + def FRSP(FRB): | 20:40 |
| programmerjake | what do you mean? | 20:41 |
| lkcl | the concept of return and of function-definitions is not part of the Power ISA pseudocode specification | 20:41 |
| lkcl | the only reason it works is because i had based the parser on GardenSnake.py by David Beazley | 20:42 |
| lkcl | and had not removed function-header and return-result from the BNF! | 20:42 |
| programmerjake | it totally is...see bfp_ABSOLUTE() for a short example | 20:43 |
| lkcl | it's a pain-in-the-ass to remove but also i am wavering as to whether it should stay as it makes the pseudocode much more readable | 20:43 |
| lkcl | you did a rewrite about a year ago of the FRSP pseudocode | 20:43 |
| lkcl | putting in function headers and splitting it from its string-based if/elif form into functions | 20:44 |
| programmerjake | well, do you want to add goto support? sounds like fun figuring out to implement that in python... | 20:44 |
| lkcl | which as i mentioned yesterday has the implication of the INTENTION to propose the exact same modification *to the Power ISA* | 20:44 |
| lkcl | jooooy | 20:44 |
| lkcl | that's a good enough justification that i can present to the OPF ISA WG | 20:45 |
| lkcl | (that and readability) | 20:45 |
| programmerjake | those were gotos, not string-based if/elif iirc | 20:45 |
| lkcl | blech | 20:46 |
| lkcl | i'm not keen on passing FPSCR as a parameter | 20:46 |
| programmerjake | hence why it's not anymore | 20:46 |
| lkcl | ok :) | 20:46 |
| programmerjake | you read the diff backwards | 20:47 |
| lkcl | aw doh | 20:47 |
| programmerjake | so, good to merge to master? | 20:47 |
| lkcl | gis a minute - wading through a 7/10 headache | 20:48 |
| programmerjake | k, hope you feel better... | 20:48 |
| * lkcl just doing a global diff | 20:50 | |
| programmerjake | that'd be a mess...i split it apart into understandable diffs | 20:52 |
| programmerjake | commits | 20:52 |
| lkcl | yeah all good | 20:52 |
| lkcl | i get a quick overview of everything. it works | 20:52 |
| lkcl | yep all good, go for it | 20:52 |
| programmerjake | particularly the moving functions around in the parser and then modifying them | 20:52 |
| programmerjake | k :) | 20:53 |
| lkcl | i'm not concerned. if it works it works | 20:53 |
| programmerjake | running tests... | 20:56 |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:00 | |
| programmerjake | more broken tests, luke, but matches master so i'm pushing | 21:02 |
| programmerjake | FAILED src/openpower/decoder/isa/test_caller_svp64_dd_ffirst.py::DecoderTestCase::test_sv_addi_ffirst_rc1 | 21:03 |
| programmerjake | FAILED src/openpower/decoder/isa/test_caller_svp64_dd_ffirst.py::DecoderTestCase::test_sv_addi_ffirst | 21:03 |
| programmerjake | FAILED src/openpower/decoder/isa/test_caller_svp64_dd_ffirst.py::DecoderTestCase::test_sv_addi_ffirst_le | 21:03 |
| *** ghostmansd[pc] <ghostmansd[pc]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 21:03 | |
| *** ghostmansd <ghostmansd!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:04 | |
| *** ghostmansd[hexch <ghostmansd[hexch!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 21:07 | |
| lkcl | ah that's new, i know why, too | 21:19 |
| lkcl | i stopped regfile writing from occurring on dd-ffirst for LD | 21:20 |
| lkcl | ghostmansd[m], octavius, i'm an idiot: no need to read insndb at all | 21:51 |
| lkcl | have ISACaller write out the instruction *and* the registers used | 21:51 |
| lkcl | insn 1,2,3 # GPR:RT=1 GPR:RA=2 GPR:RB=3 | 21:51 |
| lkcl | and this has the advantage that when writing to CR0/CR1 this can be explicit and easy too | 21:52 |
| *** octavius <octavius!~octavius@92.40.169.164.threembb.co.uk> has quit IRC | 21:54 | |
| ghostmansd[m] | Yeah that's what programmerjake basically suggested above | 21:55 |
| ghostmansd[m] | I'm not sure if we even need to output the whole insn. Even name seems to be needed for debug only. | 21:55 |
| lkcl | pretty much | 22:54 |
| lkcl | ghostmansd[m], https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=1a96d4f3a63c17054c0f176909e3284c3b5c7831 | 23:10 |
| lkcl | i'll add Rc=1 shortly | 23:12 |
| programmerjake | lkcl: please pass a path to use in from TestRunnerBase, using nmutil.get_test_path, the temp -ath you chose conflicts between all parallel invocations of ISACaller (or actually all invocations between reboots since you open it in append mode) | 23:26 |
| programmerjake | that also allows a different path per case_* fn | 23:28 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!