bvt: i have a http://archive.is/EUW9n item at home, with kernel from some arm64 distro and pizarro rockchip rootfs, but i never got time properly setup this device (plan was, run trb node)

bvt: it is not clear to me if big.little ever worked acceptably with linux -- they are tuning even today

bvt: iirc changed, but too recently to even consider a switch anyways

bvt: asciilifeform: rk3399 is a bit trickier in usage than rk3328 of pizarro rockchip -- big.little arch, so scheduling and power management have to come from rockchip kernel tree, not vanilla.

bvt: the kind of cloth used for lens cleaning works as well?

bvt: could be, i never got to disassemble and check the board after changing wlan card.

bvt: it has an annoing problem of producing high-pitched noise when running with ext. input devices or wlan on, but overheat happends only after ~45 min of compiling, which i don't do any more.

bvt: is it that much more stable with lenovo bios? i had it overheat with both orig. and coreboot variants, so stayed with coreboot

bvt: at the time i was getting mine - only w. T2400 and iirc slower cpu were available

bvt: right, t2400 is 32bit, t7200 is later generation - 64bit

bvt: please check, because all docks pointed into '32bit only' direction - perhaps it was disinfo.

bvt: hm. i have the same, but T2400 is 64bit in 'PAE' sense, not in register width sense.

bvt: this would actually be interesting for x60 machine owners as well. the register pressure would also increase on i386

bvt: only on mult, not on modexp

bvt: asciilifeform: depends on whether there will be a usecase for such item, but in any case shifts/adds should be simpler than comba

bvt: then, perf increase should be substantial

bvt: hi. the exact cut will depend on what % of ops in barret are mults

bvt: also, i was under impression that asciilifeform suggests to ditch C after getting sane iron ☟︎

bvt: http://btcbase.org/log/2019-04-25#1909969 << that clarifies the issue, thanks. i got momentarily confused because imho cuntoo (as gentoo repo snapshot) is too large to pull off http://btcbase.org/log/2019-04-24#1909621 - i see no way to replace gcc with tcc and 'rebuild world' without rewriting ebuilds/getting a ton of errors; but should be realistic with something smaller (which i plan to do). ☝︎☝︎

bvt: http://btcbase.org/log/2019-04-24#1909728 << he indeed looks very experienced http://archive.is/VOaOV#selection-1166.1-1192.0 http://archive.is/nmzYW#selection-3746.0-3773.78 http://archive.is/FeiYm#selection-3319.1-3321.349 ☝︎

