tmsr - Log 2019-03-10

asciilifeform: bvt: the only new instrs that seem to be even theoretically of use, are 'mulx' and 'adcx' -- but i dun have any iron that supports these atm, and cannot even begin to say whether constant time etc

asciilifeform: http://www.loper-os.org/pub/amd64_mulx.jpg << amd seems to support ~currently~, but dun say from what date of chip specifically

asciilifeform: fwiw it's still a 64bit mul, the only win is that it dun set any flags (and therefore keeps the pipe flowing)

asciilifeform: ftr asciilifeform suspects that 99% of what can be won from asmism in ffa, can be had simply from bvt's existing 64bit mul, plus doing adc for the additions-with-carry instead of the manually-cranked carry calc, and that all 'fancy' instructions will only lead to sad

asciilifeform meanwhile found today mistake in 17 , and expects it'll take several days to rewrite

asciilifeform: and meanwhile2, we have answr to above quandary, 'In 2017, BMI2 was further incorporated in AMD's Zen-architecture...'

asciilifeform: ... so 'mulx' aint in anyffing i have. if someone wants to test it with own hands, he can, otherwise fughetit.

asciilifeform: ftr an 'iron ffa' cpu does not even require a massive multiplier . even a microcoded ffa-style thing that lets you specify 'and at memory x there is a w-word int, and at y a w word int, add'em' etc , would still massively win over the extant liquishit, it would do the arithm atomically, without invoking branchpredictor, losing cache, etc.

asciilifeform: ( 'you want fast crypto, plebe? here, buy nsa-certified(tm)(r) cryptoaccelerator card from ibm' )

asciilifeform: remember, only a terrorist(tm)(r) 'writes own crypto', 'good citizens use openssl' etc etc

mircea_popescu: http://btcbase.org/log/2019-03-09#1901062 << very much this. "oh, couldn't POSSIBLY spare another bus width for a FULL mult result. NEVERTHELESS... can fucking spare eight trillion bus widths to specify instruction length. it's 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000101 and not a mere fucking 0000000000000000000000000000000000000000000000000 ☝︎

a111: Logged on 2019-03-09 22:38 asciilifeform: if you ever wonder why your x64 iron draws 50x the wattage to do same thing as e.g. rk, wonder no longer -- the insanity where shit gets moved around to accomodate idjit instructions with fixed in/out hoppers, the insanity where you gotta set prefixes to specify what width ~each operand~ is (why this is needed ? srsly) , all of this adds up to 3bil transistors that heat the room

mircea_popescu: http://btcbase.org/log/2019-03-09#1901064 << in quite related news : went to flagship mall in this country, escazu multiplaza (escazu being where the us embassy compound lies, and all the retarded gringos live, very miami real estate racket reservation), and guess what ? there's no ipad store. AT ALL. instead, huawei dominates both in advertising (these large floating banners) and location (top floor store, only one to sell c ☝︎☟︎

a111: Logged on 2019-03-09 22:40 asciilifeform: when you build 1 of these things, there's a set of decisions that end up determining shape of whole thing; and it so happens that intel made ~all~ of the most retarded possible choices.

mircea_popescu: jobs' been dead what, a decade ? not even a decade. meanwhile, fifty FUCKING MORONS sat around in rooms pompously pretending as to how "of course i'm teh vp, didn';t you see the sign on the door ?"

mircea_popescu: vp of motherfucking what, exactly ? "how to give away the market to the azns" ? that's a skill ? ☟︎

mircea_popescu: any fucking monkey picked out in the street could have made ~just as good~ a "corporate executive" as the fucktards apple hired -- and somehow nobody is telling them this. and of course the idiots don't have the werewithal to look in the mirror, "if plumbers were as good at plumbing as we are at executiving, we'd be quite literally swimming in the shit we're metaphorically drowning in!" ☟︎

mircea_popescu: this is the fucking problem of socialism, when that wanna-be alt-hilary stupid cow asks "if the government can print money to rescue wall street, why won't it print money to let the chitlins enjoy the college lifestyle free of charge (and permanently!)" she has a fucking point -- and the entirely similar stup ☝︎

