| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 06:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 06:11 | |
| ghostmansd[m] | lkcl, since #1068 is blocked, perhaps there are other tasks needing my attention? | 06:25 |
|---|---|---|
| ghostmansd[m] | You might have noticed that I did a lot recently, that's because I have a vacation on my work, so I can dedicate more time for a while :-) | 06:26 |
| ghostmansd[m] | We cannot miss such an opportunity! | 06:26 |
| programmerjake | lkcl may not be awake yet... | 06:31 |
| ghostmansd[m] | Well, I don't mean "please give me some task and next minute I'll be doing this" :-) | 06:35 |
| programmerjake | :) | 06:35 |
| programmerjake | if you like, you could probably try to add fminmax (not fminmaxs) to the simulator...I already wrote the pseudo-code on the wiki and figured out the opcode allocation | 06:37 |
| programmerjake | https://bugs.libre-soc.org/show_bug.cgi?id=1057#c0 | 06:37 |
| programmerjake | opcode: https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/power_trans_ops.mdwn;h=babf0130fcdfb0b25dfe25939d570ed9ca2375eb;hb=HEAD#l63 | 06:39 |
| programmerjake | pseudo-code: https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/sv/rfc/ls013.mdwn;h=084189d684e2917815c32effb3a72c57e9fb610d;hb=HEAD#l150 | 06:40 |
| programmerjake | just search openpower-isa.git for minmax and those are all the places to add fminmax (with appropriate adjustment for being a fp op instead of int) | 06:41 |
| klys | is libre-soc using microcode or anything like that or are all the ops at the register/latch/gate level? | 06:43 |
| ghostmansd[m] | Ok, perhaps will take this one! | 06:44 |
| ghostmansd[m] | Thanks programmerjake! | 06:44 |
| ghostmansd[m] | I'll wait for Luke before taking this, perhaps he has something else in mind | 06:44 |
| programmerjake | TBD, almost all register/latch/gate-level, but there are some ops that could arguably use microcode | 06:44 |
| programmerjake | e.g. SVP64 vector looping is kinda a form of microcode | 06:45 |
| programmerjake | and transcendental evaluation using CORDIC is kinda microcode | 06:46 |
| klys | which way do you think will result in less LUTs being used? | 06:47 |
| programmerjake | ghostmansd -- sounds good! | 06:47 |
| klys | I mean Logical Units not Look Up Tables | 06:48 |
| programmerjake | most of how we're implementing the CPU (with the major exception of SVP64's looping) does microcoding mostly within a Logical Unit, rather than across logical units | 06:49 |
| programmerjake | e.g. CORDIC just has a finite-state-machine in the Unit and just calculates until it's done | 06:50 |
| klys | so for perspective, cryptograhpy instructions are complete, and kazan isn't up yet, and you all are working on something in between them? | 06:52 |
| programmerjake | ghostmansd, actually, rather than searching for minmax, it'd be better to search for fmin/fmax because fminmax is replacing all those ops | 06:52 |
| programmerjake | we're currently working on submitting all the instructions we designed to the OpenPower ISA WG | 06:55 |
| klys | so you have designed all the kazan instructions? | 06:55 |
| programmerjake | some, there are plenty that actually need kazan to be further along before we can design them properly, mostly triangle rasterization and texture mapping instructions | 06:56 |
| programmerjake | most the other instructions that kazan would use are already designed because they're useful for non-GPU things too | 06:57 |
| programmerjake | or are sufficiently simple that they can be designed without having kazan up and working yet | 06:57 |
| programmerjake | such as mv.swizzle | 06:57 |
| klys | how large is the project git tree lately? | 06:59 |
| klys | I have a drive with 2TB and one with 12TB and would like to know where to checkout to | 06:59 |
| programmerjake | it'll easily fit, our server has like a <50GB disk, icr the exact number | 07:00 |
| klys | even with object code built? | 07:00 |
| programmerjake | a lot of it is python, so the stuff in git is the object code... | 07:01 |
| klys | ok | 07:01 |
| programmerjake | I have a 1TB disk on my desktop and haven't had problems yet | 07:01 |
| klys | should I just pull up the main page and follow the instructions? | 07:01 |
| programmerjake | yes, that'd probably work best | 07:02 |
| klys | thx | 07:02 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 07:17 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 07:18 | |
| ghostmansd[m] | programmerjake, does this mean that min/max are deprecated too? | 07:19 |
| programmerjake | integer min/max have been replaced with minmax, but min[us][w]/max[us][w] are now instruction aliases of minmax | 07:23 |
| programmerjake | see rfc013 which has a table | 07:24 |
| klys | what version of python3 are you using? mine has 3.11 | 08:02 |
| programmerjake | we're using 3.7 from debian | 08:04 |
| programmerjake | https://packages.debian.org/buster/python3.7 | 08:05 |
| programmerjake | if you follow the instructions on the wiki you'll get a debian buster chroot with all the required package versions | 08:07 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 08:18 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 08:22 | |
| ghostmansd[m] | It seems we must check binutils for update then; there's a patch which adds min[us][w] and max[us][w] | 08:23 |
| ghostmansd[m] | I'm not sure these insns have the opcodes they had when I added them. | 08:24 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 08:30 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 08:31 | |
| programmerjake | no, they have new encodings | 08:34 |
| programmerjake | they didn't fit where they were | 08:34 |
| ghostmansd[m] | Aha, this means we have to change these | 09:18 |
| ghostmansd[m] | Thanks! | 09:18 |
| ghostmansd[m] | I'll update it soon | 09:19 |
| klys | with buster I ran into a problem with this command: # git clone https://git.libre-soc.org/git/binutils-gdb.git ;where it would download the whole repo (takes a while) and then abort with "error: RPC failed; curl 56 GnuTLS recv error (-9): Error decoding the received TLS packet. fatal: the remote end hung up unexpectedly fatal: early EOF fatal: index-pack failed" so I did it with my most recent git | 10:03 |
| klys | from outside the chroot and it finally worked. | 10:04 |
| *** octavius <octavius!~octavius@92.40.169.167.threembb.co.uk> has joined #libre-soc | 10:13 | |
| octavius | klys, did you run the devscripts to setup a new Debian Buster chroot? | 10:14 |
| octavius | https://libre-soc.org/HDL_workflow/devscripts/ | 10:14 |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has quit IRC | 10:20 | |
| *** lxo <lxo!~lxo@gateway/tor-sasl/lxo> has joined #libre-soc | 10:33 | |
| klys | octavius, are you referring to this iota?: https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=mk-deb-chroot;h=76dcc8f666a0fc95b2ec4baea0ef77fccf73c42f;hb=HEAD#l140 | 10:46 |
| octavius | Yep, that's the one | 10:59 |
| octavius | But that wiki page also shows the other scripts that install the dependencies | 11:00 |
| octavius | I suggest you follow them, otherwise you'll go mad (based on personal experience) | 11:00 |
| lkcl | klys: don't attempt to do anything other than precisely and exactly follow the instructions. | 11:35 |
| lkcl | you don't have the time to go "off-piste" and - please don't take this the wrong way - neither do we have the time to "support" you if you are doing something that is different from following the tried-and-tested known-good known-working instructions | 11:36 |
| lkcl | in addition to that you will regret it because *when* you follow the instructions, you will go "oh my god what a total waste of my time i just subjected *myself* to by not following the instructions" | 11:37 |
| lkcl | we have had people *fail for weeks sometimes months* by not following the instructions | 11:37 |
| lkcl | then they follow the instructions | 11:37 |
| lkcl | and completely get up-to-speed within 1-3 days | 11:37 |
| lkcl | have i emphasised enough yet that it is best that you follow the instructions? | 11:37 |
| lkcl | :) | 11:38 |
| lkcl | the simplest list to follow is here | 11:38 |
| lkcl | https://libre-soc.org/HDL_workflow/devscripts/ | 11:38 |
| lkcl | octavius, no he didn't. he ignored the instructions and attempted to run the scripts within an unsupported environment. | 11:39 |
| lkcl | ghostmansd[m], i listed the minmax instructions here https://bugs.libre-soc.org/show_bug.cgi?id=1068#c2 | 11:40 |
| lkcl | as "REDO" | 11:40 |
| lkcl | i think from comment 15 you caught the integer minmax but not the FP minmax? | 11:41 |
| lkcl | the backports pinning is an utter pain in the ass. | 11:46 |
| *** mx08 <mx08!~mx08@user/mx08> has quit IRC | 11:47 | |
| lkcl | it violates the reproduceability criteria for a start | 11:47 |
| lkcl | as it's a constant moving target | 11:47 |
| *** mx08 <mx08!~mx08@user/mx08> has joined #libre-soc | 11:48 | |
| lkcl | not helped by gnutls going through a half-hearted sporadic sequence of "security" fixes, each of which producing conflicts with one piece of software then the next update mutually-exclusively fixing that one but breaking another | 11:48 |
| lkcl | sig | 11:48 |
| lkcl | h | 11:48 |
| lkcl | klys, if you find you run into problems with the devscripts please let us know - but please for goodness sake confirm that you actually did in fact run 100% only the devscripts, without deviation | 11:49 |
| lkcl | the amount of time i've wasted on people who could not clearly communicate that they hadn't followed the instructions makes me wince just thinking about it | 11:50 |
| ghostmansd[m] | lkcl, fminmax is not yet here in openpower-isa repo, that's why programmerjake suggested I introduce it | 11:51 |
| ghostmansd[m] | But I was talking not of minmax instruction, but about min* and max* family of instructions | 11:52 |
| ghostmansd[m] | These are to be re-done, actually | 11:52 |
| ghostmansd[m] | I'll redo them today | 11:53 |
| * lkcl just about waking up | 11:53 | |
| ghostmansd[m] | As for fminmax addition, I can do it, but there are already 3 persons there hunting for budget :-) | 11:54 |
| ghostmansd[m] | So I'd rather take something else | 11:54 |
| lkcl | hmm hmm well if you wanted a reasonably big task, we need a c version of power_decoder.py | 11:55 |
| lkcl | actually probably pretty much exactly what binutils does already but abstracted out so that it can be used in cavatools | 11:55 |
| lkcl | programmerjake, the fminmax* family needs a PO/XO space allocation first | 11:56 |
| lkcl | can you handle that? | 11:56 |
| lkcl | toshywoshy, ping, openpowerbot's still gone walkies :) | 11:57 |
| ghostmansd[m] | lkcl, he already did that IIUC: https://git.libre-soc.org/?p=libreriscv.git;a=blob;f=openpower/power_trans_ops.mdwn;h=babf0130fcdfb0b25dfe25939d570ed9ca2375eb;hb=HEAD#l63 | 12:00 |
| ghostmansd[m] | I can take a C version of power_decoder, but I cannot promise I can complete it soon :-) | 12:00 |
| ghostmansd[m] | Because it seems to be a large task | 12:00 |
| ghostmansd[m] | What's the time frame? | 12:01 |
| ghostmansd[m] | As for 1068, I'll fix min and max instructions, no problem :-) | 12:11 |
| ghostmansd[m] | Likely today | 12:12 |
| ghostmansd[m] | lkcl, programmerjake, I don't even understand how minu/mins are supposed to look like | 12:26 |
| ghostmansd[m] | They are no longer in repo | 12:26 |
| ghostmansd[m] | I assume these are aliases | 12:26 |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has joined #libre-soc | 12:28 | |
| ghostmansd | I assume this is the stuff: https://libre-soc.org/openpower/sv/rfc/ls013/ | 12:28 |
| ghostmansd | Generally binutils treat aliases as standalone instructions | 12:29 |
| ghostmansd | With their own operands and flags | 12:29 |
| ghostmansd | Folks, any other aliasing instructions which I might check to compare how they do it? | 12:30 |
| ghostmansd | Frankly speaking, I recall a talk "we're not going to support aliases yet" :-) | 12:37 |
| ghostmansd | > Folks, any other aliasing instructions which I might check to compare how they do it? | 12:41 |
| ghostmansd | Ah yeah, branches, so obvious | 12:42 |
| ghostmansd[m] | Yes, these minXX/maxXX are indeed separate insns from binutils point of view | 12:43 |
| ghostmansd[m] | Ok I'll do it | 12:43 |
| ghostmansd[m] | But please formulate it more obviously than "REDO minmax" | 12:43 |
| ghostmansd[m] | It's totally cryptic for someone lacking the context | 12:44 |
| ghostmansd[m] | The correct incantation should've been: "with the advent of minmax insn, minXX/maxx instructions should be redone; see https://libre-soc.org/openpower/sv/rfc/ls013/ to understand that these are aliases to common insn" | 12:46 |
| ghostmansd[m] | Because I had to guess it from programmerjake messages and lookup at wiki, which obviously wastes a lot of time. In other words, please do not assume anyone has the context you have, and give the whole information needed. | 12:48 |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has quit IRC | 12:52 | |
| *** openpowerbot_ <openpowerbot_!~openpower@94-226-187-44.access.telenet.be> has quit IRC | 13:36 | |
| *** openpowerbot_ <openpowerbot_!~openpower@94.226.187.44> has joined #libre-soc | 13:37 | |
| lkcl | ghostmansd[m], yes they are aliases | 14:59 |
| lkcl | sorry, i am just about coping | 15:01 |
| lkcl | octavius, don't make any attempt to modify the processor RTL. work with what you've got: recompile the BINARY to be at that address and set ls2 to put the **BINARY** at that address. | 15:07 |
| lkcl | that's why i pointed you towards the linker script as a first step: to recompile the BINARY to be at the starting (PC) address | 15:08 |
| lkcl | you've been at this over a week trying to maybe understand something that is not necessary to understand | 15:08 |
| lkcl | you should have flowed round the problem instead, until such time as you do understand it | 15:09 |
| lkcl | octavius, i checked from the last time i ran this (well over a year ago) - there's a #define RESET_ADDRESS in the Makefile. | 15:17 |
| lkcl | it gets hard-coded into the microwatt VHDL. | 15:18 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 16:11 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.195.231.113> has joined #libre-soc | 16:38 | |
| octavius | Yep, I saw that RESET_ADDRESS, and checked the VHDL that it does indeed generate 0xff00_000 (mentioned in my earlier comments). | 17:01 |
| octavius | Obviously, the binary header needs to have an address pointing to where the main function .text begins. My guess this whole time has been that the '_start' symbol in powerpc.lds linker script is this address. I seem to be wrong on this. | 17:01 |
| octavius | I tried following address values for _start: 0, 0x1000, 0x1014, 0xff00_0000, 0xff00_1000, 0xff00_1014. | 17:01 |
| octavius | Here's a link to the objdump for when _start was set to 0xff00_0000 (line #113 shows the symbol entry for _start): https://pastebin.com/5i4fBXsD | 17:01 |
| octavius | This symbol table looks identical for other permutations (other than the _start symbol of course). On line #22 it says the start address is 0x1000 (which I've also tried to set _start to). | 17:01 |
| octavius | The objdump shows a symbol .text.startup.main starting at 0x1014, so my reasoning is that if the CPU jumps to this location (0xff00_1014), then it will reach the first instruction of the code. Is my reasoning incorrect? | 17:01 |
| octavius | I tried to change the .head and .text addresses, but that was obviously wrong because those correspond to the binary itself (making the binary large). | 17:01 |
| markos_ | lkcl, programmerjake ok, I worked a few hours on this, there were a few things that got me concerned, I have something working now, but! (there is always a but) | 17:15 |
| markos_ | a) when I tried to handle large 128-bit products, many problems arose, positive values worked fine, but as soon as there was a negative involved... | 17:16 |
| markos_ | I tried to add special case for that, but the code became so complex that it was almost incomprehensible after a point | 17:17 |
| lkcl | octavius, remember you can't run objdump on the raw binary, only on the .elf | 17:17 |
| lkcl | but once you strip down to the raw binary you *cannot recover* the actual address that the binary is supposed to go at | 17:18 |
| lkcl | you also need to read the start.S assembler (and understand it) | 17:18 |
| markos_ | in the end I decided to revert to a previous state, 64-bit values work fine as long as you don't have overflow to the higher half of the product | 17:18 |
| * lkcl going out to throw food at ducks | 17:19 | |
| lkcl | markos_, will be back in 1/2 hr or so | 17:19 |
| markos_ | I prefer to have something working, readable and relevant to 99% of the case, rather than something complex and useful in only a few cases | 17:19 |
| markos_ | lkcl, sure | 17:19 |
| lkcl | seems to me that you may need an arithmetic-shift not a straight ROTL64 | 17:19 |
| markos_ | well, I copied the logic from other instructions, it works now and is easy to understand | 17:20 |
| markos_ | if it can be done simpler, all the better | 17:20 |
| programmerjake | well, imho we need the pseudo-code to be 100% correct, otherwise all cpus *will be required* to misbehave as specified | 17:21 |
| markos_ | it is correct, as long as the product does not overflow | 17:21 |
| markos_ | remember the original usecase was video codecs | 17:22 |
| markos_ | there is zero use right now for 128-bit values in any such case | 17:23 |
| markos_ | even 64-bit is pushing it | 17:23 |
| markos_ | no other platform has something even remotely close to those that can handle 64-bit values | 17:23 |
| programmerjake | i think the issue you're running into is that both addition and subtraction technically produce values that exceed 64-bits in range, therefore the product needs to take the full input range into account | 17:23 |
| markos_ | that's not really true, there are many instructions with a reduced precision, in fact, even the arm ones have a much reduced precision and because of that they cannot be used in all the cases | 17:24 |
| programmerjake | elwid=16/32 change that to 16/32-bit...so a 33-bit/65-bit product needs to be shifted/rounded to 16/32-bits | 17:24 |
| markos_ | addition and subtraction only produce exceeding values if the constant c is ridiculously large -eg 2^32 | 17:25 |
| markos_ | but this is hardly the case | 17:25 |
| programmerjake | well, if ours can be used in all cases, why not implement that :) | 17:25 |
| programmerjake | oh, i thought this was fixed-point, e.g. 2.14-bit | 17:25 |
| markos_ | well, the goal is to make it also fast, if we make it too complex and it's not faster than the 8 instruction we're replacing, what's the point | 17:26 |
| markos_ | no it's pure integer | 17:26 |
| programmerjake | so typical cos values would be 2^14 | 17:26 |
| programmerjake | fixed point implemented using integers and shifting/rounding afaict...DCT would otherwise have 0/1/-1 for all cos values since those are the closest integers | 17:28 |
| programmerjake | rendering the DCT largely useless due to imprecise cos values | 17:28 |
| programmerjake | the nice thing about hardware is a 33-bit product is basically just as fast as a 32-bit product, unlike software | 17:30 |
| markos_ | well, those video codecs I've been working on are using 16-bit values for cos values, and I seriously doubt this is going to change | 17:31 |
| programmerjake | so making the pseudo-code more complex to achieve correctness doesn't necessarily imply that hw is slower | 17:31 |
| markos_ | it definitely implies though that it will not be faster than the simpler version :) | 17:31 |
| programmerjake | hmm, then why not just build a hardwired to 14-bit shift version, like i'm guessing arm does? | 17:32 |
| markos_ | and again, regarding correctness, as long as you define the set where the instruction is valid, what's wrong with that? | 17:32 |
| markos_ | a) because we can, b) it is also useful in other cases, eg. SH=0 -> FFT addsub | 17:33 |
| programmerjake | imho what's wrong is when you want to use it for non-video codecs (e.g. general compiler optimizations) where you need the whole range, not just whatever av1 needs | 17:34 |
| markos_ | also, in the case, where another video codec -or another software, crypto for example, decides to use something similar with a different shift value | 17:35 |
| markos_ | compilers also know the limits of their instructions, or they should if programmed correctly | 17:35 |
| markos_ | anyway, it's not that I didn't try | 17:35 |
| markos_ | but the main problem was this | 17:36 |
| programmerjake | maybe i'll try... | 17:36 |
| markos_ | honestly, I'd rather not unless lkcl agrees with going that way | 17:36 |
| programmerjake | i may end up with a simpler version that's still 100% correct.., | 17:37 |
| markos_ | the main problem was that with a negative large product, splitting it in low and half and adding the round constant has to be done in both halves and extending the sign bit also | 17:38 |
| markos_ | I had to add special cases and the code was really ugly and far from easy to read | 17:38 |
| markos_ | yes, you might but again I'm going to disagree, unless lkcl thinks this is the right approach | 17:40 |
| markos_ | this is not a competition you know | 17:40 |
| markos_ | and this is not the first instruction that does not produce correct values outside a certain range | 17:41 |
| programmerjake | well, i do think it should be correct when it can, i expect the hw required to be only slightly larger | 17:44 |
| markos_ | and regardless, this instruction IS *specifically* for video codecs and integer DCTs, the non-video codec usecases are imho irrelevant at the moment | 17:44 |
| markos_ | I'm going to be honest, I'm getting a bit annoyed that you constantly have to prove you are right | 17:44 |
| programmerjake | yeah, i'm not trying to compete, i'm trying to achieve correctness | 17:44 |
| markos_ | it's correct within 64-bits, where the competition struggles at 16 and 32-bit, what more can you ask? | 17:45 |
| programmerjake | sorry, proving i'm right isn't my goal | 17:46 |
| markos_ | I'm going to leave it to lkcl to decide | 17:46 |
| markos_ | if he says it should be correct at full 128-bit products, go ahead and fix it | 17:47 |
| programmerjake | because when setting elwid=16/32 the correctness scales down to 16/32-bits, so if it gives the wrong answers for 64-bit it'll also give wrong answers for 16/32-bit | 17:47 |
| markos_ | but if it ends up being hundreds of lines of pseudocode then I'm still going to disagree | 17:47 |
| programmerjake | it won't, i'm expecting on the order of 20 lines | 17:48 |
| markos_ | it's ~25 lines now | 17:49 |
| programmerjake | since i'm planning on treating it as large words rather than splitting it into low/high halves and using bit slicing rather than ROTL64 | 17:49 |
| programmerjake | yes, you have several special cases that i think i can avoid needing to treat specially | 17:49 |
| markos_ | 2 | 17:51 |
| markos_ | n=0, n=1, those are the special cases, the other is the generic case | 17:51 |
| markos_ | and n=1 was needed only because [1]*(n-1) throwed an error | 17:52 |
| markos_ | [0]*(n-1) | 17:52 |
| programmerjake | gtg, ttyl | 17:53 |
| lkcl | yep i would say it's reasonable to expect programmers not to use ridiculously-large coefficients | 18:32 |
| lkcl | markos_, you can get away with (i think): | 18:35 |
| lkcl | round <- [0]*XLEN | 18:35 |
| lkcl | round[n] <- 1 | 18:35 |
| lkcl | something like that | 18:36 |
| programmerjake | round[XLEN-n-1] <- 1 | 18:36 |
| lkcl | that looks about right. | 18:37 |
| lkcl | did the "look-at-arithmetic-shifting" help? | 18:38 |
| markos_ | that's what I do, I'm basically copying sradi | 18:55 |
| markos_ | I take it you mean algebraic shifting, unless this is something else | 18:57 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.195.231.113> has quit IRC | 18:59 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 19:00 | |
| markos_ | yes, was actually round[XLEN-n] <- 1 , but it worked nicely, thanks for the tip | 19:01 |
| *** markos_ <markos_!~Konstanti@static062038151250.dsl.hol.gr> has quit IRC | 19:17 | |
| *** markos_ <markos_!~markos@static062038151250.dsl.hol.gr> has joined #libre-soc | 19:18 | |
| *** markos_ <markos_!~markos_@static062038151250.dsl.hol.gr> has joined #libre-soc | 19:19 | |
| *** markos_ <markos_!~markos_@static062038151250.dsl.hol.gr> has joined #libre-soc | 19:19 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has joined #libre-soc | 19:20 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has quit IRC | 19:21 | |
| *** markos_ <markos_!~markos_@user/markos/x-1838887> has joined #libre-soc | 19:21 | |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has joined #libre-soc | 19:40 | |
| markos_ | lkcl, programmerjake I'm sorry for my outburst a while ago, please note that I don't mind if programmerjake can demonstrate a simpler way to handle the full range | 19:51 |
| markos_ | provided you're ok with that and it's an easy fix, ie it doesn't take up much of his time | 19:52 |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has quit IRC | 20:15 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 20:28 | |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has joined #libre-soc | 20:30 | |
| ghostmansd | lkcl, markos, programmerjake, minmax aliases are implemented in binutils | 20:49 |
| ghostmansd | few things to check: https://bugs.libre-soc.org/show_bug.cgi?id=1068#c22 | 20:50 |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has quit IRC | 20:54 | |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has joined #libre-soc | 20:54 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 20:55 | |
| ghostmansd[m] | especially check "minmax on asm, min or max on disasm" section | 20:59 |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has quit IRC | 21:01 | |
| *** ghostmansd[m] <ghostmansd[m]!~ghostmans@5.32.74.194> has joined #libre-soc | 21:02 | |
| *** ghostmansd <ghostmansd!~ghostmans@5.32.74.194> has quit IRC | 21:40 | |
| *** octavius <octavius!~octavius@92.40.169.167.threembb.co.uk> has quit IRC | 23:39 | |
| *** octavius <octavius!~octavius@92.40.169.163.threembb.co.uk> has joined #libre-soc | 23:54 | |
| octavius | I've been studying the assembler file used to bootstrap the microwatt core (which then jumps to main), and wanted to see how it compares to the compiled binary. Is there a disassembler program that can convert the machine code back to assembler for power? | 23:56 |
| programmerjake | yes, objdump (the powerpc64le version) | 23:57 |
| programmerjake | use objdump -d on the elf file | 23:57 |
| programmerjake | you can use it on the binary too iirc but you need to give it more flags telling it where it goes in memory and a bunch of other stuff but the elf file has all of that info so you don't need to tell objdump | 23:59 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!