| lkcl | yay the ls180 litex peripherals + core compiled in coriolis2 | 00:46 |
|---|---|---|
| * lkcl waves to dcz_ | 10:26 | |
| dcz_ | hi lkcl | 10:26 |
| dcz | I wanted to say "hi" but I dropped out instead | 10:33 |
| lkcl | doh, been there. we have the irc bot logs for catching up if you miss things | 10:33 |
| lkcl | you asked, "Does that mean the CPU has multiple ALUs that will get used in vector mode but unlikely to see full utilization in scalar mode? | 10:34 |
| lkcl | I haven't found a diagram showing the issue width of a core yet." | 10:34 |
| *** lkcl changes topic to "https://libre-soc.org/irclog/" | 10:34 | |
| lkcl | it depends on the width of the instruction multi-issue phase | 10:35 |
| lkcl | so if the instruction multi-issue phase width is say 2, then we expect to be able to issue either 2 scalar or 2 VL-augmented instructions | 10:35 |
| lkcl | the VL-augmented instructions will be "expanded" by the special Simple-V hardware-for-loop | 10:36 |
| lkcl | and analysed for their element width to see if they can be SIMD-i-fied | 10:36 |
| lkcl | but if they are still 64-bit, they'll be thrown into the ALUs *as if* they were much wider multi-issue scalar operations | 10:37 |
| cesar[m]1 | Maybe something like hyperthreading could help ALU utilization in the case of a CPU-type workload, where you have multiple unrelated scalar threads for different processes. | 10:40 |
| dcz | did I understand it correctly, that each ALU is able to do multiple operations per cycle if the unit width is <64bit? | 10:40 |
| lkcl | cesar[m]1: perhaps, maybe that will be something to add in future, it's big enough to request its own NLNet Grant | 12:48 |
| lkcl | dcz: currently all ALUs are 64 bit scalar because we are aiming for OpenPowerISA compliance as a baseline | 12:49 |
| lkcl | however | 12:49 |
| lkcl | what we are then going to do is, using python OO techniques, *replace* the nmigen Signal() class with a specially-designed "PartitionedSignal" class | 12:50 |
| lkcl | this will *dynamically* allow, with a "context" that threads its way through every single PartitionedSignal, the ALU to be *dynamically* reconfigured | 12:51 |
| lkcl | 1x 64-bit op | 12:51 |
| lkcl | 2x 32-bit ops | 12:51 |
| lkcl | 4x 16-bit ops | 12:51 |
| lkcl | 8x 16-bit ops | 12:51 |
| lkcl | actually it will be possible to do a mixture, say 1x 24-bit plus 2x 16 plus 3x 8-bit | 12:52 |
| lkcl | the beginnings of that are here | 12:53 |
| lkcl | https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part/partsig.py;hb=HEAD | 12:53 |
| lkcl | and you can see it's just "python operator overloads __add__, __or__, __eq__" etc. | 12:53 |
| lkcl | otherwise it would be Absolute Hell to do SIMD. | 12:54 |
| lkcl | one line of code | 12:54 |
| lkcl | comb += x.eq(a + b) | 12:54 |
| lkcl | would become | 12:54 |
| lkcl | if(SIMD_SPLIT == 8-bit) | 12:55 |
| lkcl | for i in range(8): | 12:55 |
| lkcl | comb += x[i].eq(a[i] + b[i]) | 12:55 |
| lkcl | elif | 12:55 |
| lkcl | elif | 12:55 |
| lkcl | elif | 12:55 |
| lkcl | and that's just one line! | 12:55 |
| lkcl | can you imagine how insanely unreadable that would become? | 12:55 |
| lkcl | instead we use python OO, and that if/elif/elif is *DYNAMICALLY* hidden behind the __add__ function. | 12:56 |
| * dcz looks | 13:20 | |
| dcz | I more or less see the idea | 13:32 |
| dcz | the magic is in PartitionedScalarShift and friends | 13:32 |
| lkcl | yes, very much so | 13:48 |
| lkcl | and also PartitionedMux | 13:48 |
| lkcl | which you can use to do a sort-of "if" statement | 13:48 |
| lkcl | comb += PartitionedMux(boolean_decider, iftruesignal, iffalsesignal) | 13:49 |
| lkcl | just like nmigen.Mux | 13:49 |
| lkcl | exactly like it - except with a "dynamic partitioned context" | 13:49 |
| lkcl | https://git.libre-soc.org/?p=ieee754fpu.git;a=blob;f=src/ieee754/part_mux/part_mux.py;hb=HEAD | 13:50 |
| lkcl | with these primitives it *should* be possible to do something similar to nmigen "with m.If()" and "with m.Else()" | 13:50 |
| sorear | if OPF is (a) allowing you to do arbitrary non-standard extensions (b) refusing to give standard blessing to anything you do until it has been blessed by enough vendors, isn't that essentially the same as what RVF was doing? | 16:29 |
| lkcl | sorear: the differences are twofold. first is that OPF has been willing to listen, where RVF flat-out was not (in direct violation of Trademark Law) | 19:20 |
| lkcl | second is that "Custom Extensions" are nowhere near adequate. | 19:20 |
| lkcl | RV Custom Extensions are very, *very* specifically for non-upstream, non-public, isolated and one-off use | 19:21 |
| lkcl | which i agree 100% with that that's what they should be for. under NO circumstance should binutils, gcc or the linux kernel accept upstream mainstream patches for anything that uses custom RV or custom OpenPOWER opcodes | 19:22 |
| lkcl | with that possibility being eliminated, the *only* remaining option is to seek "official approval" | 19:23 |
| lkcl | to work *with* the other stakeholders, to add clear, clean and well-defined extensions to the *official* ISA | 19:24 |
| lkcl | and for those to be very specifically designed and defined in an ISA non-disruptive way (behind a "namespace" - also known in OpenPOWER is as "Program Compatibility Register") | 19:25 |
| lkcl | and that's where RVF violated Trademark Law by systematically refusing to respond to in-good-faith requests to participate in an *open* fashion | 19:26 |
| lkcl | because if we participated in secretive closed Working Groups it would make it clear that we were not in the slightest bit serious about our Business Objectives (full transparency) | 19:27 |
| sorear | have you ever tried to get intel to respond to a good faith request to do anything in an open fashion | 19:28 |
| * lkcl snorts :) | 19:28 | |
| lkcl | they're not proposing to open up the ISA, are they? | 19:28 |
| lkcl | if they did, as an already CISC ISA that'd be hilarious. | 19:29 |
| sorear | anyway the rvf got rid of the nda years ago | 19:29 |
| lkcl | not the sections that prevented us from signing as Members of the RVF | 19:31 |
| lkcl | and it bound us to unacceptable levels of secrecy | 19:32 |
| lkcl | full transparency, accountability and independent auditability has to mean what it says otherwise this entire venture is ash | 19:33 |
| lkcl | if we signed NDAs or any secrecy agreements NLnet would be quite justified in saying that we're no longer working for the public good | 19:34 |
| lkcl | and could withdraw our funding! | 19:34 |
| lkcl | that has actually happened to some projects | 19:34 |
| lkcl | they got into trouble by signing commercial agreements that handed over the copyright, and the new "owners" decided to no longer release modifications under libre licenses | 19:48 |
| lkcl | as the work that were doing was no longer meeting NLnet's Foundation Charter requirements ("works in the public good"), they had no choice but to stop funding them | 19:49 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!