bvt: though to my understanding he uses zeptobars photos at least sometimes (http://archive.is/pjqcH#selection-1139.1-1483.105 , http://archive.is/K1Efi#selection-3499.55-3503.154)

bvt: he worked with 580BM80A as well http://archive.is/01iuf, http://archive.is/RKAEx , also with feature recognition

bvt: http://btcbase.org/log/2019-04-24#1909723 << i will definitely write him ☝︎

bvt: *the cited link should've been http://btcbase.org/log/2019-04-24#1909727 ☝︎

bvt: http://btcbase.org/log/2019-04-24#1909683 << do you mean the pdf/word in the vm1 directory? or whole repo with e.g. http://archive.is/E2iex#selection-3535.0-3561.54 ? if there is a single document, i'd definitely read ☝︎

bvt: http://btcbase.org/log/2019-04-24#1909614 << i can do some experiments with tcc-based linux; this may be a too big chunk if i start with cuntoo, but should be possible with some very minimal linux. ☝︎

bvt: http://btcbase.org/log/2019-04-24#1909627 << added to the list of things to try ☝︎

bvt: http://btcbase.org/log/2019-04-23#1909552 << i grok this. the question is, how much work should go into cuntoo? ☝︎☟︎

bvt: PeterL: binary ave1gnat is already hosted by asciilifeform; but it's integration into cuntoo is an open problem that ave1 should be best equipped to handle ☝︎☟︎

bvt: http://btcbase.org/log/2019-04-23#1909490 << speaking of which, http://archive.is/pEMWM ; also, i guess elbrus-2 (~1985) and besm-6 are still running ☝︎☟︎☟︎

bvt: http://btcbase.org/log/2019-04-23#1909440 << this would involve getting binutils under our control - bigger part of these timestamps are added by ar/ld; tbh i even dunno if gcc is responsible for this at all. ☝︎☟︎

bvt: also, you can't build ave1gnat from scratch on fresh adaless system because of http://btcbase.org/log/2019-04-23#1909529 - so initial gnat binary will be required (ebuilds just download binary gnat for that). ☝︎

bvt: http://btcbase.org/log/2019-04-22#1909279 << you can't use adacore's gnat to bootstrap ave1gnat on musltronic systems, but http://btcbase.org/log/2018-05-15#1813753 works for that purpose; ☝︎☝︎

bvt: http://btcbase.org/log/2019-04-22#1909254 << i suspect that fixing direct gcc6->gcc4 step involves something like http://archive.is/cBg9N#selection-9.1340-9.1425 ☝︎☟︎☟︎

bvt: the problem with these both approaches is that it's impossible to get gnat/ada that way - gnat was bootstrapped from some commercial ada compiler in ~1994, and is self-hosted since that times. (well, impossible by definition with just tcc) ☟︎☟︎

bvt: http://btcbase.org/log/2019-04-23#1909396 << do you mean going [preinstalled gcc6] -> tcc -> gcc2.95 -> gcc4.7 -> gcc4.9 for cuntoo? or drop gcc entirely, try to get as much as possible running on tcc? ☝︎☟︎☟︎

bvt: thank you, this is a great honor to me

bvt: i see; if vendor can subvert the chip in nonobvious way by changing delays organizing a military style приемка would be the only option for actually using the devices

bvt: i get the propagation delay physics; i guess the question is how much is lost due to suboptimal design tools, vs max capability of hardware

bvt: i have to admit i have zero experience with these tools

bvt: the larger fpga - seems to be it https://symbiflow.github.io/prjtrellis-db/ ? last time i checked it was work in progress

bvt: asciilifeform: isn't ice40 a done thing, i.e. is there anything else to add to it?

bvt: asciilifeform: http://trilema.com/2015/la-chacarita/#selection-107.0-107.209 ?

bvt: yes, this is a point; i don't believe they'll even try to use oak - they have 'modern, improved' materials these days

bvt: http://btcbase.org/log/2019-04-15#1908583 << well, after ww2 germans did rebuilt everything as accurately as possible ☝︎

bvt: the only smaller item in my pipeline is unrolling comba for ch10 multiplication; and i'd like to give a shot a 'kill /dev/random and /dev/urandom' experiment, replacing them with buffers than can be directly fed from userspace, but this - even later. ☟︎

bvt: hello. just to give you a bit of information: i am alive; i'm pretty short on work time this month; given that this did not cause any further discussion i will stall it for some time.

bvt: phf: http://bvt-trace.net/2018/10/vpatch-replacing-mktemp3-take-two/#selection-13.0-31.43

bvt: i guess asciilifeform will comment tomorrow if he feels good enough (gute besserung!); i have to go to sleep right now

bvt: (iirc asciilifeform has a SU keyboard-driven prom burner, which may be a valuable device for bootstrap)

bvt: yes, with tape writers/serials, os can be delayed much further; persistent storage would complicate bootstrap a lot.

bvt: yes, i agree that a simple and clear boot sequence is a requirement

bvt: re add with carry, http://www.loper-os.org/?p=1913#selection-2329.9-2347.129

bvt: unfortunately i've worked mostly with x86, so the only other assembler i've seen was arm64 (did not look at it's instruction encoding though)

bvt: re 1, both worth using (but no lisp cpus here yet) and with features useful for bootstrapping

bvt: re 2, after a restricted ada assembler, should a ada-dos be built? mes assumes that linux kernel is a given, which imho is a big hole in the process

bvt: but are there any other features that help the bootstrap? even if this increases hardware complexity a bit

bvt: i.e. re 1 you opted for architecture where instruction encoding is easy to do by hand

bvt: to my understanding there are two questions: 1. what are the requirements to the architecture 2. what is the first interim stop after a post-M1 assembler? ☟︎

bvt: http://btcbase.org/log/2019-04-05#1906987 << well, this depends on the subset of ada; re contributors - this is a known issue ☝︎

bvt: of course, ada/gnat is too complex for bootstrapping as-is, but i guess equivalent safety properties would be still required

bvt: so far everything points into the direction opposite of linux/c (http://mocky.org/Log-Reference-Why-Ada/ may be interesting)

bvt: indeed there is; the relevant thread is http://btcbase.org/log/2019-03-18#1903170 ☝︎

bvt: !!v 3E663D0A962864DA7A238FA8497667A046916568FA36ED6112CEAE9C25A9FBAE

bvt: !!rate OriansJ 1 stage0 author

bvt: !!up OriansJ

bvt: started pizarro isp (http://pizarroisp.net/), and wrote FFA crypto library, in case you wondered what 'FFA style' from my investigation report was: http://www.loper-os.org/?p=3141 - vpatch + a write-up for helping fitting-in-head the code

bvt: to give you a short introduction, people from this place have developed FG TRNG (http://nosuchlabs.com/hardware.html), V versioning system (http://btcbase.org/patches?patchset=v), Eulora MMORPG (http://ossasepia.com/), maintain a btc reference node

bvt: OriansJ, you can register a GPG key with deedbot (http://deedbot.org/help.html), i'll rate you and you'll be able to up yourself.

bvt: OriansJ is the stage0 author, please up him upon request

bvt: !!up OriansJ

bvt: mircea_popescu: i'll try to get him into #trilema on the weekend

bvt: asciilifeform: yes, ending up with the same gnu stuff is pretty sad work result

bvt: http://btcbase.org/log/2019-03-26#1904859 << that 'me' was OriansJ, if wiki change log can be trusted ☝︎

bvt: i also don't like how at the 'mes' stage a linux kernel 'magically' appears as the underlying substrape, while stage0 parts are designed to work without os

bvt: asciilifeform: they claim that it is work-in-progress, but in fact c compiler that manages to compile tcc may be less then 10% of required work.

bvt: OriansJ in #bootstrappable has a notion of hygiene (at least basic, ie groks fits-in-head), and still works on the stage0; i had no interaction with janneke (mes author) yet, so can't make claims about him. he does make some noise in the #bootstrappable and #guix

bvt: linux bootstrap with actual mes is way more disappointingto stage0 components (the claim is 'c compiler is scheme and scheme interpreter in c', but in fact they require bash, patch, tar, etc. for the bootstrap).

bvt: hello. i did not manage to finish work on mes report part 2 last week, and i don't have a possibility to do any work this week. i plan to finish it around weekend next week.

bvt: i.e. finishing stage0/mes integration, and also there is a problem of bootstrapping gnat

bvt: well, the question is then, whether we want to do this for cuntoo -- this work will need some resources dedicated to it.

bvt: it's just that if components fit in head, imo alpha/beta does not apply

bvt: nope, it's not 'did' even for linux; this work is in WIP, not even alpha stage.

bvt: otoh, author did mention that most of the tools can be easily made to work on e.g. dos

bvt: asciilifeform: yes, this is a problem; for example, their x86_64 hex0-2, as little sense as this can make (in presence of intel me&etc), are done as linux binaries: currently their goal is to bootstrap linux

bvt: http://btcbase.org/log/2019-03-17#1903106 << i also agree that it is; i don't find myself knowledgable enough to make a decision on the republican cpu architecture, but for bootstrapping using ice40 with its limited resources a simple mips core sounded fitting. ☝︎

bvt: http://btcbase.org/log/2019-03-17#1902991 << as far as the 'stage0' is concerned, there is one guy manaloneing (OriansJ in #bootstrappable), and a dozen of people watching. can't say anything about 'mes' yet, it has a different author. ☝︎

bvt: hello

bvt: ok, i see

bvt: iirc the c-t version of algorithm comes later - around section 5. there is a formula for calculating upper bound of iterations, but I did not check his math.

bvt: also, i did not forgot about http://btcbase.org/log/2019-03-01#1899904 , but had too little time to investigate it properly; will try to do tests over this week and do a writeup on the weekend ☝︎

bvt: asciilifeform: https://gcd.cr.yp.to/papers.html -- rather new constant time gcd from djb. i did not look at it closely so can't say if it's anything good or belong to the kunstkammer

bvt: rather, http://btcbase.org/log/2019-03-10#1901346 ☝︎

bvt: trinque: after applying http://btcbase.org/log/2019-03-10#1901339 your signature verifies correctly. thanks! ☝︎

bvt: yw

bvt: correct, it was a liveusb system

bvt: ls -R /cuntoo http://wotpaste.cascadianhacker.com/pastes/hHbuq/?raw=true find /cuntoo http://wotpaste.cascadianhacker.com/pastes/gAtS2/?raw=true

bvt: as i mentioned, currently i can show results only from live cuntoo

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'.

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. ☝︎