| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 00:14 | |
| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has joined #libre-soc | 01:19 | |
| programmerjake | lkcl: if you're talking about the fcvtfg unit tests, those are marked @skip_case since I know they're currently broken and i'm fixing them soon: https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/test/fmv_fcvt/fmv_fcvt.py;h=9e8914cce83cec67142a1cbba500f9162afaee9b;hb=371d91b299c0e4bd7b23e660b9936ed40debb824#l439 | 09:39 |
|---|---|---|
| programmerjake | so of course they pass | 09:39 |
| lkcl | programmerjake, good enough :) it's the right strategy (i should have been using it with the dd-ff-ldst tests, sigh) | 09:41 |
| programmerjake | the fcvttgo. tests are not skipped however | 09:41 |
| programmerjake | so it's good they pass! | 09:41 |
| lkcl | awesome :) | 09:41 |
| programmerjake | though i'm not testing how they behave when fp exception traps are enabled since those aren't implemented | 09:42 |
| programmerjake | yet | 09:43 |
| programmerjake | fun...testing all the corner cases nearly no one ever uses... | 09:44 |
| programmerjake | since enabling underflow traps changes how it decides when underflow occurred | 09:45 |
| programmerjake | that's all specified by ieee 754 | 09:46 |
| lkcl | frickin ellfire | 09:48 |
| lkcl | "enabling" traps is easy | 09:48 |
| lkcl | whatever conditions are required - and this has to go in around where handle_carry() and handle_overflow() is called - you just call the self.TRAP() function with the appropriate memory location | 09:49 |
| lkcl | i believe it's 0x800 | 09:49 |
| lkcl | oh - no - call the call_trap() function | 09:50 |
| programmerjake | can you add that? should be pretty easy, just trap if the enable bits in msr are set and FPSCR.VEX is set iirc, it's described in the spec | 09:51 |
| lkcl | so if writing to overflow is supposed to come first, the call to a function called "self.handle_fp_exception()" should come *after* that | 09:51 |
| programmerjake | FEX | 09:51 |
| lkcl | ok i can take a look | 09:52 |
| lkcl | the bit that will be slightly irkesome (but can be added/tested/confirmed later) will be data-dependent fail-first | 09:53 |
| programmerjake | see v3.1b book iii 7.5.9 | 09:56 |
| lkcl | almost useless. | 09:57 |
| programmerjake | ?? you mean the referenced section? | 09:58 |
| programmerjake | what is almost useless? | 09:59 |
| lkcl | fer goodness sake. it's 0x700 | 09:59 |
| lkcl | i have no idea what i'm doing here. | 10:00 |
| lkcl | ok - bit 43. | 10:01 |
| programmerjake | basically just evaluate (MSR.FE0 | MSR.FE1) & FPSCR.FEX after each insn and if it's 1 then the instruction causes a trap | 10:01 |
| lkcl | uh-huhn.... and what goes into MSR? | 10:02 |
| lkcl | and is it ok to write to any registers? | 10:02 |
| lkcl | if so, which ones? | 10:02 |
| programmerjake | msr -- isn't that just a kernel-accessible register? | 10:02 |
| lkcl | "just" | 10:02 |
| lkcl | it's the most absolutely critical register of the entire Power ISA | 10:03 |
| programmerjake | the fp pseudo-code will suppress writes if needed | 10:03 |
| lkcl | controlling in a god-like fashion what happens underneath | 10:03 |
| lkcl | it's a peer of PC | 10:03 |
| programmerjake | but what i mean is msr should be easy to read in the simulator... | 10:03 |
| lkcl | so if you set the wrong value it's as if you for example set PC equal to 0xfffffffffff | 10:03 |
| lkcl | yes - self.msr | 10:04 |
| programmerjake | you don't need to write msr (unless trapping does that) | 10:04 |
| lkcl | correct - trapping does precisely and exactly that | 10:04 |
| lkcl | if you fail to write the correct values into MSR which is the *very definition* of what a trap actually is, | 10:04 |
| lkcl | you are utterly screwed. | 10:05 |
| lkcl | software will jump to (say) 0x700 then start executing code that checks the contents of MSR bits and route through to entirely the wrong code | 10:05 |
| lkcl | i encountered this multiple times when running both microwatt unit tests and the linux kernel | 10:05 |
| lkcl | (last time was unaligned memory exceptions) | 10:06 |
| lkcl | (before that it was the setting of PR bit and associated bits) | 10:06 |
| programmerjake | well, for fp unit tests at least, they don't care what msr is since they end right when the trapis taken or not | 10:06 |
| lkcl | you *have* to care | 10:07 |
| lkcl | checking in the unit test will be absolutely essential. | 10:07 |
| lkcl | the "ExpectedState" absolutely must have the expected value of MSR. | 10:07 |
| lkcl | (there's a way to specify in the unit test "if PC=={specific_value} then stop executing" | 10:07 |
| lkcl | and that can be set (in this case) to 0x700 | 10:08 |
| programmerjake | so if the trap gives the wrong msr value, that's still fine for the fp unit tests at least. all the other unit tests that specifically test did it trap correctly care, the fp unit tests just care if it trapped or not | 10:08 |
| lkcl | the unit tests are *absolutely 100%* required to "care" | 10:08 |
| lkcl | no, it is not ok. really. | 10:08 |
| programmerjake | k | 10:08 |
| lkcl | look at the text on "SRR0" | 10:09 |
| lkcl | and the page after on "SRR1". | 10:09 |
| lkcl | 43 Set to 1 for a Floating-Point Enabled | 10:09 |
| lkcl | Exception type Program interrupt; other- | 10:09 |
| lkcl | wise set to 0. | 10:09 |
| lkcl | so when specifying what ExpectedState to check for, the unit test will be *required* to set bit 43 to 1 | 10:10 |
| lkcl | that cannot be ignored! | 10:10 |
| lkcl | the only reason we get away with "ignoring" it at the moment is because we run with all ExpectedState set to a fixed pre-defined value | 10:11 |
| programmerjake | k | 10:11 |
| lkcl | that juuuust happens - by a not-so-coincidence - to be in virtually 100% of all unit tests "the right value" | 10:11 |
| programmerjake | maybe expectedstate needs a fp_trap method that updates msr to have all the right values so all the tests don't have to replicate that | 10:12 |
| lkcl | i'd prefer if they were stand-alone explicitly spelled out in each unit test (deliberately) | 10:13 |
| lkcl | but if a unit test *class* turned out to have such common values then calling a function that receives an ExpectedState as a parameter i don't have a problem with | 10:14 |
| programmerjake | ok, though sounds like a pain to get right in every test, since there're no tests to copy from yet | 10:15 |
| lkcl | MSR values are different based on different traps. with unit tests being localised within classes, the amortisation of all of those into an fp_trap function would result in making it difficult to review | 10:15 |
| lkcl | exactly!! :) | 10:15 |
| lkcl | hence why i was grumbling, above! | 10:15 |
| lkcl | this is going to need microwatt source code examination. | 10:16 |
| lkcl | and another PIb bit | 10:16 |
| lkcl | ahh there already exists one! | 10:16 |
| lkcl | PIb.FP | 10:16 |
| lkcl | who the heck added that? probably me :) | 10:17 |
| lkcl | ahh it's not MSR that changes, it's the contents of SRR1. | 10:18 |
| lkcl | self.spr['SRR1'][trap_bit] = 1 # change *copy* of MSR in SRR1 | 10:18 |
| lkcl | so by calling "self.call_trap(0x700, PIb.FP)" that _should_ be sufficient | 10:19 |
| programmerjake | feel free to just test `nop` with the fpscr bits set to cause a trap on entry, seems like the easiest way to unit test the fp trap mechanism | 10:19 |
| lkcl | apologies it's SRR1 that should be passed in to an ExpectedState | 10:19 |
| lkcl | but msr should also be - just not to the value i was anticipating | 10:19 |
| programmerjake | since none of the write-to-fpscr instructions have pseudo-code so are likely to be implemented | 10:20 |
| lkcl | SRR147 can be set to 1 only if the | 10:20 |
| lkcl | exception is a Floating-Point Enabled | 10:20 |
| lkcl | Exception and either MSRFE0 FE1 = | 10:20 |
| lkcl | 0b01 or 0b10 or MSRFE0 FE1 has just | 10:20 |
| lkcl | been changed from 0b00 to a nonzero | 10:20 |
| lkcl | value. (SRR147 is always set to 1 in the | 10:20 |
| lkcl | last case.) | 10:20 |
| lkcl | fer frickin frick's sake | 10:20 |
| programmerjake | note FE0 FE1 == 0b01 or 0b10 means fp traps may be imprecise, seems easiest to always have precise traps in the simulator | 10:22 |
| lkcl | right up to the point where we find that third party programs assume otherwise, yes | 10:22 |
| lkcl | ok need to get up | 10:22 |
| programmerjake | if they assume otherwise they're broken since cpus may cause those fp traps to occur at any point before the next fp context synchronizing instruction, including immediately when FPSCR.FEX becomes 1 | 10:24 |
| programmerjake | (icr if fp context synchronizing insn is the right phrase, but you get the idea) | 10:25 |
| programmerjake | thanks for doing this! | 10:26 |
| programmerjake | note fp underflow can't actually occur for fcvt*/fmv*, so the main difference I'd need to test is that the destination register overwrite didn't occur, tho now that i think about it, preventing writing to FRT/RT is only necessary when FRT/RT is the same register as the source, which is impossible for fmv/fcvt since they write to a different reg file than they read from | 10:29 |
| programmerjake | so maybe i can remove the preventing reg write from the pseudocode, which should simplify it a bunch | 10:30 |
| programmerjake | preventing reg write is still necessary for other fp ops tho, e.g. fsinpi f3, f3 | 10:31 |
| lkcl | actual write to the regfile does not take place unless you explicitly call GPR(nn) <- xx | 10:41 |
| lkcl | the contents of what is *requested* to be written to goes into some local variables within the function that are *returned* by the pseudocode function | 10:42 |
| lkcl | and they're *not* stored until do_outregs_nia() is called | 10:43 |
| lkcl | which goes over them carefully | 10:43 |
| lkcl | what you do have to watch out for is writing to FPSCR, CR0 etc. | 10:43 |
| lkcl | CR1 | 10:43 |
| lkcl | if those are *not supposed to be written to* then it will become necessary to add them to the list of "objects-written-to-that-must-become-return-results" | 10:44 |
| programmerjake | yeah, i expect the pseudocode to fail with NameError at the autogenerated return, needs fixing | 10:44 |
| lkcl | and that's handled by adding them to write_regs | 10:45 |
| programmerjake | FPSCR and cr1 are specified to be written to | 10:45 |
| lkcl | no they're not | 10:45 |
| programmerjake | just not frt, since that could overlap with the input | 10:45 |
| lkcl | caller.py | 10:45 |
| lkcl | if name in ['overflow', 'CR0']: | 10:45 |
| lkcl | self.write_regs.add(name) | 10:45 |
| lkcl | likewise here | 10:46 |
| lkcl | if name and name in self.gprs: | 10:46 |
| lkcl | self.write_regs.add(name) # add to list of regs to write | 10:46 |
| programmerjake | i'm talking about the PowerISA spec, not whatever possibly incorrect thing our simulator currently does | 10:46 |
| lkcl | "specified to be written to" ok --> "must be added to write_regs on-demand" | 10:47 |
| lkcl | so are there any circumstances where the pseudocode writes *directly* into CR1? | 10:47 |
| programmerjake | the fp ops *conditionally* write their dest regs, afaict the simulator doesn't support that yet | 10:47 |
| programmerjake | maybe fcmp[u/o]? | 10:48 |
| lkcl | that can be "handled" by making sure that the copy of the reg is identical going in | 10:48 |
| lkcl | ok then CR1 definitely needs adding as a peer of overflow and CR0 | 10:48 |
| programmerjake | but that doesn't need conditional writing since writing cr1 can't overwrite any inputs | 10:48 |
| programmerjake | i already did | 10:49 |
| lkcl | no, you didn't add it in parser.py | 10:49 |
| lkcl | <lkcl> if name in ['overflow', 'CR0']: | 10:49 |
| lkcl | <lkcl> self.write_regs.add(name) | 10:49 |
| lkcl | therefore it will be a local-only variable | 10:49 |
| lkcl | the contents will *never* be returned | 10:50 |
| programmerjake | ah, ok. i added it in caller since i was adding Rc=1 CR1 support anyway | 10:51 |
| lkcl | look at decoder/isa/comparedfixed.py | 10:51 |
| lkcl | wait... no.. hang on... | 10:51 |
| lkcl | err... | 10:51 |
| programmerjake | i didn't check fcmp[u/o] | 10:51 |
| lkcl | ah - av.py and/or prefix_codes.py | 10:51 |
| lkcl | decoder/isa/av.py: return (RT, CR0,) | 10:52 |
| lkcl | decoder/isa/av.py: uninit_regs=OrderedSet(), write_regs=OrderedSet(['CR0', 'RT']), | 10:52 |
| programmerjake | prefix_codes should never change CR1 | 10:52 |
| lkcl | i am explaining in the context of CR0 | 10:52 |
| lkcl | which is what we have "working" | 10:52 |
| lkcl | so parser.py has to encounter CR1 | 10:53 |
| lkcl | (being written to - not being read) | 10:53 |
| programmerjake | yeah, i'm already mostly aware how cr0 works in caller.py at least. | 10:53 |
| lkcl | it has to go, "oh, this is being written to, let me add it to the write-regs set" | 10:53 |
| lkcl | then that ends up with... | 10:53 |
| lkcl | so exactly the same thing is needed for CR1. | 10:53 |
| programmerjake | ok, we can do that when we need it, so not now | 10:54 |
| lkcl | and if FPSCR is needed to be treated the same way (a return result that must not go into the regfile and "damage" it if an exception occurred) | 10:54 |
| lkcl | then it goes into that list too | 10:54 |
| programmerjake | fpscr does not need to have writes skipped | 10:55 |
| lkcl | it just depends on whether the *pseudocode* should be writing FPSCR or whether it should be done as a post-analysis phase explicitly in python code. | 10:55 |
| lkcl | i really would prefer that not to be the case | 10:55 |
| programmerjake | besides fpscr skips all the read/write reg machinery since it's always accessed through self | 10:55 |
| lkcl | urrr.... | 10:55 |
| lkcl | that doesn't mean doing so is the right thing to do | 10:56 |
| lkcl | it just means that a completely new mechanism would be needed | 10:56 |
| lkcl | an entirely new paradigm for "coping" with register contents not being destroyed | 10:56 |
| lkcl | and that would be: take a copy of FPSCR before it is destroyed | 10:56 |
| lkcl | and have the TRAP restore it | 10:56 |
| programmerjake | but no restore is necessary | 10:57 |
| lkcl | but that's only if the specification requires that exceptions *not* allow FPSCR to be "damaged" | 10:57 |
| programmerjake | it isn't destroyed | 10:57 |
| lkcl | if however it *does* require being written to then that's fine | 10:57 |
| lkcl | "being written to such that when the trap occurs the trap can read that written FPSCR value" | 10:58 |
| programmerjake | exceptions happen after pseudocode changes fpscr to the state needed by the exception | 10:58 |
| lkcl | okaaay | 10:58 |
| lkcl | it's a communications mechanism | 10:58 |
| lkcl | ok great - then writing directly to it sounds perfectly fine | 10:59 |
| lkcl | which is good because it's a pain in the ass :) | 10:59 |
| lkcl | putting in explicit differences of behaviour | 10:59 |
| lkcl | but CR1 you will have to watch out for | 11:00 |
| programmerjake | only issues: all our proposed fp pseudocode doesn't handle exceptions (except fmv/fcvt and probably fminmax) | 11:00 |
| programmerjake | and -- svp64 ddff says failed insns don't write outputs, does that include fpscr? | 11:01 |
| programmerjake | sometimes don't write some outputs* | 11:01 |
| lkcl | that's where it becomes Hell | 11:02 |
| lkcl | it _shouldn't_ be allowed because when VLi=0 (exclusive) the instruction should never have been allowed to occur | 11:02 |
| programmerjake | i submitted https://bugs.libre-soc.org/show_bug.cgi?id=1087 | 11:03 |
| lkcl | as in: it should have a "Shadow-Hold" across it, the cancellation pulled, and the instruction treated as if it never even existed in the first place | 11:03 |
| programmerjake | we need to add all libre-soc fp ops to the see also, unless they never cause fp exceptions | 11:03 |
| lkcl | correct, dd-ff with vli=0 prohibits "failed" instructions from even existing | 11:04 |
| lkcl | they may be *attempted* but under no circumstances permitted to actually reach *any* regfiles | 11:04 |
| lkcl | (or memory contents) | 11:04 |
| lkcl | they're speculatively-executed (with Shadow-Hold) in other words | 11:05 |
| programmerjake | ok, sounds good then! any includes fpscr | 11:05 |
| lkcl | correct. FPSCR is "a register" | 11:05 |
| lkcl | therefore it is not permitted to have been written | 11:05 |
| lkcl | nor CRs | 11:05 |
| lkcl | nothing | 11:05 |
| lkcl | *anything* beyond the failed Shadow-Hold point is PROHIBITED | 11:05 |
| lkcl | it may be necessary to do that god-awful hack of taking a copy of FPSCR in order to cope | 11:06 |
| lkcl | the alternative is, you guessed it, adding FPSCR to write_regs | 11:06 |
| lkcl | which will need particular care because analysing the list of return results involves length-checking for routing through to different behaviours | 11:07 |
| lkcl | "if len(results) == 1" in places | 11:07 |
| programmerjake | it's 3am here, can you add the fp fft ops and other fp libre-soc ops to #1087 thx! | 11:07 |
| programmerjake | gtg to sleep | 11:08 |
| programmerjake | just see also or blocking as appropriate | 11:08 |
| lkcl | will take a look | 11:11 |
| programmerjake | thx, ttyl | 11:11 |
| lkcl | okaaay now need to run hundreds of unit tests - would be better to have a "long" and "short" test set | 12:18 |
| lkcl | with the short one being a few select examples, well-documented. | 12:19 |
| lkcl | nooow FPSCR can be handled correctly, prohibiting it from write-back on VLi=0 | 12:22 |
| lkcl | but otherwise permitted to write | 12:22 |
| lkcl | if not modified then the exact same value that was passed *in* will *happen* to be the exact same value *written* into the local-variable called "FPSCR" | 12:23 |
| lkcl | def op_fcvtfg(self, RB, FPSCR): | 12:23 |
| lkcl | FPSCR.FR = copy_assign_rhs(self.inc_flag) | 12:23 |
| lkcl | return (FRT, FPSCR,) | 12:23 |
| lkcl | ok they seem a little short (for the quantity) but i *think* the unit tests have run | 12:27 |
| * lkcl re-running everything after that change to parser.py and caller.py, important to ensure no "damage" occurs | 12:34 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 13:34 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 13:48 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 13:49 | |
| lkcl | ahh, @inject works on helper functions | 14:43 |
| lkcl | (because ISACaller derives from ISACallerHelper) | 14:43 |
| lkcl | aaaaa this is hairy | 15:00 |
| lkcl | i'm in the middle of fixing adding helper @inject at the same time as doing LD/ST reordering, aaaaaa | 15:01 |
| lkcl | ok good | 15:01 |
| lkcl | but... holy cow it needs a major hack in pyfnwriter | 15:01 |
| lkcl | holy cow big set of changes/simplification of LD/ST | 15:21 |
| lkcl | ghostmansd[m], that's the LD/ST modes updated to remove Saturation | 15:42 |
| lkcl | Imm is now remarkably similar (near-identical) to Idx | 15:42 |
| lkcl | and they are both a lot simpler | 15:43 |
| lkcl | much more like a sane ISA - one bit per "thing" | 15:43 |
| *** jn <jn!~quassel@2a0a-a540-9b38-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de> has joined #libre-soc | 16:04 | |
| *** jn <jn!~quassel@2a0a-a540-9b38-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de> has quit IRC | 16:04 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has joined #libre-soc | 16:04 | |
| *** jn_ <jn_!~quassel@2a0a-a540-9bb7-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de> has joined #libre-soc | 16:09 | |
| *** jn_ <jn_!~quassel@2a0a-a540-9bb7-0-20d-b9ff-fe49-15fc.ipv6dyn.netcologne.de> has quit IRC | 16:09 | |
| *** jn_ <jn_!~quassel@user/jn/x-3390946> has joined #libre-soc | 16:09 | |
| *** jn <jn!~quassel@user/jn/x-3390946> has quit IRC | 16:09 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.174> has quit IRC | 16:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.213> has joined #libre-soc | 16:31 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.213> has quit IRC | 16:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.181> has joined #libre-soc | 16:41 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.181> has quit IRC | 16:48 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 16:49 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 16:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.181> has joined #libre-soc | 16:56 | |
| lkcl | aaaa /pi is needed in LDST-Indexed | 17:19 |
| *** Guest34 <Guest34!~Guest34@188.71.221.194> has joined #libre-soc | 18:02 | |
| *** Guest34 <Guest34!~Guest34@188.71.221.194> has left #libre-soc | 18:02 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.181> has quit IRC | 18:14 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.181> has joined #libre-soc | 18:15 | |
| *** sadoon[m]1 <sadoon[m]1!~sadoonalb@2001:470:69fc:105::3:5f7c> has joined #libre-soc | 18:16 | |
| sadoon[m]1 | Hi guys | 18:17 |
| sadoon[m]1 | I truly hope you can read this because setting up a matrix server is such a pain in the ass. | 18:17 |
| sadoon[m]1 | If you do, please do let me know so I can stop banging my head xD | 18:21 |
| jn_ | sadoon[m]1: hi, message received on the IRC side | 18:27 |
| jn_ | so your matrix setup probably works :) | 18:27 |
| sadoon[m]1 | Awesome, thanks! | 18:27 |
| sadoon[m]1 | I've had an awful day dealing with this | 18:28 |
| sadoon[m]1 | Federation is still not properly working even though their tester reports all is fine but to hell with that | 18:29 |
| sadoon[m]1 | I moved to new domains and moved my server to POWER, currently in vms on my talos in preparation to move to the tyan later | 18:29 |
| sadoon[m]1 | My new email is sadoon at albader dot co | 18:30 |
| sadoon[m]1 | The old one still works for now though, might keep it for a year or two | 18:30 |
| programmerjake | lkcl: please confirm you've read and understand https://bugs.libre-soc.org/show_bug.cgi?id=1087#c10 -- it is critically important | 19:39 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.162.181> has quit IRC | 19:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 19:46 | |
| programmerjake | sadoon @sadoon:albader.chat: you'll need to change your bugzilla email address and mailing list subscriptions | 19:55 |
| programmerjake | https://bugs.libre-soc.org/userprefs.cgi?tab=account | 19:59 |
| programmerjake | if you want, you can do what lkcl does and have both email addresses subscribed to the mailing list but just disable mail delivery for one of them. this allows you to send mail from both addresses but only receive one copy of mail. | 20:01 |
| programmerjake | though if you will lose control of your old email address it's important to unsubscribe it to help prevent someone else registering it and pretending to be you | 20:03 |
| programmerjake | (though it doesn't help much since resubscribing is relatively easy) | 20:03 |
| programmerjake | changing bugzilla is much more important tho so someone can't just take your account over by getting your old email address | 20:05 |
| programmerjake | (i'd guess you already know all of that tho) | 20:07 |
| *** midnight <midnight!~midnight@user/midnight> has quit IRC | 20:10 | |
| lkcl | programmerjake, i'm really sorry, i can literally see no difference between the two pieces of pseudocode | 20:50 |
| *** octavius <octavius!~octavius@92.40.168.176.threembb.co.uk> has joined #libre-soc | 20:55 | |
| octavius | lkcl, programmerjake, I apologise for being ignorant of the pseudo-code notation, but are these | 20:56 |
| octavius | VSR[32xTX+T].dword[1] <- result | 20:56 |
| octavius | VSR[32xTX+T].dword[2] <- 0x0000_0000_0000_0000 | 20:56 |
| octavius | equivalent to: | 20:56 |
| octavius | RT <- result | 20:56 |
| octavius | ? | 20:56 |
| octavius | #1087 comment #11 | 20:57 |
| lkcl | effectively, they achieve the same thing. one targets VSR the other targets RT. | 20:57 |
| lkcl | that's "no effective difference" | 20:58 |
| octavius | Ok | 20:58 |
| lkcl | (it's not the focus - i pointed out that VSR/RT is not the issue - everything else is identical and that's what i am querying: there *is* no visible difference other than that one thing which is not relevant) | 21:00 |
| lkcl | octavius, extraoordinary paaatience needed when doing modifications to the devscripts. the nix guys took literally over 3 months, i spent weeks on coriolis2 - it's mad. | 21:04 |
| octavius | No problem. Now that you've explained the 'setup.py' dependencies a few times, I at least know what to do :) | 21:04 |
| lkcl | just take the buggers out, they cause so many problems. | 21:05 |
| lkcl | if someone doesn't install the dependencies before-hand then they should have installed them manually and/or used the devscripts | 21:06 |
| programmerjake | lkcl: explained what needs changing in https://bugs.libre-soc.org/show_bug.cgi?id=1087#c12 | 21:11 |
| lkcl | ok brilliant, let me take a look | 21:12 |
| lkcl | rright. ok. so it's the fact that the pseudocode is *not* like how it should be that is the problem? | 21:13 |
| lkcl | that still does not in turn say that the *simulator* requires anything different. | 21:13 |
| lkcl | the pattern following FPSCR.FEX (if/else) i am still not seeing as requiring any change to the simulator? | 21:14 |
| programmerjake | i didn't say the simulator must change, i said our pseudocode must change. the simulator may need changes (tbd) | 21:17 |
| lkcl | arrrgh ok | 21:17 |
| lkcl | i thought you were referring to the existing pseudocode and therefore concluded that you must have meant, "the simulator must compensate" | 21:18 |
| lkcl | how irkesome a misunderstanding. | 21:18 |
| programmerjake | well, if the simulator incorrectly interprets existing pseudocode (e.g. appendix a) then it needs change too | 21:19 |
| *** sauce <sauce!~sauce@hollandaise.sauce.icu> has quit IRC | 21:46 | |
| *** octavius <octavius!~octavius@92.40.168.176.threembb.co.uk> has quit IRC | 21:56 | |
| *** sauce <sauce!~sauce@free.and.open.sauce.icu> has joined #libre-soc | 22:35 | |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!