Show Idle (>14 d.) Chans

← 2020-09-08 | 2020-09-10 →
shinohai: !w probe
watchglass: : Busy? (No answer in 20 sec.)
shinohai: $vwap
BusyBot: The 24-Hour VWAP for BTC is $ 10232.93 USD
asciilifeform: shinohai: neato. is this new ver. of said bot, or simply renamed ?
shinohai: asciilifeform: it's the "experimental" version, hence the name change. Slowly getting around to testing a sort of msg service for it locally.
shinohai: $uptime
BusyBot: The bot has been up for: 1 days 4 hours 41 minutes and 16 seconds
asciilifeform: << i admit, always wanted a 'realtime' asmer for trad archs. esp. if also had 'tick table' , pipelineism reference displayed in parallel w/ coad...
snsabot: Logged on 2020-09-08 19:16:26 verisimilitude: My MMC model is superior to the assembler model.
asciilifeform: << x86 is just possibly world's ugliest arch to asm for (-64ism dun make so much diff in this respect)
snsabot: Logged on 2020-09-08 19:17:43 verisimilitude: I'm vehemently opposed to an x86_64 MMC targeting, as I don't believe the instruction set is even suited to an assembler, but the leagues simpler x86 may be in my sights, eventually.
asciilifeform: << recall 'debug' util ? closest thing i've ever seen to 'asm repl'
snsabot: Logged on 2020-09-08 19:48:51 trinque: verisimilitude: or is the idea closer to producing a "machine-code repl"?
asciilifeform: << fwiw i read verisimilitude's series on subj. it's imho elegant, for toy cpu, but i find that in practice nontrivial proggies in asm involve quite a bit of 'cut&pasta' and macroism. ( e.g. 'M' is maybe 40% macroism by weight )
snsabot: Logged on 2020-09-08 19:58:02 verisimilitude: Upon pressing a key, questions are asked until sufficient information is provided, and then a human-readable description of the instruction is given, alongside the omnipresent information such as the unit value in several bases and the address.
asciilifeform: macroism, to folx who dun spend much time writing asmism, feels like a luxury, but imho is inescapable if you want proggy to be readable; and helps in avoiding trivial mistakes
asciilifeform: << i expect these will be found. can't for a moment imagine that ~2GB of src is actually req'd for a usable linux
snsabot: Logged on 2020-09-08 19:35:41 trinque: I will perpetually be in the market for simpler items than the ones currently represented in the wad.
asciilifeform: !w poll
watchglass: Polling 12 nodes...
watchglass: : ( Alive: (0.090s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : ( Alive: (0.083s) V=70001 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : Alive: (0.083s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : Alive: (0.152s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498 (Operator: asciilifeform)
watchglass: : Alive: (0.168s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : Alive: (0.179s) V=70001 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : Alive: (0.281s) V=70001 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : Alive: (0.334s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : ( Alive: (0.372s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
watchglass: : ( Alive: (0.578s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647497
watchglass: : Busy? (No answer in 20 sec.) (Operator: asciilifeform)
watchglass: : Busy? (No answer in 20 sec.) (Operator: jurov)
trinque: asciilifeform: ironically, 1gb of that is the kernel, most of the other gig, gnat and binutils
trinque: not that I disagree; all 3 can surely be significantly slimmed
asciilifeform: trinque: aa, right, there's a kernel in there
trinque: I didn't snag just headers because next step is to make the item bootable
asciilifeform: makes sense
asciilifeform found that most of the obesity of linux kernel is from exotic irons. but doesn't currently have exact figure.
asciilifeform: !w probe
watchglass: : ( Alive: (0.100s) V=99999 (/ Jumpers=0x1 (TRB-Compat.) Blocks=647498
asciilifeform: !q uptime
snsabot: asciilifeform: time since my last reconnect : 19d 2h 29m
asciilifeform: !w uptime
watchglass: asciilifeform: time since my last reconnect : 48d 21h 3m
verisimilitude: A ``tick table'' as an omnipresent column of the interface is planned, for those machines which have such concerns, asciilifeform.
asciilifeform: verisimilitude: actually pretty difficult problem for x86 (where massive effect from pipeline interaction b/w adjacent ops)
asciilifeform: verisimilitude: what good btw would tick table do for emulated cpu (as in your case) ?
verisimilitude: As macros don't fit my model, that strengthens the purpose of the tool for the hardcore machine code programming, with a focus on size.
verisimilitude: I was wondering were I conflating ``tick'' and ``cycle'' inappropriately.
verisimilitude: My tool, for such CPUs which specify this, would have a column for the static cycle counts.
asciilifeform: imho ideally the ticks would be derived empirically, using iron profiler instrs
asciilifeform: ( for trad cpu, naturally )
asciilifeform: modern-day cpu vendors have moar or less given up on publishing 'tick tables', not only on acct of pipelineism, but also the atrocious memory access penalties which vary often ~randomly (due to cacheism) sadly.
asciilifeform: in 'M' i tried to weasel around the latter by making whole thing fit in a cache line. which it does. but, naturally, the data set (virtual ram image) does not.
asciilifeform experimented w/ x64's explicit cache control instrs, but did not achieve mega-result
asciilifeform: i mapped M's cpu regs ~mostly~ (but not entirely) to x64 regs; would potentially give speed boost to force the remaining regs to reside in cached ram, at expense of the 1G virt ram. but unlikely to make thing usably fast for practical use.
snsabot: (trilema) 2019-07-23 asciilifeform: meanwhile, in measurements : performance of system : as measured by a) 'bogomips' (linus's benchmark) : 93.4 times slower than host cpu; b) 'dhrystone' (traditional integer benchmark) : 300.98 times slower than host cpu.
asciilifeform: i.e. on 3GHz opteron -- you get equiv. of ~100MHz mips...
asciilifeform: if 'M' were to be rewritten as 'os kernel', could then also map mips's tlb to the x64 tlb. and potentially then merely ~50-fold penalty. but currently cannot think of a reason to attempt this.
asciilifeform: ( recall, orig. objective of experiment was 'can haz libless 100%-asm proggy that's guaranteed to boot a usable linux in 100% isolation on any 2.6 x64 linux'. rather than 'can turn a 300watt opteron into the perform. equiv. of 3watt 'pic32mz'' lol )
asciilifeform: trinque: back to thread -- if you end up regrinding genesis in near future, plox to throw in 'manifest.txt' -- seems to be missing
asciilifeform to attempt a boot of trinqueian 'bootstrap' on a dulap kernel, then a world build, later today when hands freed
trinque: cool, yep, will add a manifest.
trinque: asciilifeform: incidentally, I did an emacs build yest, and the fix works provided you're not using ASLR, otherwise segfault
trinque: I personally don't care; neither does my emulated asciilifeform. checking with the meat-instance.
asciilifeform: trinque: i can't say that the notion of running emacs sans aslr sets me into a fit. ( see also )
snsabot: (trilema) 2015-04-02 asciilifeform: aslr is sorta like building a labyrinth in your house to slow burglars
snsabot: (trilema) 2015-05-08 asciilifeform: mats: i very much see aslr as the proverbial 'teacher's condom', as per
asciilifeform: ( de-facto aslr serves as a kind of 'nsa curtain' on the overflow etc liquishit which abounds in opensoresdom, which 'dun need to be fixed cuz aslr' except then when usg attacker suddenly no aslr , typical pattern )
snsabot: (trilema) 2016-10-23 asciilifeform: in an unsurprising continuation of a very vintage lul, , --> << aslr bypass on intel iron.
trinque: seems very much like a fig leaf, yes.
trinque: fine thing for someone to choose for himself, at any rate.
asciilifeform: trinque: imho it's quite analogous to e.g. sslism. ( recall various threads where a n00b was horrified from 'we dun ssl' )
verisimilitude: I've a joke to this effect.
verisimilitude: The only way to write good software is to have it be correct and able to be fast and then have it made to actually be fast. Most software isn't correct, but is able to be fast, and is then made to be slow in an infinitesimal stepping towards correctness.
asciilifeform: i suppose nitpicker could say that e.g. pgp exists, but unixlike w/out 'over 9000' trivial overflows does not, and hence 'can't not aslr' but still analogous.
asciilifeform: verisimilitude: see also 'naggum's bathtub'.
feedbot: << The Montevideo Standard -- Former USG.NSA Head Keith Alexander Joins Amazon Board of Directors
← 2020-09-08 | 2020-09-10 →