| lkcl | programmerjake, good insight on LD/St... urrr so much work implied though | 00:01 |
|---|---|---|
| lkcl | knock-on-effect to binutils aside from anything | 00:01 |
| programmerjake | :) | 00:08 |
| programmerjake | sorry ghostmansd... | 00:08 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 00:20 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 00:21 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 01:09 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 01:09 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 02:51 | |
| programmerjake | I noticed that many places where the PowerISA spec has FPSCR.RN or FPSCR<sub>RN</sub> or XER<sub>SO</sub> we translate it to pseudocode as XER[SO], imho we should instead translate it to XER.SO or FPSCR.RN since that works waay better since it doesn't conflict with just using SO by itself where we want the field value, not the bit index, or using a variable to index: FPSCR[BF+8*(1-w)] from mtfsfi | 04:05 |
| programmerjake | I'm going to change the pseudocode and parser to do that in a branch | 04:06 |
| programmerjake | basically...add support for var.field | 04:07 |
| ghostmansd[m] | lkcl, programmerjake, which works in binutils do you mean? | 04:55 |
| ghostmansd[m] | I probably missed something | 04:55 |
| programmerjake | oh, we're redoing some load/store bits in SVP64: https://bugs.libre-soc.org/show_bug.cgi?id=1080 | 04:56 |
| ghostmansd[m] | Whoa | 05:15 |
| ghostmansd[m] | > aieee this is going to be fun | 05:16 |
| ghostmansd[m] | The best summary of the dicussion :-) | 05:17 |
| programmerjake | yeah...fun... | 05:17 |
| programmerjake | at least you kinda get your wish of having more EXTRA3 operands... | 05:17 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has quit IRC | 05:55 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has joined #libre-soc | 06:30 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 06:37 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 06:38 | |
| ghostmansd[m] | But not for every operand I guess :-) | 07:09 |
| ghostmansd[m] | Congratulate on Victory Day! | 07:10 |
| programmerjake | oh, yeah. yay! peace is nice! | 07:11 |
| programmerjake | I'm not very good at keeping track of holidays... | 07:11 |
| ghostmansd[m] | This is one of the holidays I always track :-) | 07:17 |
| programmerjake | pushed the change-to-using-attribute-syntax changes to a branch..., lkcl when you get a chance, please review: https://bugs.libre-soc.org/show_bug.cgi?id=1072#c11 | 09:03 |
| lkcl | programmerjake, yes been meaning to add that for at least a year. nice | 10:18 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 10:18 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 10:19 | |
| lkcl | bear in mind though not to change the RTL unnecessarily "for the sake of using a different syntax". | 10:25 |
| lkcl | if XER[SO} is in the spec *please leave it alone* | 10:25 |
| programmerjake | in the spec it uses subscript, as well as FPSCR.field | 10:26 |
| programmerjake | so the changes actually make it match the spec better | 10:26 |
| lkcl | x.y has not been an issue because none of the pseudocode to date has ever needed it | 10:26 |
| programmerjake | FPSCR has a large number of fields, i don't want to have to have the kludge of adding bit positions for all of them in the global namespace | 10:27 |
| lkcl | you need to think through the following scenario: | 10:27 |
| programmerjake | also, the spec literally uses FPSCR.XX and not FPSCR[XX] | 10:28 |
| lkcl | "how can we auto-generate the *ACTUAL* specification pseudocode from the markdown"? | 10:28 |
| lkcl | yes that's fine | 10:28 |
| lkcl | i.e. | 10:28 |
| lkcl | "what is the maintenance cost *to us* of *NOT* being able to generate the [now latex] pseudocode that is actually in the actual spec, from the markdown"? | 10:29 |
| lkcl | and if there are dozens of ambiguities we're f****d. | 10:29 |
| lkcl | because we will have to maintain dozens of manual discrepancies | 10:29 |
| programmerjake | so what we do is simple...translate XER.SO to XER<sub>SO</sub> except latex not html | 10:29 |
| lkcl | markdown | 10:29 |
| lkcl | the source is in markdown | 10:30 |
| lkcl | not latex and not html | 10:30 |
| lkcl | right now it is dead easy. | 10:30 |
| lkcl | XER[SO] --> XER<sub>SO</sub> | 10:30 |
| programmerjake | the markdown in our repo is literally `XER.SO`, in the pdf they use subscript | 10:30 |
| lkcl | CR[32+BF] --> CR<sub>SO</sub> | 10:31 |
| lkcl | indeed. | 10:31 |
| programmerjake | no...CR<sub>32+BF</sub> | 10:31 |
| lkcl | whatever, you get the idea | 10:31 |
| lkcl | the other oddity is repeating-of-a-constant | 10:32 |
| lkcl | which is subscripted... the other way round. | 10:32 |
| lkcl | 1 sec... | 10:32 |
| programmerjake | superscripted | 10:33 |
| lkcl | yes | 10:33 |
| lkcl | superscript-N of X means "repeat x, N times" | 10:33 |
| lkcl | and annoyingly there was no ASCII syntax for that | 10:33 |
| lkcl | so i translated it to [X]*N | 10:34 |
| programmerjake | yeah, it is relatively straight forward to translate the new attribute syntax...however the pdf uses syntax inconsistently, some places use XER<sub>SO</sub> other places use FPSCR.XX | 10:34 |
| lkcl | which (i hope) can be spotted as unique | 10:34 |
| lkcl | sigh. | 10:34 |
| lkcl | different authors did different things at different times | 10:34 |
| lkcl | over the years | 10:34 |
| programmerjake | there's probably places using FPSCR<sub>something</sub> | 10:35 |
| lkcl | there's *three* wildly-different ways to access CR fields, one of which isn't even defined (CR.field[N]) | 10:35 |
| programmerjake | well, now that attributes are supported, adding CR.field[N] will be much easier | 10:36 |
| lkcl | indeed. | 10:36 |
| *** octavius <octavius!~octavius@92.40.168.24.threembb.co.uk> has joined #libre-soc | 10:36 | |
| programmerjake | yes, section A.4 uses: FPSCR<sub>FPRF</sub> <- “+ normal number” | 10:38 |
| lkcl | blech sigh | 10:38 |
| programmerjake | so i added support for assigning strings to FPRF too | 10:38 |
| lkcl | please be *really* careful not to go overboard here | 10:39 |
| programmerjake | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=30faac34669ce3f357c7d19f396933bebdfa36e5 | 10:39 |
| lkcl | that works. it's awful but it works | 10:40 |
| lkcl | we need to think through how the latex will be generated *exactly*, followed only then by XLEN-i-fi-cation, followed by then being able to propose *diffs* to the latex | 10:41 |
| lkcl | (!!) | 10:41 |
| lkcl | thus first the perfect replication of the latex (which the ISA WG still hasn't released sigh) has to be a target | 10:42 |
| programmerjake | imho we build a latex parser and have that be our source of truth...will be a bit of work tho | 10:42 |
| lkcl | hell no | 10:43 |
| programmerjake | hmm, pandoc markdown -> latex? | 10:43 |
| lkcl | with horrible-hacks as long as they're consistent | 10:44 |
| programmerjake | nah, pandoc doesn't cover everything | 10:44 |
| lkcl | this is hypothetical until they release the damn latex | 10:45 |
| programmerjake | well, in any case please do review that, gn | 10:45 |
| programmerjake | ttyl | 10:45 |
| lkcl | willdo. | 10:45 |
| programmerjake | thx! | 10:45 |
| programmerjake | oh, i just now noticed powerisa v3.1B has a pseudocode operator precedence table, we should check that our parser matches that -- section 1.3.4 | 10:50 |
| lkcl | please put these back | 10:53 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=7d7cc78fcb45ba6fef00483c0f078d825fed3be1 | 10:53 |
| programmerjake | i'll push the branch tomorrow, after i fix the issues you mentioned | 10:53 |
| programmerjake | ttyl | 10:53 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=921ef4aa0cbcc5bf15f73ce0dbc74e597912273e | 10:53 |
| lkcl | ok - night. thx jacob | 10:53 |
| *** octavius <octavius!~octavius@92.40.168.24.threembb.co.uk> has quit IRC | 12:06 | |
| *** octavius <octavius!~octavius@92.40.168.24.threembb.co.uk> has joined #libre-soc | 12:06 | |
| octavius | lkcl, did you say to look for 'self.info' in ISACaller? | 12:23 |
| octavius | Did you mean 'info' (an alias for self.instrs[ins_name]) which has a field 'form'? | 12:23 |
| octavius | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/decoder/isa/caller.py;h=a4c26965f13fd82ab9130c9b90afe59a0a5e3d24;hb=HEAD#l1984 | 12:23 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has quit IRC | 14:34 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.174> has joined #libre-soc | 14:35 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.174> has quit IRC | 14:42 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has joined #libre-soc | 14:45 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@91.205.168.99> has quit IRC | 14:54 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.174> has joined #libre-soc | 14:54 | |
| lkcl | octavius, that's the one. | 16:36 |
| lkcl | and they come from the auto-generated code decoder/isa/all.py | 16:39 |
| lkcl | so, ha, annoyingly, you'll need to dig a bit | 16:40 |
| lkcl | pywriter must be modified to *not* create class ISA with ISACaller inheriting in the list | 16:41 |
| lkcl | instead | 16:41 |
| lkcl | it must create something called "class ISAthateithertheModel*OR*ISACallercaninheritfrom" | 16:41 |
| lkcl | ghostmansd[m], given that you're back at work i'm assigning octavius to help with the model | 16:42 |
| ghostmansd[m] | Yeah, will be here tomorrow, today's holiday :-) | 16:43 |
| ghostmansd[m] | I'll have to spend some time establishing the environment on a new laptop | 16:44 |
| octavius | Thanks lkcl, will look at after I do the video recording | 16:45 |
| lkcl | ghostmansd[m], which made it back with you through customs, yay! | 16:45 |
| ghostmansd[m] | They don't care about it that much | 16:46 |
| ghostmansd[m] | As long as you pay money, they don't care :-) | 16:46 |
| *** octavius <octavius!~octavius@92.40.168.24.threembb.co.uk> has quit IRC | 17:10 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.174> has quit IRC | 17:23 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:24 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC | 17:52 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.107> has joined #libre-soc | 17:53 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@176.59.54.107> has quit IRC | 17:57 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc | 17:57 | |
| *** tplaten <tplaten!~tplaten@195.52.27.104> has joined #libre-soc | 18:50 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 19:10 | |
| *** octavius <octavius!~octavius@92.40.168.22.threembb.co.uk> has joined #libre-soc | 20:02 | |
| lkcl | markos_, programmerjake cesar meeting | 20:02 |
| *** tplaten <tplaten!~tplaten@195.52.27.104> has quit IRC | 20:17 | |
| *** octavius <octavius!~octavius@92.40.168.22.threembb.co.uk> has quit IRC | 20:23 | |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 20:40 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 20:40 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 21:47 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 21:48 | |
| markos_ | programmerjake, just to illustrate what I'm saying: try the following simple code | 21:54 |
| markos_ | first calculate the cos of M_PI_4 | 21:56 |
| markos_ | it should be 0.707107 | 21:56 |
| markos_ | then calculate cos for multiples of M_PI_4 | 21:56 |
| markos_ | well multiples of N*2*M_PI + M_PI_4 actually | 21:58 |
| markos_ | as you increase N, the value will diverge from 0.707107 | 21:58 |
| markos_ | eg for 10000000000000*2.0*M_PI+ M_PI_4 I get cos(x) = 0.705882 | 22:00 |
| programmerjake | yes, that's correct and expected according to ieee 754 | 22:00 |
| markos_ | for N= 1e100 I get 0.281999 | 22:01 |
| markos_ | well that's what I was talking about | 22:01 |
| markos_ | yes, it's predictable, no it's not correct | 22:01 |
| programmerjake | for sinpi, you should always get sqrt(0.5) until you run out of fraction bits | 22:02 |
| markos_ | so in essence, pi reduction does not work for larger values, *with doubles* and you need a type with far better precision | 22:02 |
| markos_ | it doesn't have to do with sin, this is a double limit/problem, the exponent is so large so that variations in the -pi/2..pi/2 range simply are impossible to hold | 22:03 |
| programmerjake | well, imho you're thinking about floats wrong, a float is a value that can hold some 100% precise mathematical values of the form m*2^e for integer m and e, and ieee 754 sin gives you the rounded sin of the precise input value you give it | 22:06 |
| programmerjake | pi isn't of the form m*2^e so needs to be rounded, the rounded form is what were computing sines of so is expected and correct to give values diverging from sqrt(0.5) | 22:07 |
| programmerjake | try running: import math | 22:09 |
| programmerjake | def sinpi(x): return math.sin(math.pi * (x % 2)) # good enough for a demo | 22:09 |
| programmerjake | for i in range(64): x=0.25+2**i; print(x.hex(),sinpi(x)) | 22:09 |
| programmerjake | it always gives sqrt(0.5) until the bit falls off the end of the mantissa, at which point it gives 0 | 22:10 |
| programmerjake | (ignoring i=0 of course) | 22:12 |
| programmerjake | to implement the pi reduction, traditionally double-doubles or double-double-doubles are used | 22:18 |
| programmerjake | sinpi doesn't have that problem, since the reduction results exactly coincide with the input float type | 22:19 |
| programmerjake | iirc there's a paper where they proved exactly how many bits you will ever need in the pi reduction intermediate for double, iirc it's like 150 or so | 22:21 |
| programmerjake | there's a reason amdgpu's sin instruction really computes sin2pi, reduction is much simpler | 22:23 |
| markos_ | programmerjake, I know how floats work, you're missing my point | 22:23 |
| markos_ | and floats are definitely not about 100% precision | 22:24 |
| programmerjake | i get your point, i just disagree that it's a problem... | 22:24 |
| markos_ | it's not a problem if the coder can deal with it | 22:24 |
| programmerjake | ieee 754 effectively defines them as 100% mathematically precise values | 22:25 |
| markos_ | if you do the same operation on eg. mathematica you will always get the correct answer | 22:25 |
| markos_ | we're talking past each other, being ieee 754 compliant doesn't mean it's mathematically correct | 22:25 |
| markos_ | I'm talking about mathematical correctness here | 22:26 |
| programmerjake | yes, you'll also get the divergence from sqrt(2) when evaluating Sin[RoundToDouble[RoundToDouble[Pi]+i]] | 22:26 |
| markos_ | well, if it diverges it's not 100% mathematically correct, that's my point, and yes it can be a problem | 22:27 |
| programmerjake | it is 100% mathematically correct, you're just computing a different function than sin, you're computing ieee754's sin | 22:28 |
| markos_ | try to do a convergence close to a singularity where everything goes off the scale and you'll have to resolve to another type of higher/arbitraty precision | 22:28 |
| markos_ | when people transfer mathematical formulas involving sin/cos and the like from paper to a program they usually expect the same behaviour | 22:29 |
| programmerjake | the problem arises when people expect the input of sin to behave like real numbers and not ieee754 fp | 22:30 |
| programmerjake | sin itself still computes the correct answer | 22:30 |
| markos_ | sin (the computer function) is an approximation of the actual sin (the mathematical function) | 22:31 |
| markos_ | it's correct when it's within an acceptable range | 22:31 |
| markos_ | if it diverges, then it's not correct, and they state it clearly that its approximation has limits | 22:32 |
| markos_ | you repeating that it's 100% correct does not negate the fact that it's not mathematically correct | 22:32 |
| programmerjake | it's correct for all ieee754 inputs, just those ieee754 inputs are an approximation of what the user expects...aka the users fault, not the sin implementation's fault | 22:33 |
| programmerjake | since ieee754 sin is defined as round_to_float(sin(real_value_of_float(x))) | 22:33 |
| programmerjake | ignoring non-finite inputs of course | 22:34 |
| markos_ | I'll give you a simple example, a 3d space simulator of the solar system it's completely impossible to do accurately using doubles right now at an absolute coordinate system | 22:34 |
| programmerjake | and zero signs | 22:34 |
| *** gnucode <gnucode!~gnucode@user/jab> has quit IRC | 22:34 | |
| *** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc | 22:35 | |
| markos_ | and by accurately I mean having eg. a spaceship rotate at the edge of the solar system at the same precision as it would rotate near the center | 22:35 |
| markos_ | so every system has to use local reference systems for each object | 22:35 |
| programmerjake | you can, you just need double-double-double...a bunch of times to get from planck length to light hours | 22:35 |
| markos_ | or switch to a type with higher precision | 22:35 |
| programmerjake | absolute precision! :) | 22:36 |
| markos_ | there is no such thing but anyway | 22:36 |
| markos_ | double is ok, when you operate within its limits | 22:36 |
| markos_ | as long as you are trying to do stuff that requires extra precision, good luck | 22:37 |
| markos_ | s/as long/as soon/ | 22:37 |
| markos_ | I've been bitten by this many many times | 22:37 |
| markos_ | even designed my own C++ template type of arbitrary fixed precision to deal with this problem, and even then | 22:38 |
| programmerjake | well, if you can represent every planck volume in the solar system then (assuming string theory's correct) all that's left is measurement error and quantum uncertainty and relativity | 22:38 |
| programmerjake | technically for that you could use bigints | 22:38 |
| markos_ | fixed precision was very good at a closed range, but it sucked dealing with extreme divergence -eg singularities or infinities, didn't matter if I would use 1M bits | 22:38 |
| markos_ | I did | 22:39 |
| markos_ | as soon as I had an exponential function things would go completely wrong | 22:39 |
| programmerjake | or, if you have lots of compute time, you could use the algebraic numbers types i implemented | 22:40 |
| markos_ | I wrote a type -and its AVX2 vectorized paths- for a fixed precision math library | 22:40 |
| markos_ | including all accompanying functions | 22:40 |
| programmerjake | if you can use EL-numbers, they work with complex exponentials too, giving exact 100% precise results not approximations | 22:40 |
| markos_ | worked great for closed range calculations, that could be confined within a certain limit, would totally suck as soon as one operation reached to infinity or close | 22:41 |
| markos_ | compute time is irrelevant, I could allocate 1M digits and some operations would still diverge around a singilarity | 22:42 |
| markos_ | even it would be computed instantly, it would still diverge | 22:43 |
| markos_ | ^ even if | 22:43 |
| programmerjake | well, algebraic numbers or el-numbers are a dense subset of real/complex numbers, so if it isn't exactly infinity it will give the correct answer | 22:44 |
| markos_ | yeah, in the end it turned out we had to move to the complex plane | 22:44 |
| markos_ | it deals with singularities much better | 22:44 |
| programmerjake | for el-sumbers, all you have to do is prove https://en.wikipedia.org/wiki/Schanuel%27s_conjecture :P | 22:45 |
| markos_ | you can do closed-loop integrals around singularities there | 22:45 |
| markos_ | anyway it's years since I did this | 22:45 |
| markos_ | would love to work on such stuff again | 22:45 |
| programmerjake | ah, integrals...need something more powerful than EL-numbers then... | 22:46 |
| programmerjake | since partial differential equations are turning complete iirc | 22:46 |
| programmerjake | halting problem, here we come! | 22:47 |
| lkcl | markos_, what programmerjake is referring to as "Not A Problem" is if you have *already* converted your entire algorithm to use sinpi | 23:54 |
| lkcl | at that point you have entirely side-stepped the issue. therefore in his mind "it is not a problem" | 23:55 |
| programmerjake | no, i'm saying it's not a problem for sin (not sinpi) to not be able to compute sines of large multiples of pi, since those aren't possible to represent in fp. therefore it's the user's fault for thinking that fp can represent large multiples of pi, it isn't sin's fault, it's correctly computing the sin of what it's given | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!