| *** alMalsamo is now known as lumberjackimok | 04:26 | |
| *** lumberjackimok is now known as lumberjackok | 04:26 | |
| ghostmansd[m] | Hi folks. Long time no news. | 07:59 |
|---|---|---|
| ghostmansd[m] | How are you? | 07:59 |
| programmerjake | We're currently working on getting Libre-SOC to work on a FPGA for NGI POINTER's objectives. I'm supposed to get in the mail tomorrow an Orange Crab with the 85k LUT variant of the ECP5...thanks to Libre-SOC's FPGA fund, funded by generous donor(s). Thanks! | 08:08 |
| ghostmansd[m] | Good! Nice to hear. | 08:09 |
| ghostmansd[m] | I've continued a bit on binutils yesterday, not that much progress, but at least something. | 08:11 |
| ghostmansd[m] | Currently my chances to work are really sporadic, considering the amount of regular work and overall events in the world. | 08:12 |
| ghostmansd[m] | But still I hope to finish binutils task, anyway | 08:13 |
| programmerjake | Also, idk if you heard, Luke (and friends) has become the official maintainer of nmigen, granted a trademark licence to the nmigen trademark by the legal owner. | 08:15 |
| programmerjake | (or something like that) | 08:15 |
| programmerjake | https://gitlab.com/nmigen | 08:16 |
| programmerjake | thx for your work on binutils! | 08:17 |
| programmerjake | hopefully stuff will calm down soon, would rather not end up with WWIII | 08:18 |
| programmerjake | well...ttyl, it's after midnight here | 08:21 |
| ghostmansd[m] | Yeah, I saw nmigen news. This is really cool. | 09:01 |
| lkcl | ghostmansd[m], nice to hear from you | 09:26 |
| lkcl | programmerjake, and Toshaan Bharvani, as well, the Technical Chair of the OpenPOWER Foundation, is also the authorised co-maintainer | 09:26 |
| lkcl | Trademark Law has similar "fall-back-defaults" to Copyright Law, in the absence of a License. | 09:27 |
| lkcl | under Copyright Law, if there is no License (such as BSD, GPL etc.) every single person has to follow the excruciating legal path of seeking permission to use, permission to modify, permission to display, permission to distribute etc. etc. etc. etc. | 09:28 |
| lkcl | what most people are *not* aware of is that Trademark Law is *exactly the same*! | 09:28 |
| lkcl | even if there's a Copyrighted Open Source license with a legitimate Copyright License (GPL, BSD), if that Copyrighted work uses a Trademarked word | 09:30 |
| lkcl | such as: | 09:30 |
| lkcl | * Debian | 09:30 |
| lkcl | * Redhat | 09:30 |
| lkcl | * Linux | 09:30 |
| lkcl | * git | 09:30 |
| lkcl | * Mozilla Firefox | 09:30 |
| lkcl | * Mozilla Thunderbird | 09:30 |
| lkcl | you *have* to seek and obtain the explicit permission to at the bare minimum "distribute" anything containing the Trademarked word if you want to operate stably and legally | 09:33 |
| lkcl | if you don't seek and obtain that License, the Trademark Holder can issue you with a Cease and Desist notice, and once that happens they can get a Court Order to enforce it if you do not comply | 09:34 |
| lkcl | and if they ask you to terminate all use retrospectively, you have to delete absolutely everything using that word! | 09:34 |
| lkcl | it would utterly, utterly devastate the Libre-SOC Project to have to remove *from the entire archives and git history* all mention of "nmigen"! | 09:35 |
| lkcl | the crucial thing is: having received the Trademark License, the Trademark Holder *cannot* ask us to do that [retrospectively remove the word "nmigen" from all archives and git commits] | 09:36 |
| lkcl | the only thing they could do is: revoke the License then ask us not to use it any further. and i negotiated a 90 day period so if we really really screw up that badly, we've got 90 days to do a cleanup | 09:37 |
| lkcl | (a proper fork with "we can't tell you what the name is of what we are now using") | 09:38 |
| lkcl | Trademarks have been used in the past by Free Software Projects to protect a Brand / Reputation | 09:45 |
| lkcl | * Mozilla enforced their Trademark against Debian, forcing them to find an alternative name: they picked iceweasel, icedove etc. | 09:46 |
| lkcl | * Debian enforced their Trademark against Christian Marillat, who was distributing nonfree (and often patent-infringing) versions of debian packages via http://debian-multimedia.org | 09:46 |
| lkcl | * Redhat *routinely* puts the hammer down on anyone distributing "free" versions of RHEL packages | 09:47 |
| lkcl | which is why Centos is called "Centos", not "Redhat-free-community-maintained-version" | 09:48 |
| lkcl | all of which was extremely disruptive for the projects involved, and *all of them were using Free Software*! | 09:53 |
| lkcl | just because you use - or contributed - to a Copyrighted Free Software work - does *not* grant you any permissions, overrides or authority over a Trademark | 09:55 |
| ghostmansd[m] | So we have a fork of nmigen which should not be called nmigen? | 10:00 |
| lkcl | ghostmansd[m], no. we *don't* have to do that, because we've a License to use nmigen from the Trademark Holder | 10:03 |
| lkcl | but | 10:03 |
| lkcl | if that is ever revoked, we would have 90 days in which to do such a fork | 10:03 |
| lkcl | and we also *wouldn't* have the extremely disruptive task of doing a massive git revision rewrite | 10:04 |
| lkcl | it would still be a pain in the ass but less of a pain in the ass | 10:05 |
| lkcl | btw ghostmansd[m], markos is going to do the video assembler (hooray) | 10:07 |
| ghostmansd[m] | Whoa, cool | 10:07 |
| lkcl | he'll be able to use the hacked-together-python-rewriter which turns "sv.xxx" into ".long NNNNN; xxx" temporarily | 10:07 |
| ghostmansd[m] | You did a lot while I've been out :-) | 10:08 |
| lkcl | but it will give you some assembler listings to actually try putting through binutils-svp64 | 10:08 |
| lkcl | :) | 10:08 |
| lkcl | deep breath: i'm going to have to do an icarus verilog simulation of ls2 with the gram DDR3 controller | 13:21 |
| lkcl | there's a stand-alone simulation which i managed to get working (after fixing the Clock-Reset-Generator) | 13:22 |
| lkcl | https://git.libre-soc.org/?p=gram.git;a=tree;f=gram/simulation;hb=HEAD | 13:22 |
| lkcl | but that sends direct commands over wishbone | 13:23 |
| lkcl | icarus verilog has to be used because the Micron-provided DDR3 verilog simulation is timing-sensitive | 13:24 |
| lkcl | https://git.libre-soc.org/?p=gram.git;a=tree;f=gram/simulation/dram_model;hb=HEAD | 13:24 |
| ghostmansd | I again have some issues with mkpinmux when I set things up via hdl-dev-repos-virtualenv script | 14:11 |
| ghostmansd | https://pastebin.com/z4GJJhhn | 14:11 |
| ghostmansd | Anyone familiar with this error? | 14:11 |
| lkcl | use an earlier version | 14:34 |
| lkcl | back to this commit should do it | 14:35 |
| lkcl | https://git.libre-soc.org/?p=pinmux.git;a=commit;h=d96f737c0a53dde983060522816bbef016b449ce | 14:35 |
| lkcl | we converted the test example that andrey was working on to multi-bank pinouts but haven't yet had time to go back and fix ls180 to accept the new multi-bank format | 14:37 |
| lkcl | commit d96f737c0a53dde983060522816bbef016b449ce | 14:43 |
| lkcl | yep, that one | 14:43 |
| lkcl | oo, interesting - icarus verilog, because it is entirely timing-driven, has thrown up a situation with the icache SRAMs, which are combinatorial | 15:27 |
| ghostmansd | lkcl: thanks, checkouting the mentioned revision helps! | 15:57 |
| ghostmansd | OK, yet another error upon "test_issuer.py nosvp64": https://pastebin.com/4GLegcec | 16:10 |
| ghostmansd | it seems like each and every time I re-establish the environment the process hardly goes smoothly :-) | 16:11 |
| ghostmansd | perhaps I need to do it more often | 16:11 |
| ghostmansd | I did some changes to openpower.consts I'd like to check, so I had to launch test_issuer; I can reproduce this issue on master, though | 16:11 |
| ghostmansd | lkcl: gotcha! $(git show 09baeded9726414aa79cf01da5dd8b71984dd5b4) | 16:28 |
| lkcl | ghostmansd, i added a unit test to branch that might not work | 17:00 |
| lkcl | the immediate is out of range | 17:00 |
| lkcl | ignore it :) | 17:00 |
| lkcl | ghostmansd, ah, do a git pull on openpower-isa | 17:01 |
| lkcl | you're not up-to-date | 17:02 |
| lkcl | more to the point, sigh, i hadn't done a git push. have now https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=55dfbec9191382d2cdbb729de910c60ed1d1b745 | 17:02 |
| lkcl | sorry about that :) | 17:09 |
| ghostmansd | ehm, that's basically just disabling it, amirite? | 17:31 |
| lkcl | ghostmansd, correct | 17:31 |
| ghostmansd | ok then :-) | 17:31 |
| ghostmansd | that's what I did | 17:31 |
| ghostmansd | (not this way, I simply cut some lines) | 17:31 |
| lkcl | i needed a quick test | 17:32 |
| ghostmansd | still not here though: https://pastebin.com/CXaPr6Rp | 17:32 |
| ghostmansd | I'm launching $(python3 src/soc/fu/compunits/test/test_branch_compunit.py) | 17:32 |
| octavius | Happy belated birthday tplaten! | 17:32 |
| ghostmansd | all of nmigen, nmigen-soc and nmigen-boards are updated via $(git pull origin master --rebase) | 17:33 |
| lkcl | ghostmansd, if you can, use fu/branch/test/test_pipe_caller.py instead | 17:35 |
| lkcl | it does the same thing as test_branch_compunit.py but puts a Function Unit wrapper around it | 17:36 |
| ghostmansd | ah OK | 17:36 |
| ghostmansd | I'm on talos1, so I guess it's possible | 17:37 |
| ghostmansd | what's the best way to check all tests? | 17:38 |
| lkcl | i'm currently focussing on FPGAs and running via verilator and icarus verilog | 17:38 |
| lkcl | test_issuer.py | 17:38 |
| lkcl | for now | 17:38 |
| ghostmansd | ok, got it | 17:38 |
| lkcl | python3 test_issuer.py nosvp64 | 17:38 |
| ghostmansd | nosvp64 still? | 17:38 |
| ghostmansd | aha, brilliant | 17:38 |
| ghostmansd | thanks | 17:38 |
| lkcl | basically the ordering is: | 17:38 |
| lkcl | * compunits with individual unit tests | 17:38 |
| lkcl | * test_pipe_callers with exactly the same unit tests but a Function Unit wrapper around the CompUnits | 17:39 |
| lkcl | * test_core.py which is missing a fetch unit (hilariously it cheats by using the Simulator to tell it what PC and instruction to use) | 17:39 |
| lkcl | * test_issuer.py | 17:39 |
| ghostmansd | ok, thanks! | 17:40 |
| lkcl | they go up and up and up and up, adding more functionality at each layer | 17:40 |
| ghostmansd | and now for something completely different | 17:57 |
| ghostmansd | https://pastebin.com/kGRBHes2 | 17:57 |
| ghostmansd | this time it seems XLEN is broken and is of Mock type instead of int | 17:58 |
| lkcl | ghostmansd, sigh, yep, an experiment i added yesterday | 17:58 |
| lkcl | yep i know because it's being passed a PSpec which has not had pspec.XLEN=64 added to it | 17:59 |
| lkcl | PSpec derives from unittest mock | 17:59 |
| lkcl | 1 sec | 17:59 |
| lkcl | ghostmansd, should do the trick https://git.libre-soc.org/?p=openpower-isa.git;a=commitdiff;h=efd99092d29ff546a4b48999630c277028f3af73 | 18:00 |
| lkcl | running now | 18:00 |
| lkcl | yep all good | 18:00 |
| ghostmansd | OK thing's running now :-) | 18:05 |
| ghostmansd | hopefully it'll pass now | 18:05 |
| lkcl | goood, sorry about that. embarrassingly, you're the only other person in about 3-4 weeks to run any of the unit tests. | 18:05 |
| lkcl | huhn, that's a new one. icarus verilog is putting the TestIssuer exec_fsm value as "x" | 18:07 |
| lkcl | oink | 18:07 |
| lkcl | after running for about 100 instructions successfully | 18:08 |
| lkcl | ahh i think i know how. uart_tx was undefined | 18:09 |
| lkcl | and it propagated through | 18:09 |
| lkcl | after trying to access the wishbone bus connected to the uart. | 18:09 |
| lkcl | ha. | 18:09 |
| lkcl | that's actually really smart | 18:09 |
| lkcl | and annoying | 18:14 |
| lkcl | wishbone 16550 has tx_o as "z" | 18:14 |
| lkcl | grr | 18:14 |
| ghostmansd | > goood, sorry about that. embarrassingly, you're the only other person in about 3-4 weeks to run any of the unit tests | 18:32 |
| ghostmansd | lol, glad to be useful | 18:32 |
| ghostmansd | now there's bunch of assertion errors at openpower-isa/src/openpower/test/state.py:126 | 18:33 |
| lkcl | i only ran alu and that worked | 18:34 |
| lkcl | i haven't run all of them | 18:34 |
| ghostmansd | and there at lines 87 and 106 | 18:34 |
| ghostmansd | and 100 | 18:35 |
| lkcl | oh wait that's memory. which given it's running an L1 cache by default now maaay not produce the right answer | 18:35 |
| lkcl | btw you know you're running the HDL, here, not the ISACaller simulator, right? | 18:36 |
| lkcl | or, you're running ISACaller-against-the-HDL-for-comparing-answers | 18:36 |
| lkcl | hmmm a module buried inside uart16550 is being deleted for some reason by yosys passes | 18:45 |
| ghostmansd | > btw you know you're running the HDL, here, not the ISACaller simulator, right? | 18:59 |
| ghostmansd | well I recall that there are tests which use HDL and which use ISACaller, but the fact that we now have it buried in runner.py is nice | 19:00 |
| ghostmansd | I guess that's a recent addition, right? | 19:00 |
| lkcl | nope :) | 19:00 |
| ghostmansd | or at least I missed how it worked | 19:00 |
| lkcl | been there ooo about... 18+ months? :) | 19:01 |
| ghostmansd | lol | 19:01 |
| ghostmansd | well, given how fast things change now, 18+ months is extremely old, almost as if dating Cicero's times lol | 19:02 |
| lkcl | i'm currently in "delivery" mode, which is very boring | 19:03 |
| lkcl | deliverable: FPGA | 19:03 |
| lkcl | ooo annoying | 19:05 |
| lkcl | yosys is deleting uart_transmitter and uart_receiver from deep inside a structure | 19:05 |
| lkcl | because it deems them to be "unnecessary" | 19:06 |
| programmerjake | hmm, do they have any externally visible outputs (if not, yosys probably is justified in deleting them)? or are they being flattened into the parent modules? try marking their outputs with the `keep` attribute | 19:11 |
| lkcl | no flattening | 19:15 |
| lkcl | ah ha! | 19:15 |
| lkcl | okaay that seems to have done it | 19:20 |
| lkcl | dang | 19:20 |
| lkcl | let's try that as a setattr command | 19:23 |
| programmerjake | for stuff I should be working on, should I try and add XLEN=32 tests? currently XLEN=32 is entirely untested against the simulator, I know for a fact there are some discrepancies | 19:24 |
| lkcl | programmerjake, at some point yes, | 19:24 |
| lkcl | but with XLEN=16 and 8 as well | 19:24 |
| lkcl | it's a damn big job | 19:25 |
| lkcl | where ISACaller needs to be done first, realistically | 19:25 |
| lkcl | otherwise how the heck are we going to know the answers are correct? | 19:25 |
| programmerjake | XLEN=16/8 has the major problem that load/store addresses aren't really sufficient so that will need extra work | 19:26 |
| lkcl | yes you saw the message i wrote this morning about that | 19:26 |
| programmerjake | yeah, i don't necessarily like that solution though...it sounds like a mess | 19:27 |
| lkcl | alternatives are even worse. "special registers" | 19:27 |
| lkcl | special LD/ST registers | 19:27 |
| lkcl | SPRs | 19:27 |
| lkcl | it starts to massively deviate from the Power ISA and ultimately cost a fortune in compiler modifications | 19:28 |
| programmerjake | imho XLEN=16 should just have 16-bit addresses and just limit it to microcontrollers, XLEN=8 shouldn't be a whole cpu, there's just not enough address bits and I think we should limit its use to sv width overrides | 19:29 |
| lkcl | that's not useful in the context of running general-purpose programs. | 19:29 |
| programmerjake | where with sv the addresses are still 64/32/16-bit (depending on whole-cpu XLEN) | 19:30 |
| lkcl | and if you look at 8-bit microcontrollers they are in no way limited to only addressing 256 bytes of RAM | 19:30 |
| lkcl | ALU width != Memory width | 19:30 |
| programmerjake | which part isn't useful? | 19:30 |
| lkcl | forcing ALU width === Memory width is not in the least bit useful | 19:31 |
| lkcl | expecting a 4096-core AI chip to only be possible to address 256 bytes of memory will be laughed at | 19:32 |
| lkcl | there do exist such processors - a scalar one that costs below $0.10 is the STM8003 | 19:33 |
| lkcl | but even that has "advanced" (higher cost) versions that can address 512 bytes | 19:33 |
| programmerjake | i strongly disagree...keeping max alu width == memory address width retains the simplicity of the instruction set. expecting a 4096 core AI chip to only have 8-bit arithmetic is also a joke, you need fast address calculations, so at least 32-bit arithmetic | 19:33 |
| lkcl | programmerjake, you're again waving different criteria around and moving the goalposts again. it's a very annoying habit | 19:35 |
| programmerjake | well...i'm pointing out the inherent flaws in your goalposts and suggesting imho more useful goals | 19:35 |
| programmerjake | if you have sv-based carry chains that *is* larger arithmetic, so setting XLEN to a tiny value just makes the ISA more complex for no real benefit. you can always have a 32/64-bit cpu that processes most arithmetic 8-bits at a time | 19:38 |
| lkcl | i'm currently focussed on delivery, for the contracts. i can spare a *small* amount of time to discuss other things | 19:39 |
| lkcl | however i cannot spare the time if it becomes a major distraction | 19:39 |
| programmerjake | imho the main usecase for tiny XLEN is tiny microcontrollers, not AI. AI would use XLEN=32 and let sv width override to 8 for AI arith | 19:39 |
| lkcl | i have to focus, and you should be as well | 19:39 |
| lkcl | ahh good, those attributes did the trick | 19:41 |
| programmerjake | yeah...so put off XLEN=32 tests for later? or work on that rn? | 19:41 |
| lkcl | thank you | 19:41 |
| programmerjake | :) | 19:41 |
| lkcl | it was an experiment to see if there was a way to reduce FPGA resources | 19:41 |
| lkcl | to help the OpenPOWER Foundation Members (particularly LibreBMC) out of a bind | 19:42 |
| lkcl | and | 19:42 |
| lkcl | also | 19:42 |
| lkcl | to tie in with IBM's interest - and the IBM India Education Groups's interest - in AI | 19:42 |
| programmerjake | ah...i thought it was cuz you were having issues with the ecp5 85k | 19:43 |
| programmerjake | and AI | 19:43 |
| lkcl | i tied it in with a whole stack of other things in order to help justify external interest, strategically | 19:43 |
| programmerjake | in any case, should I work on that now? or something else? | 19:44 |
| lkcl | no, skip it for now | 19:44 |
| lkcl | it needs the simulator, ISACaller, to support XLEN, first | 19:44 |
| programmerjake | that seems relatively easy to add...just add an external parameter for now | 19:45 |
| programmerjake | support sv later | 19:45 |
| lkcl | it's not: the register file is specifically designed around 64-bit SelectableInts | 19:46 |
| lkcl | exxcellent, i'm getting DDR3-simulated-traces in icarus verilog | 19:47 |
| programmerjake | yay! | 19:48 |
| lkcl | by comparing the reactions to the "vanilla" (wishbone-driven-without-a-CPU) version i can see what the hell's going on | 19:48 |
| programmerjake | well, what should I work on next? i'll be getting the fpga sometime tonight | 19:53 |
| * lkcl thinks thinks | 19:53 | |
| lkcl | ah brilliant | 19:53 |
| lkcl | probably pick another bitmanip instruction? | 19:53 |
| programmerjake | k | 19:54 |
| lkcl | i tried reaching out to the nym folk after one of them responded well at an NGI meeting | 19:54 |
| lkcl | but haven't heard from them since | 19:54 |
| lkcl | Mirko's tried to re-introduce us to get some engagement, still no reply | 19:55 |
| programmerjake | i was thinking of the AES S-BOX instructions...though modular inverse could be *extremely* slow (why AES uses a look-up table) | 19:55 |
| lkcl | which is weird, because we need algorithms to test hardware on, and they expressed an interest in having hardware that they could test algorithms | 19:56 |
| programmerjake | or, i could look through whatever else we'd want for sha3 to be fast | 19:56 |
| programmerjake | sha3 has no s-box, it's just bitmanip | 19:56 |
| lkcl | interesting | 19:56 |
| lkcl | can you raise a bugreport about it, and find a *really* simple reference implementation? (don't write one) | 19:57 |
| programmerjake | which one? | 19:57 |
| lkcl | there should be one in or associated with the academic papers on it | 19:58 |
| lkcl | sha3 | 19:58 |
| programmerjake | sha3? | 19:58 |
| programmerjake | ah, ok | 19:58 |
| lkcl | one of the really really irritatingly-annoying things about what we're doing is that we actually want "totally-suboptimal-like-totally-unuseable-for-everybody-else scalar algorithms" | 19:59 |
| lkcl | i think it took me like 3 weeks and looking at dozens of papers to find a "human readable" version of DCT | 20:00 |
| lkcl | (i eventually found project nayuki) | 20:00 |
| lkcl | but even there had to spend 2 weeks adapting it from recursive to iterative | 20:00 |
| lkcl | everyone else goes, "oh that scalar algorithm is totally s*** you REALY want to like use these totally fast SIMD instructions and do loop unrolling and s***" | 20:01 |
| * lkcl bangs head against the desk | 20:01 | |
| lkcl | the most awe-inspiringly-scary one i came across was a compiler that blatted out fully-loop-unrolled SIMD assembler for large FFTs | 20:05 |
| lkcl | my personal favourite one, jacob, is to do NTT (Number Theory Transform) | 20:06 |
| lkcl | which is basically Discrete Fourier Transform with Galois Field arithmetic | 20:06 |
| lkcl | that's the core basis of highly optimal algorithms for Reed Solomon | 20:07 |
| * lkcl going to let icarus run for another half hour | 20:08 | |
| lkcl | it's horrendously slow but hey | 20:08 |
| programmerjake | found the de-facto standard Rust implementation of SHA3's sponge function (the main core of SHA3) | 20:10 |
| programmerjake | https://github.com/RustCrypto/sponges/blob/master/keccak/src/lib.rs | 20:10 |
| programmerjake | it's pretty readable imho | 20:11 |
| programmerjake | afaict ternlog is the only instruction we needed that would speed up sha3 without being sha3-specific...so, mission accomplished? | 20:16 |
| lkcl | programmerjake, that's frickin hilarious :) | 20:21 |
| lkcl | ah - and an implementation without external modules. | 20:22 |
| lkcl | that's another pain-in-the-ass thing about implementations | 20:22 |
| lkcl | they're not standalone | 20:22 |
| lkcl | academic papers and cryptographic authors know to not #include anything at all | 20:23 |
| lkcl | (sole exception stdio.h) | 20:23 |
| lkcl | "mod unroll" | 20:23 |
| lkcl | can you find a c reference implementation? | 20:24 |
| lkcl | oh btw, also, can you adapt comment 0 on the cryptoprimitives Schedule A to put the full URL of the bugreports in it? | 20:24 |
| lkcl | like in #175 | 20:24 |
| lkcl | then email the text cut/paste to Michiel? | 20:25 |
| programmerjake | unroll: https://github.com/RustCrypto/sponges/blob/master/keccak/src/unroll.rs | 20:25 |
| lkcl | yes exactly: it's a module. | 20:25 |
| lkcl | this is a "No" as a Reference Implementation | 20:25 |
| lkcl | the reason i asked if you can find a c implementation is because it can be converted to assembler with "gcc -S" and then used as the basis to do a svp64 version | 20:26 |
| * lkcl thinking out loud here | 20:26 | |
| programmerjake | you can easily do that with rust too... | 20:26 |
| * lkcl also has to check sausages | 20:26 | |
| programmerjake | a rust module is much closer to a C++ namespace than a C source file...in rust everything in a crate (a collection of modules) is compiled together as the equivalent of 1 c source file | 20:28 |
| programmerjake | i can get rustc to spit out an inlined version, where everything is in 1 file | 20:28 |
| lkcl | no, please. no rust. | 20:28 |
| lkcl | no. | 20:28 |
| lkcl | that makes an entire rust compiler an extra dependency for the openpower-isa repo where the media assembler lives | 20:29 |
| lkcl | no | 20:29 |
| lkcl | we've talked about this multiple times | 20:29 |
| programmerjake | we can check in the .s file if you like? it would need to be manually edited to add in ternlog instructions anyway | 20:30 |
| lkcl | look at how the media directory is set up in the openpower-isa rep | 20:30 |
| programmerjake | so, imho no matter which way we go, we'd want the .s checked in cuz ternlog isn't in any compilers yet | 20:31 |
| lkcl | yes. | 20:31 |
| lkcl | again | 20:31 |
| lkcl | look at how the media subdirectory is set up. | 20:31 |
| lkcl | you will find two versions. | 20:31 |
| lkcl | 1) the original scalar ppc64 version | 20:32 |
| lkcl | 2) an svp64 version | 20:32 |
| lkcl | this is where some c-based reference designs can be found | 20:33 |
| lkcl | https://keccak.team/software.html | 20:33 |
| lkcl | the tiny one looks like a good candidate | 20:33 |
| lkcl | https://github.com/mjosaarinen/tiny_sha3/blob/master/sha3.c | 20:34 |
| lkcl | that's pretty blindingly obvious | 20:34 |
| programmerjake | exactly as obvious as the rust implementation... | 20:37 |
| programmerjake | also they have the sorta equivalent of rust modules: #include "sha3.h" | 20:38 |
| programmerjake | also the RustCrypto repos are audited for correctness iirc, the tiny_sha3 repo seems less likely to be audited | 20:41 |
| programmerjake | > oh btw, also, can you adapt comment 0 on the cryptoprimitives Schedule A to put the full URL of the bugreports in it? | 21:08 |
| programmerjake | i thought i already did that... | 21:09 |
| programmerjake | https://bugs.libre-soc.org/show_bug.cgi?id=589 right? | 21:09 |
| programmerjake | so i just need to email the contents of comment #0 to michiel? or can I just email him the link? | 21:10 |
| programmerjake | lkcl ^ | 21:11 |
| programmerjake | btw toshywoshy, openpowerbot disconnected from oftc | 21:18 |
| lkcl | programmerjake, brilliant, yes - do email Michiel. | 21:49 |
| programmerjake | sent. (as you probably can see, i cc-ed you) | 22:05 |
| lkcl | ghostmansd, very funny on the python enums :) | 22:11 |
| ghostmansd | well, I've spent a day and a half trying to make metaclass work with inheritance from enum.EnumMeta | 22:12 |
| lkcl | ooo noiiice | 22:12 |
| ghostmansd | and in the end I'm really pissed with the rationale that they don't allow inheritance | 22:13 |
| lkcl | ehn?? que?? | 22:13 |
| ghostmansd | unless you inherit from really basic stuff, like enum.Enum | 22:13 |
| ghostmansd | i.e. you're basically allowed to inherit it _once_ | 22:13 |
| ghostmansd | well, I _made_ it work | 22:13 |
| ghostmansd | ...only to find that it breaks in Python 3.9 | 22:14 |
| lkcl | 20 years working with python and i don't frickin understand a single one of these https://www.programcreek.com/python/example/81530/enum.EnumMeta | 22:14 |
| ghostmansd | a day and a half to realize that it's easier to re-create enum from scratch than really inherit existing | 22:14 |
| ghostmansd | I mean, what the fuck? We had bunch of enums in power_enums, I also converted a bit of code in openpower.consts | 22:15 |
| ghostmansd | what'd be simpler than inheriting those, right? | 22:15 |
| lkcl | uh-huhn. makes sense to me | 22:15 |
| ghostmansd | but the crap simply doesn't work; what's worse, it doesn't work differently across different python versions | 22:16 |
| lkcl | feel free to do exactly that btw | 22:16 |
| ghostmansd | really, really pissed | 22:16 |
| ghostmansd | any hack I tried so far is doomed | 22:16 |
| ghostmansd | so I iterate over Enum.__members__ since it's documented, and re-create enum with all its values | 22:17 |
| ghostmansd | I haven't pushed it yet; waiting for test_issuer to complete | 22:17 |
| ghostmansd | binutils part is pushed, though | 22:17 |
| lkcl | excellent | 22:17 |
| ghostmansd | as for test_issuer, I have many failures; I want to ensure I have these on master as well | 22:18 |
| lkcl | no if you think it's worth replacing Enum then absolutely go for it | 22:18 |
| ghostmansd | yep, because this allows to deal with consts.XXX exactly like we deal with power_enums.YYY | 22:18 |
| ghostmansd | I found that we have some code in svp64.py | 22:18 |
| ghostmansd | like (bc_vlset << SVP64MODE.MOD2_LSB) | 22:19 |
| ghostmansd | and so on | 22:19 |
| ghostmansd | and, well, I also have do this stuff in binutils :-) | 22:19 |
| ghostmansd | I still haven't looked into new mnemonics | 22:20 |
| ghostmansd | i.e. bc_brc and bc_vli are not present in svp64.py | 22:21 |
| ghostmansd | bc_svstep is there, but it's always zero | 22:21 |
| ghostmansd | that's what I mean: https://bugs.libre-soc.org/show_bug.cgi?id=550#c50 | 22:22 |
| ghostmansd | anyway. it's 1:22 AM here | 22:22 |
| ghostmansd | so enough for today :-) | 22:22 |
| lkcl | :) | 22:23 |
| ghostmansd | OK it seems the failures are the same on master | 22:32 |
| ghostmansd | I'm pushing the changes | 22:32 |
| ghostmansd | Done; please let me know if this breaks anything. It shouldn't (the change I'm worried is Enum migration, which should be harmless), but I cannot say for sure, since I see about 100 tests failing in test_issuer and is unable to check whether some fail differently with my patch. | 22:35 |
| lkcl | ghostmansd, star. yeah will take a look soon, trying to focus on FPGAs | 23:36 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!