asciilifeform: ( it is certainly indexed in the place where it lives -- http://www.loper-os.org/pub/ffa/hypertext/ch13/fz_basic__adb.htm#72_13 -- but for some reason not in ffa_calc__adb... )

asciilifeform: ( e.g. in above example -- FFA_FZ_Get_Head is not linkable, and several hrs of dig failed to tell me why )

asciilifeform: still mighty useful. ( presently i'm continuing with the http://www.loper-os.org/pub/ffa/hypertext/ch13/ffa_calc__adb.htm thing, to fill that niche )

asciilifeform: pehbot is simply a wrapper around compiled ffa_calc , currently it gives closest possible picture to what you get if you ran the proggy itself locally.

asciilifeform: !Q later tell phf plox to snarf http://www.loper-os.org/?p=2822 into http://btcbase.org/patches?patchset=ffa , ty ☟︎☟︎

asciilifeform: mircea_popescu: now you know what half of ffa illustration sweat loox like !

asciilifeform: diana_coman et al: http://ossasepia.com/2018/11/24/proposed-change-to-w_borrow-ffa/comment-page-1/#comment-4500

asciilifeform: !Q later tell phf plox to snarf http://www.loper-os.org/?p=2798 into http://btcbase.org/patches?patchset=ffa , ty

asciilifeform: this is the reason why asciilifeform is saving the optional asm subroutines in ffa for ~dead last~ ( per http://www.loper-os.org/?p=2735 proclamation ) rather than given in beginning of series

asciilifeform: i've added all kindsa 'new api' in ffa, but the only regrind was when we took up new hash type for vtrons

asciilifeform: http://btcbase.org/log/2018-11-18#1873480 << this is entirely ok, diana_coman , there is not a burning hurry ( tho i expect that anybody who intends on firing ffa on battlefield will first take the time to properly eat it ) ☝︎

asciilifeform: ( e.g. ffa genesis, is very small, but contained all of the basic fundamental moving parts for simple arithm )

asciilifeform: unrelatedly, ave1 , diana_coman , mircea_popescu , phf , other folx with a gnat and 10min of free time -- asciilifeform would like to see outputs of http://www.loper-os.org/pub/ffa/thousand_muls.txt ( ch12 benchmark ) on various irons ☟︎

asciilifeform presently massaging ffa ch12, expects to take most of today

asciilifeform: ffa/p-tron as a dos boot disk would imho rock.

asciilifeform: ( i deliberately wrote ffa in such a way that it oughta work on under 32bit or even plain 16, supposing somehow enuff ram )

asciilifeform: it is on hold pending resolution of http://btcbase.org/log/2018-10-26#1866266 ( and is taking back seat to ffa currently ) ☝︎☟︎☟︎☟︎

asciilifeform: btw i was going through my ffa notebooks and found a margin note that was actually about this, that prolly oughta go in the l0gz : if yer 'pow' is a walk-through-storage, 1 problem is that initial state of the system gives too little material to walk. so 1 interesting answer might be to include a 'ballast', consisting of, say, the first 9 yrs of classical btc blox, 1...N, that is part of the luby'd set (as raw bytes, rather than as m

asciilifeform actually ran 2 printers into the ground since started ffa

asciilifeform: ( no algo in ffa is newer than 1988 or so )

asciilifeform: mircea_popescu: kinda what ffa is

asciilifeform: i wish i could concur, but while baking ffa i had to eat a good 100GB of pdf.

asciilifeform: mod6: have you considered to get a diff heathen gig ? the kind where you dun have to go anywhere ? in '16 asciilifeform pulled this off, yes it took having to run on batteries for a spell, but was 100% worth it, it's the only reason i had strength to actually do FG, ffa, etc

asciilifeform: i was hoping to avoid baking hashing into ffa/p , but loox like it isn't escapable if we're doing oaep

asciilifeform: i think just his bigendian vs littlendian speshulcases (why he has any?! ffa doesn't..! ) weigh moar than all of ffa together

asciilifeform: i'd like to be able to put a link in the 'ffa regrind' article, 'and you can press it with ~this~'

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: ( 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 ☟︎

asciilifeform: ( but eventually i do want to write e.g., asmtronic MUL, for arm64 ffa )

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 in the process of keccakizing ffa, hence practical q

asciilifeform: when i have the choice, i'd rather write proggy to need no such cassettes ( observe, streams are not used in ffa )

asciilifeform: mircea_popescu: after ffa/p beta rollout, i'ma be at yer service for the next thing ( fg2? tmsr.mips ? radio ? or other, take yer pick )

asciilifeform: ( i got one coming in a week or so, tho, for ffa exhaustive tests )

asciilifeform: ^ mircea_popescu , diana_coman , other potential ffa eaters ^

asciilifeform finally finished rereading ffa, nao preparing ch12 + estimate of just-how-long-to-battlefield promised earlier

asciilifeform: phf: i prolly won't get a chance to actually put it to use in near term, hands pretty full with ffa; but would like to have it. if it's there to be had.

asciilifeform: ( it's not ~completely~ fucktarded, all of ffa is still reachable via http://www.loper-os.org/pub/ffa/hypertext/ch11/ffa__ads.htm . but still frustrating )

asciilifeform: phf: it's definitely not perfect, e.g. why the FUCK is FFA_FZ_ZeroP not clickable ?

asciilifeform: phf: the default view ( http://www.loper-os.org/pub/ffa/hypertext/ch11/ ) of gnathtml gives you a frames thing with ~worthless alphabetic index in the left pane. really it oughta show 'where currently clicked symbol used' imho

asciilifeform: 3) -l1 turns on line numbering; -I adds paths to the libraryisms ; -p takes a file containing src_dir=. gpr_file=ffa_calc.gpr .

asciilifeform: 2) cd ffa/ffacalc ; gnathtml.pl -l1 -f -D -I obj -I ../libffa -I ../libffa/obj -p ffa_calc.adp ffa_calc.adb

asciilifeform: mod6: rereading own ffa , from opening shot to 11

asciilifeform: fwiw i've massaged ffa to the point where it's fully static and the problem dun affect it any. but some of my other stuff (mmap) is hobbled by it.

asciilifeform: current ffa relies on the user/caller to wipe

asciilifeform: ( it's not a wholly useless thing, i dun have it in current ffa but my 1st draft used it to wipe all data on the stack erry time it goes out of scope )

asciilifeform: bvt: which gnat are you using ? i've never observed any such thing ( and i use the same restriction, http://btcbase.org/patches/ffa_ch11_tuning_and_api/tree/ffa/libffa/restrict.adc#L76 , ~with~ sequential i/o, http://btcbase.org/patches/ffa_ch11_tuning_and_api/tree/ffa/ffacalc/ffa_rng.adb#L49 )

asciilifeform re-rotates desk to ffa pile ☟︎

asciilifeform: there is no particular reason why ~erry~ proggy has to have the same pragma fascism as ffa ( and in fact i've written several that cannot function under that set of constraints, e.g. the mmap thing requires System.Address )

asciilifeform: implicit conditionals aint evil per se , tho ; i banned them in ffa specifically as they get in the way of constanttimeism, is all ☟︎

asciilifeform: diana_coman: out of curiosity -- given what mircea_popescu said the other day re necessary speed of rsa ops, could potentially use the current (11) ffa ?

asciilifeform: the funny/sad bit is that this is ALREADY in gnat, for e.g. http://btcbase.org/patches/ffa_ch8_randomism#L132 , but ~not exposed~ ! to user

asciilifeform: bvt: i have a variant of this in ffa, and yet another subset in mmap

asciilifeform: i have 1 presently ( switched off, will move it to pizarro in near fyootoor ) , talks to ffa

asciilifeform: i illustrated this in ffa

asciilifeform: ave1: use the method illustrated in w_mux, http://btcbase.org/patches/ffa_ch1_genesis#L870

asciilifeform: ave1: you dun need ffa for this, yer dividing single words by single word

asciilifeform: http://btcbase.org/log/2018-10-04#1857985 << financials -- none; conveyor -- tmsr.udp ; ffa to resume once i wrap up keccakizing ☝︎

asciilifeform: e.g. i can put out ch12 of ffa on keccak.

asciilifeform: http://btcbase.org/patches/ffa_ch11_tuning_and_api/tree/ffa/libffa/fz_io.adb#L59 << example of endian-insensitive routine.

asciilifeform: http://btcbase.org/log/2018-09-14#1850327 >> they are, see e.g. http://btcbase.org/patches/ffa_ch4_ffacalc#L43 example ☝︎