Tuesday, 2023-05-09

lkclprogrammerjake, good insight on LD/St... urrr so much work implied though00:01
lkclknock-on-effect to binutils aside from anything00:01
programmerjakesorry ghostmansd...00:08
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC00:20
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc00:21
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC01:09
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc01:09
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC02:51
programmerjakeI 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 mtfsfi04:05
programmerjakeI'm going to change the pseudocode and parser to do that in a branch04:06
programmerjakebasically...add support for var.field04:07
ghostmansd[m]lkcl, programmerjake, which works in binutils do you mean?04:55
ghostmansd[m]I probably missed something04:55
programmerjakeoh, we're redoing some load/store bits in SVP64: https://bugs.libre-soc.org/show_bug.cgi?id=108004:56
ghostmansd[m]> aieee this is going to be fun05:16
ghostmansd[m]The best summary of the dicussion :-)05:17
programmerjakeat least you kinda get your wish of having more EXTRA3 operands...05:17
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC05:55
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc06:30
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC06:37
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc06:38
ghostmansd[m]But not for every operand I guess :-)07:09
ghostmansd[m]Congratulate on Victory Day!07:10
programmerjakeoh, yeah. yay! peace is nice!07:11
programmerjakeI'm not very good at keeping track of holidays...07:11
ghostmansd[m]This is one of the holidays I always track :-)07:17
programmerjakepushed 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#c1109:03
lkclprogrammerjake, yes been meaning to add that for at least a year. nice10:18
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC10:18
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc10:19
lkclbear in mind though not to change the RTL unnecessarily "for the sake of using a different syntax".10:25
lkclif XER[SO} is in the spec *please leave it alone*10:25
programmerjakein the spec it uses subscript, as well as FPSCR.field10:26
programmerjakeso the changes actually make it match the spec better10:26
lkclx.y has not been an issue because none of the pseudocode to date has ever needed it10:26
programmerjakeFPSCR 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 namespace10:27
lkclyou need to think through the following scenario:10:27
programmerjakealso, 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
lkclyes that's fine10: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
lkcland if there are dozens of ambiguities we're f****d.10:29
lkclbecause we will have to maintain dozens of manual discrepancies10:29
programmerjakeso what we do is simple...translate XER.SO to XER<sub>SO</sub> except latex not html10:29
lkclthe source is in markdown10:30
lkclnot latex and not html10:30
lkclright now it is dead easy.10:30
lkclXER[SO] --> XER<sub>SO</sub>10:30
programmerjakethe markdown in our repo is literally `XER.SO`, in the pdf they use subscript10:30
lkclCR[32+BF] --> CR<sub>SO</sub>10:31
lkclwhatever, you get the idea10:31
lkclthe other oddity is repeating-of-a-constant10:32
lkclwhich is subscripted... the other way round.10:32
lkcl1 sec...10:32
lkclsuperscript-N of X means "repeat x, N times"10:33
lkcland annoyingly there was no ASCII syntax for that10:33
lkclso i translated it to [X]*N10:34
programmerjakeyeah, 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.XX10:34
lkclwhich (i hope) can be spotted as unique10:34
lkcldifferent authors did different things at different times10:34
lkclover the years10:34
programmerjakethere's probably places using FPSCR<sub>something</sub>10:35
lkclthere's *three* wildly-different ways to access CR fields, one of which isn't even defined (CR.field[N])10:35
programmerjakewell, now that attributes are supported, adding CR.field[N] will be much easier10:36
*** octavius <octavius!~octavius@> has joined #libre-soc10:36
programmerjakeyes, section A.4 uses: FPSCR<sub>FPRF</sub> <- “+ normal number”10:38
lkclblech sigh10:38
programmerjakeso i added support for assigning strings to FPRF too10:38
lkclplease be *really* careful not to go overboard here10:39
lkclthat works.  it's awful but it works10:40
lkclwe 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 latex10:41
lkclthus first the perfect replication of the latex (which the ISA WG still hasn't released sigh) has to be a target10:42
programmerjakeimho we build a latex parser and have that be our source of truth...will be a bit of work tho10:42
lkclhell no10:43
programmerjakehmm, pandoc markdown -> latex?10:43
lkclwith horrible-hacks as long as they're consistent10:44
programmerjakenah, pandoc doesn't cover everything10:44
lkclthis is hypothetical until they release the damn latex10:45
programmerjakewell, in any case please do review that, gn10:45
programmerjakeoh, i just now noticed powerisa v3.1B has a pseudocode operator precedence table, we should check that our parser matches that -- section 1.3.410:50
lkclplease put these back10:53
programmerjakei'll push the branch tomorrow, after i fix the issues you mentioned10:53
lkclok - night.  thx jacob10:53
*** octavius <octavius!~octavius@> has quit IRC12:06
*** octavius <octavius!~octavius@> has joined #libre-soc12:06
octaviuslkcl, did you say to look for 'self.info' in ISACaller?12:23
octaviusDid you mean 'info' (an alias for self.instrs[ins_name]) which has a field 'form'?12:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:34
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:35
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:42
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:45
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC14:54
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc14:54
lkcloctavius, that's the one.16:36
lkcland they come from the auto-generated code decoder/isa/all.py16:39
lkclso, ha, annoyingly, you'll need to dig a bit16:40
lkclpywriter must be modified to *not* create class ISA with ISACaller inheriting in the list16:41
lkclit must create something called "class ISAthateithertheModel*OR*ISACallercaninheritfrom"16:41
lkclghostmansd[m], given that you're back at work i'm assigning octavius to help with the model16: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 laptop16:44
octaviusThanks lkcl, will look at after I do the video recording16:45
lkclghostmansd[m], which made it back with you through customs, yay!16:45
ghostmansd[m]They don't care about it that much16:46
ghostmansd[m]As long as you pay money, they don't care :-)16:46
*** octavius <octavius!~octavius@> has quit IRC17:10
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:23
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc17:24
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has quit IRC17:52
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has joined #libre-soc17:53
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@> has quit IRC17:57
*** ghostmansd[m] <ghostmansd[m]!~ghostmans@broadband-109-173-83-100.ip.moscow.rt.ru> has joined #libre-soc17:57
*** tplaten <tplaten!~tplaten@> has joined #libre-soc18:50
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc19:10
*** octavius <octavius!~octavius@> has joined #libre-soc20:02
lkclmarkos_, programmerjake cesar meeting20:02
*** tplaten <tplaten!~tplaten@> has quit IRC20:17
*** octavius <octavius!~octavius@> has quit IRC20:23
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC20:40
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc20:40
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC21:47
*** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc21:48
markos_programmerjake, just to illustrate what I'm saying: try the following simple code21:54
markos_first calculate the cos of M_PI_421:56
markos_it should be 0.70710721:56
markos_then calculate cos for multiples of M_PI_421:56
markos_well multiples of N*2*M_PI + M_PI_4 actually21:58
markos_as you increase N, the value will diverge from 0.70710721:58
markos_eg for 10000000000000*2.0*M_PI+ M_PI_4 I get cos(x) = 0.70588222:00
programmerjakeyes, that's correct and expected according to ieee 75422:00
markos_for N= 1e100 I get 0.28199922:01
markos_well that's what I was talking about22:01
markos_yes, it's predictable, no it's not correct22:01
programmerjakefor sinpi, you should always get sqrt(0.5) until you run out of fraction bits22:02
markos_so in essence, pi reduction does not work for larger values, *with doubles* and you need a type with far better precision22: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 hold22:03
programmerjakewell, 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 it22:06
programmerjakepi 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
programmerjaketry running: import math22:09
programmerjakedef sinpi(x): return math.sin(math.pi * (x % 2)) # good enough for a demo22:09
programmerjakefor i in range(64): x=0.25+2**i; print(x.hex(),sinpi(x))22:09
programmerjakeit always gives sqrt(0.5) until the bit falls off the end of the mantissa, at which point it gives 022:10
programmerjake(ignoring i=0 of course)22:12
programmerjaketo implement the pi reduction, traditionally double-doubles or double-double-doubles are used22:18
programmerjakesinpi doesn't have that problem, since the reduction results exactly coincide with the input float type22:19
programmerjakeiirc 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 so22:21
programmerjakethere's a reason amdgpu's sin instruction really computes sin2pi, reduction is much simpler22:23
markos_programmerjake, I know how floats work, you're missing my point22:23
markos_and floats are definitely not about 100% precision22:24
programmerjakei 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 it22:24
programmerjakeieee 754 effectively defines them as 100% mathematically precise values22:25
markos_if you do the same operation on eg. mathematica you will always get the correct answer22:25
markos_we're talking past each other, being ieee 754 compliant doesn't mean it's mathematically correct22:25
markos_I'm talking about mathematical correctness here22:26
programmerjakeyes, 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 problem22:27
programmerjakeit is 100% mathematically correct, you're just computing a different function than sin, you're computing ieee754's sin22: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 precision22:28
markos_when people transfer mathematical formulas involving sin/cos and the like from paper to a program they usually expect the same behaviour22:29
programmerjakethe problem arises when people expect the input of sin to behave like real numbers and not ieee754 fp22:30
programmerjakesin itself still computes the correct answer22: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 range22:31
markos_if it diverges, then it's not correct, and they state it clearly that its approximation has limits22:32
markos_you repeating that it's 100% correct does not negate the fact that it's not mathematically correct22:32
programmerjakeit'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 fault22:33
programmerjakesince ieee754 sin is defined as round_to_float(sin(real_value_of_float(x)))22:33
programmerjakeignoring non-finite inputs of course22: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 system22:34
programmerjakeand zero signs22:34
*** gnucode <gnucode!~gnucode@user/jab> has quit IRC22:34
*** gnucode <gnucode!~gnucode@user/jab> has joined #libre-soc22: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 center22:35
markos_so every system has to use local reference systems for each object22:35
programmerjakeyou can, you just need double-double-double...a bunch of times to get from planck length to light hours22:35
markos_or switch to a type with higher precision22:35
programmerjakeabsolute precision! :)22:36
markos_there is no such thing but anyway22:36
markos_double is ok, when you operate within its limits22:36
markos_as long as you are trying to do stuff that requires extra precision, good luck22:37
markos_s/as long/as soon/22:37
markos_I've been bitten by this many many times22:37
markos_even designed my own C++ template type of arbitrary fixed precision to deal with this problem, and even then22:38
programmerjakewell, 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 relativity22:38
programmerjaketechnically for that you could use bigints22: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 bits22:38
markos_I did22:39
markos_as soon as I had an exponential function things would go completely wrong22:39
programmerjakeor, if you have lots of compute time, you could use the algebraic numbers types i implemented22:40
markos_I wrote a type -and its AVX2 vectorized paths- for a fixed precision math library22:40
markos_including all accompanying functions22:40
programmerjakeif you can use EL-numbers, they work with complex exponentials too, giving exact 100% precise results not approximations22: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 close22:41
markos_compute time is irrelevant, I could allocate 1M digits and some operations would still diverge around a singilarity22:42
markos_even it would be computed instantly, it would still diverge22:43
markos_^ even if22:43
programmerjakewell, 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 answer22:44
markos_yeah, in the end it turned out we had to move to the complex plane22:44
markos_it deals with singularities much better22:44
programmerjakefor el-sumbers, all you have to do is prove https://en.wikipedia.org/wiki/Schanuel%27s_conjecture  :P22:45
markos_you can do closed-loop integrals around singularities there22:45
markos_anyway it's years since I did this22:45
markos_would love to work on such stuff again22:45
programmerjakeah, integrals...need something more powerful than EL-numbers then...22:46
programmerjakesince partial differential equations are turning complete iirc22:46
programmerjakehalting problem, here we come!22:47
lkclmarkos_, what programmerjake is referring to as "Not A Problem" is if you have *already* converted your entire algorithm to use sinpi23:54
lkclat that point you have entirely side-stepped the issue.  therefore in his mind "it is not a problem"23:55
programmerjakeno, 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 given23:59

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