asciilifeform: realized when i woke up that really oughta have first tried plain-old sjljistic ave1-gnat , and see if this cure is even necessary there
asciilifeform: mircea_popescu: this run is a test of bvt's 'kill weaksymbol-ism' pill
asciilifeform: ( the fact that diana_coman's built in ~1h, suggests that i broke my local config there )
asciilifeform: looking at the kilometre of bash that comes with the thing, for the answr
asciilifeform: really this whole thing oughta take ~30m on dulap ( 32 cpu )
asciilifeform: strangely , the -j32 thing aint working for good chunk of the build, possibly dun apply to the bootstrap gnat..?
asciilifeform: sadly had to restart the experimental build ~2h ago, botched the config last night
asciilifeform: i'ma put whole thing in a signed manifest
asciilifeform: ave1: i changed mine to work from local copy of the tars, back when first tested. is there anyffin else new in the sept. ver.?
asciilifeform: mummification is for dirty orcs, apparently; here , 'advanced', will instead have his 3d animated corpse 'speak' deep troofinesses 4evah
asciilifeform was in a public place where tv on the wall, and guess what was shown : mccain. apparently not dead enuff ( 'freshly uncrated' taped blather, near as i could tell. )
asciilifeform: ( this is where i point out, that the fabled 'sane iron' isn't simply a purely aesthetic win to ticke asciilifeform's aestheticles, but in fact substantially cuts down on the complexity of ~all other sane items~ that are to stand on top of it )
asciilifeform: if we had a sane iron, would be similarly easy to produce a back end ( and that's what asciilifeform thinks of as 'ada machine' )☟︎
asciilifeform: re bolix back end, i suspect it aint very useful as starting point, because was far ~too easy~ item , in that the iron per se was sane (i.e. performed bounds and type checks, so much of what gcc is stuck doing in soft, was unnecessary )☟︎
asciilifeform: ftr much easier for a sane iron ( with small instruction set ) like mips, than for x86.
asciilifeform: the other thing that makes backend a bitch is that ~100% of the work has to be done again and again, for each iron.
asciilifeform: it's why ~errybody is using gcc's (incl. the folx pretending not to)
asciilifeform: ( for n00bz: ) writing a compiler back-end aint actually hard. asciilifeform & many many other folx, did it ~as homework~ , at school. the hard thing is writing a ~decent~ optimizing backend.☟︎
asciilifeform: funnily enuff, i suspect there are a grand total of ~two~ ada back ends in existence : 1) the Official adacorpse one , sewed out of gcc ( the 'fsf gnat' is simply old copy of same )
asciilifeform: mircea_popescu: thinking about it, kernel is really the starting point for 'get c the hell off the box' -- the e.g. 20% of gnat's standard lib that's in c, is in c strictly cuz of reason illustrate in http://btcbase.org/patches?patchset=udp , i.e. that kernel api doesn't eat sane (e.g. bounded array) parameters, demands liquishit c-istic buffers
asciilifeform: is this actually in the worx ? or still chalkboard
asciilifeform: concretely -- on sane iron, cpu do not share memory, but instead implement exactly diana_coman's work-queue mechanism.
asciilifeform: ( the very need for locking, on software level, for instance, comes from the absence of any sane mechanism for corralling data to particular cpu )
asciilifeform: all of this might seem uninteresting until you realize that this is what sits under all threading, no matter how implemented on os side.
asciilifeform: ( ever wonder why cannot make 'unhangable' os for multi-cpu pc ? this is why )
asciilifeform: afaik none of'em, however (with possible exception of sgi's) have semantics such that multiple processors dun share a bottleneck at the interrupt controller
asciilifeform: 'younger' archs that were baked with decent # of interrupts to begin with, have ~slightly~ less retarded subsystem
asciilifeform: old msdos hands will recall setting jumpers for e.g. 'soundblaster' irq etc
asciilifeform: ( incidentally, when asciilifeform speaks of 'iron babel', interrupts are a screamingly concrete example : there is ~no uniformity b/w archs re how they're implemented (does it save regs ? which ? what happens if two interrupts temporally near ? ) or how many , or for what devices, etc )
asciilifeform: possibly i oughta add the detail, that $item is like any other machine i/o-ism -- on bare irons, it writes to the irq table ( whatever shape that has on $irons ) , on unixen it yes uses signals, because wtf else can you do there, on (hypothetical) msdos gnat, will again write to irq table, on boxen without interrupts -- will give eggog on build, what else; etc
asciilifeform: ( when build on unix -- it gets implemented as unix signals )
asciilifeform: ada.interrupts ~will~ have to be tested, it's a must for 'bare irons' adaisms as a class.☟︎
asciilifeform: ( for killing processes, it is possible to e.g. use ada.interrupts system . but asciilifeform not yet tested ! )
asciilifeform: that being said, sjlj is apparently totally broken on arm gcc currently, and if want a threaded proggy on e.g. rk, currently stuck with zcx
asciilifeform: diana_coman: if it aint a seekrit: didja ever try building client on musl ?
asciilifeform: ( the less said on the subj, the better, tho, my appetite already ruined by thinkin' about it )
asciilifeform: ( asciilifeform also maintains multi-MB 'non-tmsr' proggies. for orc dubloons. it's how he eats )
asciilifeform: diana_coman gets the trooly hard nuts to crack ( which is why retained by s.mg for coin , neh )
asciilifeform: ( asciilifeform is for instance at this very moment sitting on a glibcistic gentoo box, but where all tmsr soft is musltronic )
asciilifeform: mircea_popescu: fix of sjlj on arm64 is actually moar urgent than arm-cuntoo, cuz sanely build ( static-musl ) ~will~ run on glibcistic linux
asciilifeform: i expect that i'm even doomed to open a book and see how the fuck arm64 worx.
asciilifeform: mircea_popescu: entirely. see 2d ago thrd.
asciilifeform: diana_coman: the caveat is that i still dunhave a working cuntoo for all asciilifeform-operated irons; e.g. rk is still running barbaric old glibc gentoo
asciilifeform: i banned it for all asciilifeform-powered efforts in 2015, and dun miss it.
asciilifeform: rather than continuing in a babelized gnat with 'pick yer threader, pick yer stdlib' etc
asciilifeform: given this, asciilifeform would go with 'b' + 'we fix the breakages , both as-we-find-'em and proactively '
asciilifeform: ( as asciilifeform recently discovered re ffa. it dun thread, and gcc correctly snips out all pertinent coad )
asciilifeform: 'd' is arguably mis-statement of problem, a threadless proggy incorporates ~neither~ system
asciilifeform: for instance, emacs has yet to be cured, as i understand☟︎
asciilifeform: mircea_popescu: cuntoo is arguably a realtime test lab for 'what does removing glibc from ~errything~ cost'
asciilifeform: i dun see where drepperism wins in ~any~ version, vs. the ab initio and 10x moar compact musl.
asciilifeform: re 'e', i can't picture what'd move anyone with two neurons to rub together to maintain a glibc, that'd be rather like starting a trb from prb 12 (or what is current one)
