log☇︎
62200+ entries in 0.036s
asciilifeform: nao, this being said, my objective is still to give acceptably-performing, re erryday ops, ffa ~without asm~. but asmism will make a serious diff re e.g. key generation, make minutes instead of day+.
asciilifeform: ( scroll to the bloody leg illustration )
ave1: http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#33_13, this is the egyptian mul?
asciilifeform: ( there is also the fact that such a simple thing as addition with carry takes not 1 ADD instruction, but an entire http://www.loper-os.org/pub/ffa/hypertext/ch11/word_ops__adb.htm#36_13 orchestra )
asciilifeform: the other is that on iron such as certain ARM ( i have not yet investigated ~which~ ) , and ppc, and certain others, there does not even exist a constant-time MUL, and one is stuck with some variant of http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#33_13 -- which really begs to be asmed, is riotously inefficient
asciilifeform: when i started ffa, i did not plan to bake any asm speedups at all. but there's 2 reasons to do it, eventually : one is that on e.g. x86/x64, getting the upper half of a word-sized multiplication, without asm, takes ~four~ MULs plus a buncha additions : http://www.loper-os.org/pub/ffa/hypertext/ch11/w_mul__adb.htm#95_14 ☟︎
ave1: I'll see if I can patch gcc and add an extra constraint to the asm statement
asciilifeform: i suspect it'll result in tighter coad, tho, in principle
ave1: yes, but then you'll have to do stack gymnastics etc
asciilifeform: i.e. same thing i did with the C routines
asciilifeform: well there is also a 'put all asmism in a standalone .S and feed it to the linker' , for completeness
ave1: unfortunately the asm instruction has a limited version of the pinning
ave1: in GNAT ther is one way: the asm instruction
asciilifeform: ( but eventually i do want to write e.g., asmtronic MUL, for arm64 ffa )
ave1: In C there are 2 ways: (a) in the asm instruction, (b) in the register variable definition
asciilifeform: i can't speak for other folx, but i dun expect to need this particularly soon, so there is time to unravel the puzzler
ave1: To be clear, the register pinning is in gcc
ave1: I've looked into the "constraints" code support in GCC (for x64), but I'm still in the spaghetti phase
asciilifeform: ave1: see if you can find what is the coad in gnat that exists on x64 but not arm64, re register pinning
asciilifeform: in the particular example of udp, a coupla extra MOV's won't make a diff speedwise (vs the latency of the nic) but this sorta thing will be ugly once we start writing kernel mods in ada / moving off unix entirely
ave1: syscalls only have one outgoing parameter, the errorcode (all other outs are through pointers)
ave1: I use it now for the recvfrom / sendto calls for x86_64
ave1: to get the first argument into the x0 registers
ave1: then in the inline assembly code, you do something like: mov %0, %%x0 ☟︎
ave1: In the inline assembly you specify that the variable can be in a global (constraint == "g")
ave1: first work around is to have a bunch of mov instructions before the syscall
asciilifeform: it'll have to be fixed.
asciilifeform: ave1: depending on just how sad gcc turns out to be, may have to put the asm in a separate linkable .o and invoke it as if it were c lib
ave1: in C you can specify the register for a variable at definition time
ave1: arm has a lot more registers, but no constraints for these
asciilifeform: right, how can even have inline asmism without this
ave1: this variable needs to be in the aex register etc
asciilifeform: ( if broken, will have to be fixed, wtf )
asciilifeform: ave1: do you mean that inline asm is actually broken on arm64 gnat ? or simply not found how to make it go
ave1: asciilifeform, diana_coman: I'm now looking into arm 64bit, but so far seems to be bit more involved. I've not found a way to directly couple an ada varable to a register.
a111: Logged on 2018-11-13 05:14 deedbot: http://barksinthewind.com/2018/splitting-the-primary-and-the-sub-key-in-a-gnupg-keychain/ << BARKS IN THE WIND - Splitting the primary and the sub key in a gnupg keychain
asciilifeform: http://btcbase.org/log/2018-11-13#1871703 << also neato, i expect this'll come in handy when we start extracting moduli / migrating off gpg ☝︎
a111: Logged on 2018-11-13 09:00 mircea_popescu: made me think of odessa.
asciilifeform: ave1: this is neat
diana_coman: ave1, nice! I'll add it to my list to give it a spin
diana_coman: as the lithuanian-estonian-russian said "they've always been great, what!"
diana_coman: hey, old riga sprats are great here too!
mircea_popescu: phf impressive dance you got there.
mircea_popescu: made me think of odessa. ☟︎
mircea_popescu: and in other news, got a shipment of sprats. old riga, including pronouncements as to how kosher they are, in hebrew on the side.
diana_coman: fwiw I actually patched v.pl to use phf's vtools and it works absolutely fine; I guess I'll write-it up and publish the whole thing later today if nobody else does it ☟︎☟︎
deedbot: http://barksinthewind.com/2018/splitting-the-primary-and-the-sub-key-in-a-gnupg-keychain/ << BARKS IN THE WIND - Splitting the primary and the sub key in a gnupg keychain ☟︎
lobbes btw is finding esthlos' summaries to be very helpful in finding threads at times
deedbot: http://blog.lobbesblog.com/2018/11/conveyor-outlook-now-to-feb-2019/ << lobbesblog - Conveyor Outlook: Now to Feb 2019
asciilifeform: it's exactly an africa, complete with tsetse fly.
asciilifeform: mircea_popescu: entire unixlike ecosystem has never afaik been anyffing other than africa.
asciilifeform: that's yet a third derp, whoever wrote python-gnupg
mircea_popescu: asciilifeform hence the "made in america" comment. the america of africa, as much an america as any other america rite.
mircea_popescu: what, specifically, is the tag supposed to convey ? cuz it sure as fuck doesn't seem to be "we'll randomly change abis because why the fuck not, windowns power!"
asciilifeform: i'll be happy to see'em sitting on neighbouring stakes tho
asciilifeform: mircea_popescu: stallman has plenty to answer for, but i dunno what he has to do specifically with koch's gpg
asciilifeform: mircea_popescu: funnily enuff happens to be exactly what asciilifeform's doing
mircea_popescu: we gotta get rid of this whole "subkey" bs and kock-shitsandwich bs along with it.
phf: asciilifeform: well post your gnupg.py and i will at the very least look at the diff between the two. maybe their subkey strategy has changed
asciilifeform: ( i need specifically both vtrons to work on these boxen , with no systemwide modifications )
phf: i have to excuse myself midway through conversation, but will chime in later
asciilifeform: but gotta find a pill, cuz right nao wheels turning in the mud
mircea_popescu: if it were a case of "phf why the fuck are you using non-v or non-tmsr or non-standard or non-something" it'd have legs. as it is it's "phf why didn't you intuit what's in the magic box under my bed" ?
asciilifeform: still remains to be seen
mircea_popescu: asciilifeform you seriously can't go after people who happen to not share your ~unpublished~ personal pre-chain.
asciilifeform: seems like the closest thing to a working keccak-vtron currently is phf's v98 tho
phf: i've narrated how to make v.pl work with keccak, i think i even posted an unsigned patch for mod6, butman is busy
asciilifeform: i was able to regrind ffa today, using phf's vdiff, but atm cannot yet press and confirm that it actually presses to same thing as the classical
asciilifeform: phf: fwiw my orig v.py is pretty sad in several wellknown ways -- i'm not particularly attached to it, would happily take mod6's, if there were (did i miss??) a ver of it patched to work in keccak
phf: that's accidental. most people have been running mod6's v.pl, they also might've pulled the dependency back when v.py came out, of various __version__'s closer to the one you have, but not necessarily exact. i think your attachment to your code clouds your judgment!
asciilifeform: with all respect to phf -- it seems to me that he's the one with the nonstandard envir
asciilifeform: really, nobody ? why is it that nobody until phf's v98 felt inclined to change the routine, then ?
phf: asciilifeform: i'm surprised at this entirely un-vtronic argument. your "10kb proggy" brings in a magic dependency, that nobody else has except for you
asciilifeform: i will not be answerable for a 3GB ball of shit, there aint even 1% of the necessary hrs to read it, left in my lifespan
asciilifeform: it's nonsense tho.
asciilifeform: by that token it's 3GB cuz that's how much stripped gentoo weighs, lol
phf: "i have a copy of gnupg that works, and everyone that's using anything else is an idiot" is not much a strategy
asciilifeform: phf: i dun want to glom python-gnupg into vtron tho!
phf: asciilifeform: you can also calm the fuck down, and post your version of gnupg, version 0.3.2, unsigned is fine, and we can figure out what the issue is. i'll look at the diff and see if 0.3.2 can be added to v.py as another file
asciilifeform: i can't think of anyffing to do but a) make flensed version of phf's that actually worx here, i have NO intention of breaking my legacy toolchain in which i still have 90000 unconverted private patches or b) bake an e.g. if gpg.__version__ = phf : ... else .... thing
phf: asciilifeform: because that routine doesn't work with version 0.4.1, it only picks up primary keys
asciilifeform: phf: can you plz remind me why you changed that routine to begin with ?
asciilifeform: my orig worked with 0.3.2 ( which is poured into cement and i have no intention to 'upgrade' wtf lol )
phf: well, time to vpatch gnupg.py
asciilifeform went to strace to find what gpg binary it actually invokes, and oddly enuff no mentions of EITHER in strace output...
asciilifeform: so apparently gpg2ism is not the culprit
asciilifeform: phf: worx -- in the sense that no above eggog : but same result as previously, http://p.bvulpes.com/pastes/wmR7H/?raw=true
mircea_popescu: asciilifeform no but how do you call it ? import gnupg ? and then gpg = ?
phf: asciilifeform: try gpgbinary
asciilifeform: it always baked a tmp to satisfy gpg's keyring idjicy and nuked it after
mircea_popescu: there's also a homedir for the keyring
asciilifeform goes to try mircea_popescu's tip
asciilifeform: loox like i'ma have to strip out the subkey garbage, and regenesis, 'v98-that-actually-worx'. unless phf has better idea.
phf: well, that's a useful conversation.
asciilifeform: and yes it was originally my kludge. but the diff is, mine worked...
asciilifeform: and imho it is pretty sad that a vtron even sees ~anything~ 'systemwide'.
asciilifeform: phf: well that aint what i have here.
phf: asciilifeform: everything i test, i test on Linux gravity 4.4.138-1-ARCH #1 SMP PREEMPT Tue Jun 26 21:26:35 MDT 2018 aarch64 GNU/Linux, which is a press of your rk pre-cuntoo
phf: asciilifeform: all the other kids do it!
asciilifeform: phf: it will be even gnarlier, would have to parse the output somehow and essentially recreate all of python-gnupg ( wanna ? )