a111: Logged on 2017-03-15 00:29 mircea_popescu: pretty fine example of exactly why warren was so vocal (item was strictly a barony created so elizabeth warren could be barron OF SOMETHING). this cfpb item spent 55mn on "renovations" of its hq, ie more than the gsa spent that year on everything the usg owns ; spent immensely on travel (which is not something they do). the chairman is supposed to not be removable by the president except "for cause" (meanwhile that got strick

mircea_popescu: id cow "from twitter" explaining @whatever conference "how serious they take banning" blinks incomprehendingly just as she's done with her soundbytes. yeah, why is it ??? there's entirely no difference between any of them and any other aspiring-writers-in-new-york, philosophy of art history studies rejects the world over. why those, why not these ? blink blink ?

mircea_popescu: dude check me out, by now i'm writing 500 word chatlines. this isn't going well.

mircea_popescu: but on a more optimistic note, that's probably the most anyone cared about anything to do with the topic or the persons named or otherwise referred to in their entire history. that should count for something.

mircea_popescu: but speaking of those design decisions, by my current thinking the ideal processor is defined as follows : the bus width is 512bits ; therefore the byte is 512bits. the processing core is a state machine, with 512 byte-sized registers. a processor is composed of 512 + 8*9 such cores. for convenience imagine them organized in a cube, 8x8x8, with an extra 64 item layer on three sides. ☟︎

mircea_popescu: the 512 "central" cores are state machines that can do add or mul, and always proceed ~on their entire register set~. so if you don't want to multiply 131072-bit numbers, just put in zeros ; and if you put larger numbers in there you'll just get the LAST 262144 bits of the result, is all.

mircea_popescu: the 64 "flat outer" cores are state machines that can do mvin and mvout -- taking registers to memory or memory to registers, ie use the bus. only, of course, for the state machines inside their ~projection~. ☟︎

mircea_popescu: the remainder 8 "sharp outer" cores control the flats, by moving things in and out of ~their~ registers.

mircea_popescu: memory, of course, starts with byte 299008 (584 * 512) and extends as far as 512 bits bus can address, if you're installing that. meaning, all core registers are allocated as memory anyways. and that's fucking it. ☟︎

mircea_popescu: i ~can't imagine~ what the fuck must have been going through the skull of whoever came up with "working a piece or moving the worked piece, same thing". what the fuck ever is it same thing! ☟︎

asciilifeform: http://btcbase.org/log/2019-03-10#1901101 << recall, ave1 found that the asm inlining was ~yet another~ item partially broken in ye olde gnat ( iirc it dun let you assign registers deterministically ) ☝︎

a111: Logged on 2019-03-10 02:44 mircea_popescu: http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/#selection-15.295-19.176 << why this, specifically ? is there no ada asm calling method besides this ?

asciilifeform: http://btcbase.org/log/2019-03-10#1901090 << i was convinced somehow that crapple stores exist only in the reich ☝︎

a111: Logged on 2019-03-10 02:22 mircea_popescu: http://btcbase.org/log/2019-03-09#1901064 << in quite related news : went to flagship mall in this country, escazu multiplaza (escazu being where the us embassy compound lies, and all the retarded gringos live, very miami real estate racket reservation), and guess what ? there's no ipad store. AT ALL. instead, huawei dominates both in advertising (these large floating banners) and location (top floor store, only one to sell c

asciilifeform: think, where else are idjits gonna ~lease~ ( the new crapple thing! not even buy, lease.. ) a brick for its weight in gold

a111: Logged on 2019-03-10 02:46 mircea_popescu: 7% gains, not even that huge.

a111: Logged on 2019-03-10 03:02 mircea_popescu: but speaking of those design decisions, by my current thinking the ideal processor is defined as follows : the bus width is 512bits ; therefore the byte is 512bits. the processing core is a state machine, with 512 byte-sized registers. a processor is composed of 512 + 8*9 such cores. for convenience imagine them organized in a cube, 8x8x8, with an extra 64 item layer on three sides.

asciilifeform: http://btcbase.org/log/2019-03-10#1901105 << this is sorta how hillis's 'connection machine' worked. was pretty neat. ☝︎

a111: Logged on 2019-03-10 03:02 mircea_popescu: the 64 "flat outer" cores are state machines that can do mvin and mvout -- taking registers to memory or memory to registers, ie use the bus. only, of course, for the state machines inside their ~projection~.

asciilifeform: the thing with gigantic multers is that they grow physically with the cube of the bitness. hence scarce. ( tho i dun imagine even a 8192bit single-cycle multer would be remotely near as heavy as the 3bil-transistor 'let's fry eggs' pentium-xxviii or whatnot )

asciilifeform: http://btcbase.org/log/2019-03-10#1901108 << pipelineism, branchpredictionism, etc., all these heresies, were birthed from the fact that speed of memory fell massively behind that of cpu, in the time it takes to fetch ~anything~ you can do five digits of clock cycle ☝︎

a111: Logged on 2019-03-10 03:04 mircea_popescu: i ~can't imagine~ what the fuck must have been going through the skull of whoever came up with "working a piece or moving the worked piece, same thing". what the fuck ever is it same thing!

asciilifeform: aaaanyfffing but get rid of the idjit von neumann bottleneck and bake micro-cpus into the ram

asciilifeform: http://btcbase.org/log/2019-03-10#1901095 << rando monkey from the zoo would make 9000x better director than the catamite d00d ( recall, what he was in charge of prev. : rounding the corners on the 'ui'.. ) ☝︎

a111: Logged on 2019-03-10 02:24 mircea_popescu: any fucking monkey picked out in the street could have made ~just as good~ a "corporate executive" as the fucktards apple hired -- and somehow nobody is telling them this. and of course the idiots don't have the werewithal to look in the mirror, "if plumbers were as good at plumbing as we are at executiving, we'd be quite literally swimming in the shit we're metaphorically drowning in!"

asciilifeform: http://btcbase.org/log/2019-03-10#1901094 << with or without crapple, asia laffs allthewaytothebank -- it aint as if crapple bricks are made somewhere other than shenzhen ☝︎

a111: Logged on 2019-03-10 02:23 mircea_popescu: vp of motherfucking what, exactly ? "how to give away the market to the azns" ? that's a skill ?

a111: Logged on 2019-03-10 03:02 mircea_popescu: memory, of course, starts with byte 299008 (584 * 512) and extends as far as 512 bits bus can address, if you're installing that. meaning, all core registers are allocated as memory anyways. and that's fucking it.

asciilifeform: i dun expect to even live to see with own eyes a machine where 64bits of addr space fully populated (on current x64 Official standard, only 48 addr lines even connected, the rest mandatory 0)

a111: Logged on 2019-03-10 03:21 asciilifeform: http://btcbase.org/log/2019-03-10#1901103 << i cannot resist to bite : why 512 ?

mircea_popescu: asciilifeform so i take it your ideal cpu would actually be simply state machines + registers, no actual ram ? ☟︎

diana_coman: http://btcbase.org/log/2019-03-09#1901066 -> I ran those and I got exactly the same genesis.vpatch (i.e. diff on this vs the one obtained from the script itself returned empty) ☝︎

a111: Logged on 2019-03-09 22:43 trinque: diana_coman, other folks that have cuntooed, can y'all confirm that the paths that ended up in your genesis.vpatch do not in fact exist? I'd like you to reproduce the commands starting at line 114 of scripts/make_portage_tree.sh in your build directories, i.e. cd ~/src/cuntoo/build/cuntoo and then run them, as root

diana_coman: onth in unexpected results and assorted ugh: vdiff ends up in stack overflow ran on those ☟︎

diana_coman: trinque, which are exactly the paths that don't match? since I don't have the original genesis.vpatch I can't really know what to check to look if indeed those paths actually exists or not or wtf

mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity. ☟︎

mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal" ☟︎

mircea_popescu: ie, socialism fails yet again, and calling itself "democracy" dun help anything -- flat is fail, no two ways about it.

mircea_popescu: http://btcbase.org/log/2019-03-10#1901145 << say this again ?! vdiff blows the stack when processing the two diffs ? ☝︎

a111: Logged on 2019-03-10 15:10 diana_coman: onth in unexpected results and assorted ugh: vdiff ends up in stack overflow ran on those

mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it. ☝︎☟︎

a111: Logged on 2018-09-25 00:39 asciilifeform: the only binball is that coupla kB of ddr ram init thing.

asciilifeform: http://btcbase.org/log/2019-03-10#1901142 << programmable interconnect fabric ( similar to what's sold as fpga ) . iirc i detailed this in old thrd. ☝︎

a111: Logged on 2019-03-10 08:23 mircea_popescu: asciilifeform so i take it your ideal cpu would actually be simply state machines + registers, no actual ram ?

a111: Logged on 2019-03-10 16:42 mircea_popescu: asciilifeform thinking about whart you said, i can't repress the suspicion that maybe the memory model is acrtually profoundly fucked,as a central driver of the whole cs insanity.

asciilifeform: http://btcbase.org/log/2019-03-10#1901148 << imho the ( ~homogeneous~ variant of ) fpga is actually the correct model. i.e. you get to stitch it later into however many parallel mechanisms you happen to need on a given occasion. ☝︎

a111: Logged on 2019-03-10 16:43 mircea_popescu: ie, that structured data should really be much better hardware supported, that memory should include much more processor per storage cell, that in fact memory should look a lot more like trees than the current flat, democratic lines of "all cells are equal"

asciilifeform: http://btcbase.org/log/2019-03-10#1901153 << bake 'pile of reconnectable flipflop' and then you aint gotta ever bake anyffin else again. iirc i detailed this in ancient thread, mircea_popescu barfed ( iirc answered 'why waste so many transistor on interconnects' ) , but can't currently dig up where we had this ☝︎

a111: Logged on 2019-03-10 17:02 mircea_popescu: perhaps the correct republican approach is not to bake cpu, but to ~bake memory~. why even bother with the whole turdpile that's ddr init when could simply have sane ram, and rk with it.

asciilifeform: http://btcbase.org/log/2019-03-10#1901140 << the down side of 'let's 512b bus' is that most cpu time (where it runs, not counting idles on i/o here) is spent in 'inner loops' where yer counting to e.g. 3. and nao you gotta move 512bits when yer counting to... 3 ☝︎

a111: Logged on 2019-03-10 05:07 mircea_popescu: http://btcbase.org/log/2019-03-10#1901119 << because 8 cubed.

diana_coman: mircea_popescu, yes, vdiff on the 2 genesis.vpatch files overflows the stack; while on same machine and same files, diff seems to have no such trouble

asciilifeform: ( the style of programming that would appear on ' asciilifeform's ideal cpu ' is best illustrated in http://btcbase.org/patches/fg-genesis/tree/fg.v . i.e. all of the independent pieces in fact run in parallel, and in deterministic time, there are no interrupts, no scheduler, etc. )

a111: Logged on 2018-10-20 01:44 asciilifeform: !Q later tell phf i found today that your keccak-vdiff is unable to eat a 40MB file ( dies politely with stack overflow )

asciilifeform: diana_coman: i do not presently know where is the barf threshold, i suspect it depends on yer stack size

asciilifeform: i'd like to see phf come back to life and fix. failing this, 1 of us will have to ☟︎

asciilifeform: diana_coman: iirc it throws whole file on the stack, but then also keccak eats stack

asciilifeform: !Q later tell phf fughet for nao about http://btcbase.org/log/2019-03-01#1899897 , but wouldja pleez fix vdiff ? and tell us what sorta swamp yer stuck in, what wouldja need to get to surface ? ☝︎

a111: Logged on 2019-03-01 08:57 phf: asciilifeform: give me until end of march to resolve it one way or another, feel free to neg rate me then

lobbesbot: asciilifeform: The operation succeeded.

asciilifeform: diana_coman: i think he's trapped in some sorta cube hell; the squarebracket thing mircea_popescu asked for also not happened yet etc

asciilifeform: diana_coman: the 'errything on stack' approach has its limits; it is why i wrote the mmap thing (currently stuck in limbo , but i'ma have to revive it and fix, cuz ffa 17 also is hitting against this wall, you can't expect to put 100MB on stack, you gotta mmap it

asciilifeform: i'ma detail, ftr : 'ffacalc' runs 'as fed', i.e. 1 command at a time. but 'peh' , adult version, has support for functions and loops, and therefore requires the 'tape' to exist in memory. so currently i have 'tape can be 1000000 bytes', but this is not acceptable obv. in the long term

asciilifeform: mmap is the obv. logical method to handle multi-MB inputs for e.g. vdiff , without introducing heapisms

asciilifeform: tho not neccessarily required, in vdiff, the process as i understand it does not actually demand random access to the entire input

mircea_popescu: diana_coman see, if it is broken code, then it just eats all stack available. but i suspect here code is sound, demand on stack defensibly large.

mircea_popescu: the whole "low stack by default" thing is a low level "let's stimulate heap usage", in the same exact way the empire of smegma would impose a high import tax on soap.

mircea_popescu: asciilifeform it's not at all evident vdiff is broken. what'd you have him do ?

diana_coman: mircea_popescu, yes, I don't suspect the code is broken as such but it is a limitation of the approach and I did not really expect bumping into it at 7MB

diana_coman: I don't recall it being discussed in detail (i.e. with numbers for stack size and input size) anywhere and I think it should be, if it stays as it is

mircea_popescu: asciilifeform imo it is the job of the kernel to expose all available memory (ram, and fucking hell, disk, too, ALL available memory) to me as i fucking want it : stack, cpu registers, heap, whatever it is i wanna call it.

asciilifeform: mircea_popescu: kernel ( linus's , that is ) -- exposes. the tricky bit was/is the ada glue.

a111: 28 results for "horsecocks", http://btcbase.org/log-search?q=horsecocks

BingoBoingo: asciilifeform: It's march 10th, what is the window for a supply run looking like and what issues appear to be blocking?

asciilifeform: BingoBoingo: currently hands full restarting ffa conveyor; however will be ordering irons in next 2 wks, and scheduling flight when the items with least predictable shipment windows are in hand

BingoBoingo: asciilifeform: Aite. We don't do these very often yet, so getting things in hand trumps getting plane ticket arranged.

asciilifeform: BingoBoingo: i'd ~really~ like to avoid the scenario where i go out with a half-empty crate

asciilifeform: i'm reluctant to do the massive rk thing until we have a semblance of working gnat for arm

mircea_popescu: i don't really, and besides my/our policy has mostly been to have pizarro own iron, hence the snsa sale etc.

asciilifeform: we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 )

mircea_popescu: true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones.

phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch. ☝︎☟︎

a111: Logged on 2019-03-10 17:40 asciilifeform: i'd like to see phf come back to life and fix. failing this, 1 of us will have to

lobbesbot: phf: Sent 2 hours ago: <asciilifeform> fughet for nao about http://btcbase.org/log/2019-03-01#1899897 , but wouldja pleez fix vdiff ? and tell us what sorta swamp yer stuck in, what wouldja need to get to surface ?

BingoBoingo: <mircea_popescu> true enough. nevertheless, in my view owning iron helps give pizarro some meat on its bones. << That it does

phf: the problem is that our ada keccak explodes whatever char buffer it gets into an array of octets, which means that, while diff keeps the size of chunks under some particular value, keccak explodes that value x8

trinque: diana_coman: http://p.bvulpes.com/pastes/rWreS/?raw=true << here's the diff of your genesis and mine again

trinque: you'll notice it thinks your home dir is sitting in the profiles dir, which is mighty strange! maybe it is?

phf: http://btcbase.org/log/2019-03-10#1901200 << that is not at all the problem. i can read the file just fine, but as i do i feed chunks of it to keccak. keccak doesn't take char buffers, it wants "bitstream" i.e. arrays of bits, which means whatever char ☝︎☟︎

a111: Logged on 2019-03-10 18:09 asciilifeform: mircea_popescu: ideally, mmap the inputs

phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation ☟︎

diana_coman: trinque, that's weird; fwiw: no, my home dir as far as I can see is *not* in the profiles directory

diana_coman: trinque, this is probably having to do with the drive being external, connected via USB and how it's mounted, I don't see any other explanation

mod6: <+asciilifeform> we also host owner-operated iron (e.g. dulap is still snsa ; and trinque has some, and mod6 ) << The Foundation's 2nd box ("lovelace") is with ben_vulpes, currently. He's going to find a home for it in his new area, last we had talked about it. I don't have any machines on-hand that are waiting to go to .uy. However, I might be interested in buying a UY1 style machine from alf...

a111: Logged on 2018-12-03 21:48 diana_coman: hm, if it's indeed the tmp thing, it might be worth a try to press vtools to current leaf (i.e. vtools_tempfile_standalone or _notmp) and see if that cures it; my archive contains pressed vtools to ksum patch only, not further

mod6: Ok, I'm gonna shutdown the cuntoo box, and boot my original gentoo ssd (where I built cuntoo from). I'll see what I can find out from the genesis.vpatch thing.

diana_coman: trinque, I'm trying here to even *see* this "profiles/" path in any other way than in the vpatch but so far no luck

feedbot: http://qntra.net/2019/03/french-ophthalmologists-demand-police-rubber-ball-bullet-ban-after-epidemic-of-eye-injuries/ << Qntra -- French Opht...ists Demand Police Rubber Ball Bullet Ban After Epidemic Of Eye Injuries

diana_coman: apparently vdiff is correct after all and there is this thing it sees - it just took me a bit to find it as I thought it was just a misplaced path rather than...the actual thing,huh

mircea_popescu: phf pretty sure that's the wrong version of it ? iirc there was also a keccak that didn't explode ? diana_coman ?

bvt: trinque: i also confirm that under /cuntoo/portage/profiles there is a directory structure that corresponds to my bootstrap environment

lobbesbot: bvt: Sent 22 hours and 22 minutes ago: <asciilifeform> http://bvt-trace.net/2019/03/ffa-chapter-9-homework-comba-in-x86_64-assembly/comment-page-1/#comment-12

diana_coman: mircea_popescu, when he says "explodes" he means that keccak implementation expects as input a bitstream where each bit is stored in an octet

bvt: something like i.e. /cuntoo/portage/profiles/root/cuntoo/build/usr/portage/profiles/features/musl/use.mask

bvt: i confirm that it is both in genesis and is a valid path. i'm testing live cuntoo though, have no access to bootstrap env currently

a111: Logged on 2018-10-12 13:08 diana_coman: asciilifeform, hm, the bit version blows up buffers even more because it uses *internally* arrays of bits as per http://www.dianacoman.com/2018/02/01/eucrypt-chapter-8-bit-level-keccak-sponge/#selection-51.100-51.594

diana_coman: trinque, bvt put clearly what I was trying to say: here I have the same: the full directory structure inside /cuntoo/portage/profiles

mircea_popescu: diana_coman do you see the wisdom in implementing a keccak variant that uses eucomms-style fields ? so that something like "hello world" would be passed as 0x01146865 6c6c6f77 6f726c64

diana_coman: mircea_popescu, from keccak's pov there is no meaning to the input so I don't quite see what you mean there

mircea_popescu: to be clear : i expect that in the regular course of republican work, GB-sized vdiffs will occur -- strictly because we're contemplating confiscating all sort and manner of heathen artefact, and by now bloat is just a synonym for heathen. the "increase stack" fix works ok as a stop-gap, but we can't really 8x everything just for boredom.

mircea_popescu: diana_coman i mean that instead of keccak receiving array of bits stored in octets, keccak receives (and processes) a eucomms field.

diana_coman: that requires simply a bit-level keccak; which requires in turn someone with the time to do the transformation as it were

mircea_popescu: 0x(01 => length of 2nd field is 1) (14 => length of 2nd field is 20) (6865 6c6c6f77 6f726c64 = hello world).

deedbot: bflame voiced for 30 minutes.

diana_coman: that seems to be at most at reading-chunk-from-file level which is not really related to keccak and not a problem if I understand correctly what phf says; specifically on one hand he said http://btcbase.org/log/2019-03-10#1901225 and then option c from http://btcbase.org/log/2019-03-10#1901236 ☝︎☝︎

a111: Logged on 2019-03-10 19:44 phf: http://btcbase.org/log/2019-03-10#1901176 << i'll put it to the top of the stack, i remember fixing it, but never completing the patch.

a111: Logged on 2019-03-10 20:00 phf: there are three possible solutions, a) make sure that stack is arbitrarily large b) feed keccak buffers no larger than some magic size c) rewrite keccak to operate on char arrays directly without the need for bitstream allocation

mircea_popescu: bflame how about you make yourself useful and implement a keccak as discussed ^ then patch diana_coman 's tree with it.

diana_coman: so perhaps the text coding etc would help at chunking-file stage if needed but what is that to do with keccak

mircea_popescu: diana_coman well, apparently it expects to be called with a bitstream, which is a peculiarly inconvenient datastruct in practice.

mircea_popescu: i really do not wish to see c strings, and i don't perceive char buffer to be different. "bitstream" does not exist. so my thinking is, to henceforth mandate datapassing as such a field.

mircea_popescu: the ~problem~ with c-strings is that to know how loing it is you must look ~at the end~.

mircea_popescu: the problem with any other datastruct, such as octets or words, is that you never know how large it is.

asciilifeform: mircea_popescu et al : there are no cstrings in ada, unless one explicitly bakes'em in order to throw to c linked liquishit. all arrays carry their bounds with'em.

bvt: http://btcbase.org/log/2019-03-09#1901061 << iirc there were restriction on what regs can be used as base and index; another example of isa ugliness is MOV http://archive.is/w0IAC#selection-607.0-945.2 ☝︎☟︎

a111: Logged on 2019-03-09 22:35 asciilifeform: btw, bvt , rax etc. ~are~ encoded as 1-8, the iron dun see reg names at all, the classic names are a convention of the asmers and the vendor docs. and imho remains on acct of the asinine x86isms like MUL which use fixed input and output regs, makes'em slightly easier to remember.

bvt: http://btcbase.org/log/2019-03-09#1901064 << well, IMO nvidia's "denver" managed to beat even them. ☝︎

bvt: ('denver' is arm at frontend and vliw inside, dynamic jit tries to continuously improve translation: if you have a loop, the 1st, 100th and 1000th loop iterations can execute totally different vliw code)

bvt: http://btcbase.org/log/2019-03-10#1901101 << I decided against inline assembly because the asm source is quite large, it's inconvenient to have 100+ lines of asm inline with comments. ☝︎

bvt: there are Import(Ada,...) and Import(Asm,...), which do the same thing according to the docs (http://archive.is/XEHW0#selection-17075.0-17109.171), and I did not manage to find any ABI docs with 'ada calling sequence'.

mod6: trinque: Ok, immediately I notice that in my /home/mod6/cuntoo/nomods/cuntoo working directory, from which I ran `./bootstrap.sh -k config/cuntoo-test1 -d /dev/sdb` there is currently nothing in the 'build' directory.

mod6: I've looked at the genesis.vpatch that was genereated ( http://www.mod6.net/cuntoo-blog-2/nomods.genesis.vpatch ), and at first glance I don't see these files in their paths. (even if I remove the preceeding 'a/').

mod6: trinque: aha. yeah, powered down, plugged my gentoo SSD back in, and am booted into gentoo where i've built cuntoo.

mod6: Oh, sorry, I guess I wasn't excatly sure what you were asking me to look for, and where. I never had /dev/sdb mounted when I did the bootstrap.

trinque: you didn't read the script either and would otherwise know that it mounted that for you.

mod6: I have also posted the entire typescript (47Mb WARNING) of the build to my website: http://www.mod6.net/cuntoo-blog-2/nomods.cuntoo.build.typescript

mod6: I also have tar'd up the entire cuntoo build directory, but have not posted it. It's like 1.7G, but will send it somewhere if someone wants it.

trinque: scripts/make_portage_tree.sh << line 14, I do string-munging on the path that's specific to my own filesystem layout ☟︎☟︎

mircea_popescu: diana_coman what ended up being the problem then, i'm not getting something here.

feedbot: http://pizarroisp.net/2019/03/10/pizarro-isp-march-10th-update/ << PizarroISP -- Pizarro ISP March 10th Update

trinque: bvt: diana_coman: I wager that if you change line 14 of scripts/make_portage_tree.sh to the following, my sig will verify on the resulting genesis.vpatch : dest=$pdir/profiles/${src#$bdir/usr/portage/profiles/} ☟︎☟︎☟︎