| ghostmansd[m] | lkcl, I read the Alan's reply and your additions. I think it'd be easier to really just change the conventions. | 06:14 |
|---|---|---|
| ghostmansd[m] | That said, if time permits, I can try some tricks with a tree. | 06:16 |
| lkcl | ghostmansd[m], yeah agreed about changing conventions. | 10:02 |
| lkcl | sigh, ~ff=ne as well | 10:02 |
| ghostmansd[m] | What does it mean, ~ff=ne? | 10:04 |
| lkcl | fail-first based on inverted CR bit... oh right | 10:04 |
| lkcl | ~ff=eq | 10:04 |
| lkcl | hmmm that's not obvious at all is it | 10:05 |
| lkcl | inverted fail-first equal | 10:05 |
| lkcl | don't like it. | 10:05 |
| lkcl | tree-changing is probably a better overall approach. | 10:06 |
| octavius | hi lkcl, I've been looking at the spec pdf, and noticed the fields.tex doesn't separate the bitfields lines. | 10:59 |
| octavius | If there's a way to add \par at the end of every line, that could make things clearer. Another problem is the column padding, as well as sub-columns (for example bits 6-10 corresponding to the RT bitfield/column in X-FORM) which look the same. | 10:59 |
| lkcl | bitfield lines, que? que? | 11:00 |
| lkcl | fields.tex... ahh | 11:00 |
| lkcl | we have to be careful about fields.tex because power_fields.py is its corresponding machine-reader | 11:01 |
| octavius | Ah ok | 11:02 |
| lkcl | fields.tex is very deliberately *not* done as tables because the "|"s are bit-aligners using ascii | 11:02 |
| lkcl | look at DQ-Form for an example | 11:02 |
| lkcl | 33 #1.6.6 DQ-FORM | 11:03 |
| lkcl | 34 |0 |6 |11 |16 |28|29 |31 | | 11:03 |
| lkcl | 35 | PO | RTp | RA | DQ | PT | | 11:03 |
| lkcl | 36 | PO | S | RA | DQ |SX| XO | | 11:03 |
| lkcl | PT spreads across 28-31 | 11:03 |
| octavius | At least for the entries, there's probably a way to add \par? Otherwise the document just shows a stream of numbers, letters and | XD | 11:04 |
| lkcl | but SX is bit 28 and XO bits 28-31 for the other variant of DQ-Form | 11:04 |
| lkcl | no it doesn't. | 11:04 |
| octavius | I mean in the filtering | 11:04 |
| lkcl | git pull on openpower-isa, you are out-of-date | 11:04 |
| octavius | ah ok | 11:05 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=b7bdc6cb587beab6c34408a5137ac451ec546e27 | 11:05 |
| lkcl | @@ -1,318 +1,318 @@ | 11:05 |
| lkcl | #1.6.1 I-FORM | 11:05 |
| lkcl | - | PO | LI |AA|LK | | 11:05 |
| lkcl | + |0 |6 |30|31 | | 11:05 |
| lkcl | i added one extra space which brings it to a total of 4 spaces which is the trigger for "fixed-width-font-code-block" in markdown | 11:06 |
| octavius | Ah ok, something wrong with my repo (comparing against the generated pdf on the ftp server) | 11:08 |
| octavius | I did git pull already | 11:08 |
| lkcl | make clean | 11:12 |
| octavius | Ah, I was dumb. My libreriscv repo is not in a chroot, and I have a separate copy of openpower which I didn't git pull | 11:12 |
| lkcl | :) | 11:12 |
| octavius | Now I did fix some missing spaces for three sub-headings in fields.text, it caused the pandoc to not generate correctly | 11:17 |
| lkcl | *DON'T* alter fields.text. | 11:20 |
| lkcl | it is a mission-critical file where if you make a mistake it will terminate absolutely everything | 11:21 |
| lkcl | simulator | 11:21 |
| lkcl | unit tests | 11:21 |
| lkcl | TestIssuer | 11:21 |
| lkcl | absolutely everything fundamentally and critically relies on those machine-readable files. | 11:21 |
| lkcl | there are a couple of mistakes i've spotted (compared to the v3.0B spec that fields.txt was taken from) but fortunately those aren't in use | 11:22 |
| lkcl | please drop a -/+ diff here in irc for review on *exactly* what you mean "fix some missing spaces for three sub-headings" | 11:24 |
| lkcl | https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=6aa7a4619676d4c5a5ce245489feb607e83b5e58 | 11:25 |
| lkcl | did you run any unit tests to check that those changes did not break anything? | 11:25 |
| octavius | No I didn't, sorry about that. | 11:25 |
| lkcl | octavius, that is absolutely critical to do | 11:26 |
| lkcl | you may have terminated everyone's ability to do any work | 11:26 |
| lkcl | this is source code, not a "random document" | 11:26 |
| octavius | Where are the tests that I need to run before any submission? | 11:27 |
| lkcl | it might seem "obvious" that "oh just add a space" | 11:27 |
| lkcl | all of them in this case! | 11:27 |
| lkcl | executing power_fields.py to check it reads is the first priority | 11:27 |
| octavius | in openpower-isa, or are you talking about *all* the dev repos? | 11:27 |
| lkcl | well it is diminishing returns | 11:27 |
| lkcl | in this case, if just one of test_caller*.py works then chances are that you didn't do any damage to the file format | 11:28 |
| lkcl | but even pywriter critically depends on fields.text through power_fields.py | 11:28 |
| lkcl | sv_analysis | 11:28 |
| lkcl | sv_binutils | 11:28 |
| lkcl | absolutely everything | 11:28 |
| lkcl | if you had changed one of the Forms itself then that could have damaged just one of the instructions | 11:29 |
| lkcl | or more | 11:29 |
| lkcl | and finding out which? the only way: run *all* unit tests. | 11:29 |
| lkcl | so you have to be intelligent about it. | 11:30 |
| lkcl | in this case as it is just headings that you changed, chances are high that there's not been any damage | 11:30 |
| lkcl | but you still have to check (running power_fields.py and a couple of test_caller*.py tests would do that) | 11:31 |
| octavius | I ran the power_fields.py and it generated. I'll try some of the test_caller tests now | 11:32 |
| lkcl | brilliant | 11:33 |
| lkcl | one (short one) will do. | 11:33 |
| octavius | test_caller_bcd ran and passed. test_caller_bitmanip ran and passed, but has an UnboundLocalError: local variable 'insn' referenced before assignment | 11:40 |
| lkcl | octavius, 1 sec | 11:41 |
| octavius | Ah sorry, that's found in svp64.py | 11:41 |
| octavius | https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=src/openpower/sv/trans/svp64.py;h=f4b03a5f276967d0570f2f97660fc3e7228b97a9;hb=HEAD#l293 | 11:43 |
| octavius | the grev function doesn't define insn | 11:44 |
| lkcl | yep, that's ghostmansd[m] sorting out svp64.py last week, consolidating things. | 11:45 |
| octavius | Also, I apologise for not running the commit with the team beforehand. And thank you for the warning and lesson, it's a good thing you taught me now before we had any serious consequences | 11:45 |
| lkcl | if you want to have a go at fixing that it's easily done, insn = PO = 5 | 11:45 |
| octavius | sure | 11:45 |
| lkcl | really, a list of dependencies is needed (in graphical form) | 11:45 |
| lkcl | somehow | 11:46 |
| ghostmansd[m] | lkcl, but we have both eq and ne. | 11:46 |
| ghostmansd[m] | Why invent ne == ~eq? | 11:46 |
| lkcl | ghostmansd[m], yes. hence ~sm=CRfieldbit is not... exactly | 11:46 |
| lkcl | and saying (in your head), "negated eq" is... meh | 11:47 |
| ghostmansd[m] | Aaaah I got what you mean | 11:47 |
| ghostmansd[m] | You're talking of how it looks to anyone familiar with English | 11:47 |
| lkcl | yes. reading it out in their head | 11:48 |
| ghostmansd[m] | You know what? Let me check how it goes with expression tree. | 11:48 |
| ghostmansd[m] | Perhaps it goes better than I expect. | 11:48 |
| ghostmansd[m] | (actually I really think it will go smoothly enough) | 11:48 |
| octavius | Added the insn init, ran test and passed (both 0 and 1) | 11:48 |
| * lkcl learned a couple of years ago that programmers use the same foreign language centres for understanding | 11:48 | |
| octavius | " foreign language centres" ? | 11:48 |
| lkcl | octavius, fantastic, then that's good enough / clearance to commit it. | 11:48 |
| lkcl | french, english, spanish, greek, serbo-croat, mandarin | 11:49 |
| lkcl | anything-not-native-tongue | 11:49 |
| octavius | Ah, you meant in you brain | 11:49 |
| lkcl | your brain uses the exact same centres for processing *computer* languages | 11:49 |
| octavius | I thought you talked about 'centres' as in institutions or buildings | 11:50 |
| ghostmansd[m] | Yes, because, after all, it's still a language | 11:50 |
| ghostmansd[m] | And we all know these are for people not computers | 11:50 |
| ghostmansd[m] | (unless we have someone here who speaks in 0 and 1) | 11:50 |
| octavius | Da net naverno ;D (yes no maybe) | 11:51 |
| ghostmansd[m] | Well that's ternary logic | 11:52 |
| ghostmansd[m] | Should've been placed this way: net naverno da | 11:52 |
| ghostmansd[m] | Or - 0 + | 11:52 |
| octavius | Nah, I meant that it's a valid phrase (essentially no) | 11:53 |
| ghostmansd[m] | Ah I guess it'd be difficult to translate it | 11:53 |
| ghostmansd[m] | I mean, "yes no maybe" doesn't explain it :-) | 11:53 |
| octavius | Probably not | 11:54 |
| lkcl | that's called "covering your bases" :) | 11:54 |
| octavius | :P | 11:54 |
| lkcl | i heard a story about someone who did a Cambridge Entrance Exam | 11:54 |
| lkcl | 3 hours to write an essay on the topic "Is this a question?" | 11:55 |
| lkcl | they first wrote: | 11:55 |
| lkcl | yes | 11:55 |
| lkcl | then after half an hour, crossed it out and wrote: | 11:55 |
| lkcl | no | 11:55 |
| lkcl | after another hour, they crossed that out and wrote: | 11:55 |
| lkcl | maybe | 11:55 |
| lkcl | they got a Distinction and an acceptance letter. | 11:56 |
| octavius | XD | 11:58 |
| ghostmansd[m] | lkcl, yes, I think what we want is doable; I guess this will constitute some special machine-dependent operand type, but this is even better. | 12:12 |
| markos | ghostmansd[m], ok, so *finally* I can resume actual work on svp64, so how do I build binutils with svp64 support? is it upstream already? | 12:13 |
| lkcl | markos, yay! | 12:15 |
| lkcl | this should do it | 12:16 |
| lkcl | https://git.libre-soc.org/?p=dev-env-setup.git;a=blob;f=binutils-gdb-install;hb=HEAD | 12:16 |
| markos | lkcl, sorry it has taken so long | 12:16 |
| lkcl | bear in mind, ghostmansd[m] is literally working on field-support right now for things like the "sm=r3" part of "sv.addi/sm=r3" | 12:17 |
| lkcl | hey no problem | 12:17 |
| ghostmansd[m] | Actually the current version resides in a different branch, svp64-ng. | 12:18 |
| ghostmansd[m] | But at this point I think I might as well move it to svp64 branch. This svp64-ng is a heavy refactoring, and also has macros support. | 12:19 |
| ghostmansd[m] | markos, I'll sync the branch | 12:19 |
| lkcl | Veera[m], looks really good | 12:21 |
| ghostmansd[m] | markos, I've overridden the legacy svp64 branch with the current state of art; I'll continue tuning macros and prefix stuff on svp64-ng. | 12:21 |
| ghostmansd | markos, please also check this commit c58f3e556d4b7271ec90a1fb26ec47fd84aae376 | 12:22 |
| markos | ok | 12:22 |
| ghostmansd | It shows some updates we did to assembly recently | 12:22 |
| ghostmansd | And binutils follow this notation (we'll also do, but later) | 12:23 |
| Veera[m] | lkcl: I am thinking of working on bug #883 - add cvc5 and bitwuzla to hdl-yosys-tools | 13:07 |
| Veera[m] | lkcl: After that I wanted to submit RFPs | 13:07 |
| lkcl | Veera[m], yes good idea, then do all R... yes :) | 13:07 |
| lkcl | do make the installs in /usr/local, which is the default. no need to set PREFIX= | 13:08 |
| lkcl | and especially no need to set prefix=/usr/local/somewhere_non_standard | 13:08 |
| lkcl | it means having to explicitly add to $PATH which is getting inconvenient | 13:08 |
| Veera[m] | lkcl: One question: Did DDR3 64x16 Mb worked on ECP5 Versa Dev Board | 13:08 |
| Veera[m] | lkcl: OKay | 13:09 |
| lkcl | last time i checked, yes | 13:09 |
| lkcl | my board would only run at 55 mhz though. the manufacturing tolerances on the DRAM ICs are *between* 48 and 55 mhz | 13:09 |
| Veera[m] | ECP5 Versa Dev Board: What is the price? 85K version | 13:10 |
| lkcl | there is no 85k version | 13:10 |
| lkcl | raptor engineering got a one-off ultra-expensive custom board | 13:10 |
| Veera[m] | digikey shows one with price around $100. I was not sure so asked! | 13:11 |
| lkcl | you're probably thinking of this | 13:12 |
| lkcl | https://www.digikey.co.uk/en/products/detail/lattice-semiconductor-corporation/LFE5UM5G-85F-EVN/9553907 | 13:12 |
| lkcl | which is *not* a VERSA_ECP5, it's a bare-bones evaluation board with pretty much one IC on it: the ECP5-85K FPGA | 13:12 |
| Veera[m] | Not. https://www.digikey.in/en/product-highlight/l/lattice/ecp5-versa-evaluation-board | 13:14 |
| lkcl | that's a top-level product listing page. | 13:14 |
| lkcl | theLFE5UM-45F-VERSA is only a 45k LUT4. | 13:14 |
| Veera[m] | Sorry. I missed the meaning. | 13:15 |
| Veera[m] | Aside. Did Orangecrab ecp5 84k lut worked with memory? | 13:16 |
| lkcl | apparently it works in other systems. | 13:16 |
| Veera[m] | mean other verilog code | 13:17 |
| lkcl | yes | 13:17 |
| Veera[m] | For versa it is in docs that it works upto 800Mbps mode. And for SDRAM 133MHz the lowest limit is around 50Mhz. | 13:19 |
| lkcl | DRAM ICs have manufacturing tolerances. | 13:20 |
| lkcl | the data sheet for the MT64k(something) says "100mhz" | 13:20 |
| Veera[m] | What the doc for Versa's says about its DDR3 lower limit of frequency? | 13:20 |
| lkcl | in reality, as low as 48-55 mhz works | 13:20 |
| lkcl | nothing. | 13:20 |
| lkcl | it's not their responsibility. | 13:20 |
| markos | ok, fyi, trying git clone in the schroot fails with libcurl3-gnutls from backports, it gives 'Failed sending HTTP request' | 14:54 |
| markos | after some search, I found out that you need to downgrade to latest from stable and pin it there, ie 7.64.0-4+deb10u2 | 14:55 |
| markos | backports version is 7.74.0-1.2~bpo10+1 | 14:55 |
| markos | or in other words, how to spend half your day cloning a git repo | 14:56 |
| markos | https://stackoverflow.com/questions/65556397/git-clone-always-fails-with-failed-sending-http-request | 14:58 |
| ghostmansd | lkcl, https://bugs.libre-soc.org/show_bug.cgi?id=849#c20 | 15:32 |
| ghostmansd | TL;DR: macros _are_ difficult. It's funny that we stuck on modes, but it seems that this revealed an issue in vanilla PPC (or not, if they choose not to support stuff like ".set REG, %r0" at all). | 15:33 |
| ghostmansd | Anyway, we're almost here, I think. Once we can use registers in macros, we're really close to stuff like 1<<%r3. | 15:34 |
| ghostmansd | I'll need Alan's advice on this, though. | 15:34 |
| markos | ghostmansd, ok, binutils built, how to test svp64 compilation? | 16:07 |
| markos | assembler rather | 16:08 |
| markos | I mean what's the compilation flags used? | 16:17 |
| lkcl | markos, that's a pain. i've added the voodoo magic incantation to install-hdl-apt-reqs | 16:32 |
| lkcl | ghostmansd, ah 1<<%r3 is not needed. that's too much. | 16:33 |
| lkcl | markos, "powerpc64le-linux-gnu-as file.s -o file.o" will do it. | 16:34 |
| markos | so, what works and would I need to change? | 16:36 |
| lkcl | pysvp64asm absolute basic use of ".set something regnum" works | 16:37 |
| lkcl | like this https://git.libre-soc.org/?p=openpower-isa.git;a=blob;f=media/audio/mp3/mp3_0_apply_window_float_basicsv.s;hb=HEAD | 16:38 |
| lkcl | 26 # SV floats | 16:38 |
| lkcl | 27 .set fv0, 32 | 16:38 |
| lkcl | 75 sv.fmuls *fv0, *fv0, *fv1 | 16:38 |
| lkcl | beyond that i recommend the trick of taking a c version, compiling to assembler, and hand-editing | 16:40 |
| lkcl | gcc -s c_version.c -o converted_to_assembler.s -mnovsx -mnoaltivec | 16:41 |
| lkcl | something like that | 16:41 |
| markos | I think it may have not picked up the right branch, cause it gives me 'unrecognized opcode' errors for sv.* instructions in this file | 16:41 |
| markos | it's svp64 branch right? | 16:41 |
| markos | $ powerpc64le-linux-gnu-as -v | 16:41 |
| markos | GNU assembler version 2.39.50 (powerpc64le-linux-gnu) using BFD version (GNU Binutils) 2.39.50.20220711 | 16:42 |
| markos | is this correct? | 16:42 |
| markos | it's running natigve on a power9 system/vm if that helps | 16:42 |
| ghostmansd[m] | markos, you need -mlibresoc flag | 16:53 |
| ghostmansd[m] | powerpc64le-linux-gnu-as -mlibresoc asm.s -o asm.o | 16:54 |
| ghostmansd[m] | >> ghostmansd, ah 1<<%r3 is not needed. that's too much. | 16:54 |
| ghostmansd[m] | lkcl, we've already discussed it, this is how PPC assembly works: you need to either use %, or always pass -mregnames | 16:55 |
| ghostmansd[m] | So you can use 1<<r3 but no sooner than you pass -mregnames. | 16:56 |
| ghostmansd[m] | In some contexts, you can omit r, e.g. in instruction operands. | 16:56 |
| ghostmansd[m] | But I doubt it's doable on macro level. Moreover, what would 1<<3 mean to anyone? Hardly a register. | 16:57 |
| markos | still unrecognized opcodes, maybe I missed something | 16:57 |
| ghostmansd[m] | So yeah, either 1<<%r3, or -mregnames and 1<<r3. | 16:57 |
| markos | a50e2deae0dcfca57cd95abee416ed4e8d87d175 last commit, looks ok | 16:57 |
| markos | maybe the configure cmd needs something extra? | 16:58 |
| ghostmansd[m] | Markos, afk. What exactly do you try to compile and how? | 16:59 |
| markos | powerpc64le-linux-gnu-as -mlibresoc mp3_0_apply_window_float_basicsv.s | 16:59 |
| markos | mp3_0_apply_window_float_basicsv.s: Assembler messages: | 17:00 |
| markos | mp3_0_apply_window_float_basicsv.s:56: Error: unrecognized opcode: `setvl' | 17:00 |
| markos | etc | 17:00 |
| markos | checked if I'm running the right as and I am | 17:00 |
| ghostmansd[m] | Please show the top commit | 17:07 |
| ghostmansd[m] | Does -mlibresoc work? | 17:07 |
| ghostmansd[m] | Aaahh | 17:07 |
| ghostmansd[m] | Yeah | 17:07 |
| markos | it seems so | 17:07 |
| ghostmansd[m] | Crap | 17:08 |
| ghostmansd[m] | Open this file | 17:08 |
| ghostmansd[m] | And set .machine to libresoc | 17:08 |
| markos | ah cool | 17:08 |
| ghostmansd[m] | Does it work now? | 17:09 |
| markos | yup | 17:09 |
| ghostmansd[m] | It should :-) | 17:09 |
| ghostmansd[m] | Awesome :-) | 17:09 |
| markos | ok, now compiling my own code | 17:09 |
| markos | uncommented the sv.* instructions | 17:09 |
| markos | as expected, I get syntax errors :) | 17:09 |
| markos | setvl 0,0,18,0,1,1 # Set VL to 18 elements | 17:10 |
| markos | # Load 18 floats from (in) | 17:10 |
| markos | sv.lfs 8.v, 0(5) | 17:10 |
| markos | mp3_1_imdct36_float.s:70: Error: syntax error; found `.', expected `,' | 17:10 |
| markos | mp3_1_imdct36_float.s:70: Error: junk at end of line: `.v,0(5)' | 17:10 |
| markos | so I guess it doesn't like the offset | 17:10 |
| markos | or the .v annotation? | 17:11 |
| markos | I see it has changed in the other file | 17:11 |
| markos | it's now * | 17:11 |
| markos | what's the /els for? | 17:12 |
| markos | yup * worked | 17:12 |
| ghostmansd[m] | markos, sorry, I'm driving now :-) I'll help you later | 17:20 |
| ghostmansd[m] | I see you found a new convention already :-) | 17:20 |
| markos | it's ok, I'll do some tests | 17:21 |
| markos | thanks a lot for your work | 17:21 |
| markos | it's a game changer | 17:21 |
| markos | do we by any chance have an instruction to load a float constant immediate ? | 17:30 |
| markos | also, another question, but does "pointer" arithmetic work eg. sv.adds *fvs+1, *fvs+1, *fvs | 17:38 |
| ghostmansd[m] | Hm, not sure, I haven't checked it. | 17:53 |
| ghostmansd[m] | What do you expect from it? | 17:53 |
| ghostmansd[m] | What is fvs, for example? | 17:53 |
| ghostmansd[m] | How it works is: 1) we find whether * is present and if so remember that this is vector; 2) we parse the operand into vanilla PPC expression; 3) afterwards, if it was a vector, we tune it appropriately. | 17:55 |
| ghostmansd[m] | Other than that, we do nothing IIRC. | 18:03 |
| ghostmansd[m] | So, we record the fact that it was a vector, and simply store this fact into some structure associated with the expression. | 18:04 |
| ghostmansd[m] | On the other hand, there might be some stuff to be updated. For example, I have yet to check the routine which takes care of optimization. | 18:07 |
| lkcl | markos, *fvs+1 would be "the register number from the macro fvs, plus one" | 18:22 |
| lkcl | so if you had | 18:23 |
| lkcl | .set fvs 12 | 18:23 |
| lkcl | then *fvs+1 i would expect to become *13 | 18:23 |
| ghostmansd[m] | Yep, mine impression too | 18:23 |
| lkcl | that's if the expression logic works at all, reducing down to numbers | 18:24 |
| ghostmansd[m] | It likely does, yeah | 18:24 |
| ghostmansd[m] | I mean, if it worked before me, it still should :-) | 18:24 |
| ghostmansd[m] | Because this part I haven't touched | 18:24 |
| lkcl | markos, fmvis i haven't implemented in the simulator yet, if you wanted to have a go at it yourself i can walk you through the process | 18:26 |
| lkcl | (and justify some budget for doing so) | 18:26 |
| lkcl | markos, if you can do the two instructions fmvis and its other half i can justify a budget of EUR 2000 (i'll need some to help you out) under this https://bugs.libre-soc.org/show_bug.cgi?id=234 | 18:29 |
| lkcl | aaand i thiiink... DX-Form i already added.... soo... https://libre-soc.org/openpower/sv/int_fp_mv/#fmvis | 18:30 |
| lkcl | the pseudocode's already in that page... | 18:30 |
| lkcl | and there's two patches here which show how it's done https://bugs.libre-soc.org/show_bug.cgi?id=234#c1 | 18:31 |
| ghostmansd[m] | > Should I put it on the review on mailing list, or it's a bit early yet? | 18:35 |
| ghostmansd[m] | lkcl, ^^^ we forgot about it | 18:35 |
| lkcl | don't worry about it | 18:35 |
| lkcl | markos: /els means "element-strided" | 18:36 |
| lkcl | https://libre-soc.org/openpower/sv/ldst/ | 18:36 |
| lkcl | element strided (sequential but regularly offset, with gaps) | 18:37 |
| lkcl | have a look at the pseudo-code for op_load | 18:37 |
| lkcl | # element stride mode | 18:37 |
| lkcl | srcbase = ireg[RA] | 18:37 |
| lkcl | offs = i * immed | 18:37 |
| lkcl | this is something unique to Vector ISAs | 18:37 |
| markos | lkcl, I will check this out, it doesn' | 19:08 |
| markos | +doesn't look like something too advanced for my level | 19:08 |
| markos | reg. the *fvs+1, yes, that's exactly what I would expect it to be | 19:09 |
| markos | ie: | 19:09 |
| markos | # equivalent to: for (i = 17; i >= 1; i--) in[i] += in[i-1]; | 19:09 |
| markos | sv.fadds/mrr *vin+1, *vin+1, *vin | 19:09 |
| lkcl | wow and that actually makes sense, too | 19:37 |
| lkcl | that one is "map-reduce, reverse-gear" | 19:40 |
| lkcl | it's actually a complete misnomer, "mapreduce" | 19:40 |
| lkcl | you actually want the reverse-gear mode but "/mrr" is the easiest way to get it | 19:41 |
| markos | well, it already worked before | 19:41 |
| markos | but with absolute register numbers | 19:42 |
| markos | now it's more intuitive I think | 19:42 |
| markos | and plenty more like that in the code | 19:42 |
| lkcl | the way mapreduce works btw is that it relaxes the conditions of terminating the looping if the result is a scalar | 19:46 |
| lkcl | mapreduce *keeps going* | 19:46 |
| lkcl | therefore it's up to you to use it with a scalar-source-equal-to-destination | 19:46 |
| lkcl | to give the *appearance* of a mapreduce | 19:46 |
| lkcl | but in this case it's being used entirely with vector-source and vector-dest | 19:47 |
| lkcl | but | 19:47 |
| lkcl | there's no other easy way to enable reverse-loop (VL-1..0 rather than 0..VL-1) | 19:47 |
| markos | is fmvis supposed to take hex constants only? I mean is the fp -> int conversion supposed to happen in the assembler? or should I handle fp constants as well? | 19:54 |
| markos | ie fmvis f4, 0x40000000 vs fmvis f4, 2.0f | 19:54 |
| lkcl | markos, for now yes. | 20:06 |
| lkcl | as this is an entirely new instruction it's down to us to *define* what it takes | 20:07 |
| lkcl | but none of the sv/trans/svp64.py infrastructure copes with fp numbers and likely not hex or binary either | 20:07 |
| ghostmansd[m] | Well, svp64.py can't, but binutils can. | 21:08 |
| ghostmansd[m] | I mean f prefix. | 21:09 |
| ghostmansd[m] | As for constants, I haven't checked it yet, but this is doable, if not present yet. | 21:11 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!