tmsr - Log 2019-04-06

OriansJ: one minor note; there is a common pattern with structs to load (base + offset) followed by arithmetic/logic with another register and generally writing out to another (base + offset). So it is tempting to put in instructions to do those; but as the VAX has shown, it isn't worth the additional complexity.

OriansJ: I've been exploring the logs and one thing you may wish to know about bootstrapping MIPS is humans writing assembly need only 7 registers (I round up to 16 to include Stack pointer(s) and Condition register(s) and if my goal was optimize for C compiler performance, I would have gone with 64 registers (architecturally unified between the Integer unit and the Floating point unit but leveraging the trick of the DEC Alpha 21264 and ☟︎

OriansJ: electrically seperating them and simply require an Interlock delay when registers are updated between units) as that is the closest approximation of the 88.5 registers that is optimal

OriansJ: The Branch Delay slot should never been allowed and it just adds complexity to any bootstrap. The Multiply and Divide instructions of MIPS were just a bad idea and the DEC Alpha solution was a much better combination to go. The Exception style overflow pattern in MIPS is pure complexity and waste; the 68K series was so much closer to the optimal (The split Integer register and BCD support was a bad mistake that I am glad Cold Fire ☟︎

OriansJ: We definitely don't need hardware support for floating point though (just a set of defined encodings for floating point instructions and a clean exception mechanism which allows an operating system or a library to implement via software routines) ☟︎

a111: Logged on 2019-04-05 23:25 OriansJ: well, I guess a really important question to ask is at what level of lithography people here actually have trust? (1 transistor, AND Gate in TTL, 100 Gate ALU, 1000 Gate ULA, 10000 Gate Asic, .... FPGA, 1B+ gate CPU, etc)

spyked: http://btcbase.org/log/2019-04-05#1907021 <-- the problem with "portability" (in the sense of supporting/maintaining the same software interface across different hardware architectures/configurations) is that it's a convenient lie most of the times. the goal isn't to implement the same DOS for all architectures, but to have some sort of DOS that provides some functionality and otherwise stays out of the pr ☝︎

a111: Logged on 2019-04-05 23:02 OriansJ: bvt: Actually DOS wouldn't be the correct direction as it is actually more complex to implement portably and it's abstraction layer isn't right for a good general bootstrap.

spyked: that is, for whatever architecture it's implemented on, it doesn't have to be the same DOS

a111: Logged on 2018-04-16 15:20 mircea_popescu: the best example i can think of is the code on the old handheld calculators. THAT is a general purpose os : it makes no assumption about the downstream, merely fully, cleanly and directly exposes the hardware.

diana_coman: it seems quite surprising to me there isn't more interest but tbf I haven't used local WU ever, would need to even look it up, lol. ☟︎

OriansJ: Mocky: floating point support is part of being turing complete. We can either bitch about how bad it is (Like the old MIPS engineers) or accept the reality and figure out a why that costs us the least. ☟︎☟︎

Mocky: and in addition you suggested floating point as software addon. turing completeness can now be achieved after the fact! ☟︎

OriansJ: spyked: well the iCE40 is a good starting point for now and I guess we can agree on that. You are right about not having to be portable but I prefer building a stack that can be used to defend against a Nexus Intruder program class attack.

OriansJ: Mocky: yes that was my point; floating point will either exist in hardware or software because of Turing completeness. ☟︎

OriansJ: So we can either make simulating more complex instructions in software easy or we can shoot ourselves in the foot trying to avoid the unavoidable (The ability to support floating point)

OriansJ: and let us be honest here; making it easy to trap on undefined instructions, jumping to a software routine that performs the functional definition of that instruction and returning to right after the trapped instruction. Will allow us to ditch instructions in hardware without fear of breaking our bootstrap. ☟︎

OriansJ: Mocky: Don't get stuck on the idea of Floating point, it is just an example of classes of instructions that are complex to implement in hardware that a proper illegal instruction trap will allow us to move between hardware and software with no one else having to care what we are doing. As we want people programming to standards not to systems. ☟︎

BingoBoingo: diana_coman: WU is not. Normal bank wires work. WU is offered as an option because it works for people inside the wire sending to LATAM. Unsure how smooth WU UK would be.

diana_coman: tbf unsure how smooth either wire or wu would be from UK given additional currency headache; hence my hesitation to add this one to the to do list but by the looks of it, if this continues with no real bids even on quite competitive prices, I guess I'll have to.

diana_coman: last time I used WU was ~10 years ago and it was from EU to USA so not much help for current use case

BingoBoingo: hanbot's Costa Rica to Uruguay via WU experiment ended up going through a channel other than WU, so the suspicion is Intra-LATAM WU is fucked

auctionbot: Buy order # 1046: 500 WFF, WU esta bien Heard: 140mn from jurov outbidding PeterL. Ending: 2019-04-07 12:12:39.925433 UTC (26 hours 26 mins)

asciilifeform: http://btcbase.org/log/2019-04-05#1907008 << asciilifeform is quite curious re what 'ideas in posix worth preserving', i can't think of even one ☝︎

a111: Logged on 2019-04-05 22:53 OriansJ: BingoBoingo: I agree POSIX has a great many flaws but there are some ideas inside of it worth preserving; especially in regards to bootstrapping.

asciilifeform: http://btcbase.org/log/2019-04-05#1907021 << 'dos' as typically discussed here is simply shorthand for 'os that fits in coupla kB and gets the fuck out of the way and speaks only when spoken to' , roughly ☝︎☟︎

asciilifeform: http://btcbase.org/log/2019-04-05#1907023 << whytheFUCK wouldja want the nullterm-string warcrime to exist on a brand-new arch ? ☝︎☟︎

a111: Logged on 2019-04-05 23:03 OriansJ: well the only extremely useful feature for bootstrapping hardware architectures have is clean encoding and a sane subset of operations that make working with strings and structs easy to do in assembly.

asciilifeform: http://btcbase.org/log/2019-04-05#1907027 << why would 'compat with x86' be ANY kind of consideration ? ☝︎

a111: Logged on 2019-04-05 23:06 OriansJ: although if one wanted good backwards compatability with x86 and the rest; simply add load/store instructions that work on little endian data

asciilifeform: http://btcbase.org/log/2019-04-05#1907037 << i recommend to read the logs re 'specificity' ( picture yourself baking a sabotaged fpga , for victim whose gate net you do not know in advance. what would you put in it ? ) ☝︎☟︎

a111: Logged on 2019-04-05 23:38 OriansJ: As for the operating system floor; there is a micro-posix subset that might be of interest as it would be enough for bootstrapping full operating systems but not complex enough to have anything non-deterministic.

a111: Logged on 2019-03-26 20:05 asciilifeform: bvt: the other thing, is the 3-ring circus aspect of elaborately dethompsonizing a box in order to... bring up 1M+line of linusolade

asciilifeform: i.e. whole problem of 'bootstrap', imho, is misformulated . why to fixate on thompsonism and then bring up multi-decamegabyte kernel fulla liquishit, on which to run overflowandcrashlang (aka 'c') compiler with which to then build moar of same, etc

asciilifeform: http://btcbase.org/log/2019-04-06#1907042 << all of these archs were missing essential piece for sanity -- type tagging and bounds checking. ( i.e. if running ada or lisp 'costs extra' on your iron vs. c , your arch is broken ! ) ☝︎

a111: Logged on 2019-04-06 00:52 OriansJ: The Branch Delay slot should never been allowed and it just adds complexity to any bootstrap. The Multiply and Divide instructions of MIPS were just a bad idea and the DEC Alpha solution was a much better combination to go. The Exception style overflow pattern in MIPS is pure complexity and waste; the 68K series was so much closer to the optimal (The split Integer register and BCD support was a bad mistake that I am glad Cold Fire

asciilifeform: and yes, 'branch delay slot' is retarded. as is the whole pipeline concept. ( why ? cuz http://www.loper-os.org/?p=300 . sane iron FIRST, and ~then~ can ~maybe~ think about speed. )

asciilifeform: http://btcbase.org/log/2019-04-06#1907058 << this is where i say 'wtf' . what am i missing here ? where and for what do you need the ieee erroneous-arithmetics liquishit ?! ☝︎

a111: Logged on 2019-04-06 12:41 OriansJ: Mocky: floating point support is part of being turing complete. We can either bitch about how bad it is (Like the old MIPS engineers) or accept the reality and figure out a why that costs us the least.

asciilifeform: http://btcbase.org/log/2019-04-06#1907066 << people who demand oddball instructions, can simply write own fpga payload and go happily on own path -- what am i missing ? ☝︎

a111: Logged on 2019-04-06 12:52 OriansJ: and let us be honest here; making it easy to trap on undefined instructions, jumping to a software routine that performs the functional definition of that instruction and returning to right after the trapped instruction. Will allow us to ditch instructions in hardware without fear of breaking our bootstrap.

feedbot: http://pizarroisp.net/2019/04/06/pizarro-march-2019-report/ << PizarroISP -- Pizarro March 2019 Report

OriansJ: asciilifeform: no where did I say null terminated strings; it could be length prefixed strings but support for strings needs to exist in a human readable bootstrap. ☟︎

asciilifeform: OriansJ: imho the place for it ( just as for e.g. bignums, arrays, other basics ) is in the iron

asciilifeform: OriansJ: why exactly should overrunning string, or array, etc bounds be electrically possible ?

asciilifeform: it aint even as if no one ever built sane iron, and it is being proposed for 1st time

OriansJ: We can always add complexity and provide mechanisms for supporting additional complexity but but typed memory isn't exactly easy to bootstrap in hex

asciilifeform: it goes into the iron, you dun need to bootstrap it as such, beyond applying mains current

OriansJ: There are very good reasons why typed memory systems appeared after high level languages did. ☟︎

OriansJ: asciilifeform: Your level of bootstrap is considerably higher level than mine. I assume I have to hand toggle in the root binary and hand assemble everything.

asciilifeform: OriansJ: possibly we are speaking at cross purposes. having eaten the log, i formed impression that OriansJ is interested in hypothetical sane iron, and not merely dethompsonization of x86 pc.

asciilifeform: i'm not currently sure that there is in fact any overlap between these two problems

OriansJ: Sane Iron is a great goal that I believe needs to be done but I also believe that a chain of trust needs to be built to allow Sane Iron to be safe from some classes of attacks.

asciilifeform: re 'classes of attack', i'm particularly curious re what is OriansJ answ to http://btcbase.org/log/2019-04-06#1907086 puzzler ☝︎

a111: Logged on 2019-04-06 21:51 asciilifeform: http://btcbase.org/log/2019-04-05#1907037 << i recommend to read the logs re 'specificity' ( picture yourself baking a sabotaged fpga , for victim whose gate net you do not know in advance. what would you put in it ? )

a111: Logged on 2017-02-24 02:36 asciilifeform: veen: let's try a historical angle. according to legend, emperor qin shi huangdi (same d00d as known for taking the 'immortality pill' and promptly croaking) had a palace with 1,500 rooms. and would not tell anyone in advance which one he plans to sleep in on a given night. and which ones he would put cutthroats in, ready to kill anyone who opens door. think 'minesweeper.'

asciilifeform: OriansJ: let's posit. what does this give you, if you do not know what is connected to the i/o pins ? beyond ability to short +v to - and smoke

asciilifeform: ( if this counts as a useful attack, why not answer instead 'coupla gram of thermite' ? )

OriansJ: well lets see, we can add a short wave radio but that might be blocked with tempest hardware layers

OriansJ: we can include a hardware block for network and leverage it if it is connected; while letting our customers know about it speeding up network loads

asciilifeform: leverage how ? if you have literally 0 info re what netlist will be loaded and what cells it will make use of, and to what end

OriansJ: asciilifeform: all FPGAs have hardware blocks specific to certain function to speed up common functionality

asciilifeform: observe that it is entirely trivial to permute given netlist so that 9000 manufactured boards will each have unique one, with same function

BingoBoingo: OriansJ: On possibly missing prior is that should the work take us there, in this channel the question of fabbing our own hardware (Maybe on saphire wafers) is largely one of "when?"... provided we live to see it.

asciilifeform: OriansJ: not all. matter of fact, the 1 used in http://nosuchlabs.com/hardware.html has no dedicated cells, aside from i/o

asciilifeform: OriansJ: i specifically picked the part for this attribute. ( ice40 was not 'solved' yet at the time , but it has quite similar topology )

OriansJ: asciilifeform: so the Fab knows those cells will be for I/O and we know some common patterns of I/O that we can eletrically detect

asciilifeform: the puzzler concerns 'general purpose' sabotaged fpga, rather than case where you know what the victim intends to connect and what protocols etc ☟︎

OriansJ: asciilifeform: that is absolutely correct; an attacker in Silicon can only put in attack hooks for things that they know about not all possible inputs.

OriansJ: However we know common patterns for networked devices, Operating systems and external storage systems

asciilifeform: the irons that speak these 'common patterns' -- already sabotaged decade+ ago, no need even to concern with fpga..

OriansJ: asciilifeform: well some of these patterns are universally useful and will exist even in Sane Iron systems ☟︎

asciilifeform: OriansJ: incidentally, a pattern matcher on i/o pin will affect propagation delay

asciilifeform: OriansJ: if i'm baking e.g. dram refresher -- then quite easily (and very frustratingly, in actual practice did, it is why it is ~impossible to bake a decent dram controller from scratch using fpga that hasn't been 'solved' ice40-style )

OriansJ: asciilifeform: DRAM initialization has a very unique pattern which can be detected very early (long before the DRAM itself is ready)

OriansJ: Let us just assume the FPGA was not compromised and leverage it for the bootstrap work at this stage (I'll be going to pure LibreSilicon before I am finished but hey to each their own) ☟︎

asciilifeform: correct. so, proposing to put 64-state statemachine on each pin and look for it? and what, slip the timings so dram loses bits ? this is in the 'smoke' category, logic analyzer will find the peculiar defect, and victim buys another fpga.

asciilifeform: OriansJ: i am not proposing it as 'boostrap for pc', but as ~replacement~ for pc.

OriansJ: asciilifeform: I am good with that as well; provided we actually bootstrap it properly

asciilifeform: and specifically as illustration of the physical limits of thompsonism, in the abstract

OriansJ: So, perhaps the most important question what has been actually decided about Sane Iron and what still needs definition? ☟︎

OriansJ: asciilifeform: it is a project for open source lithography, it currently is at the 1 micrometer process node and limited to around 1 million transistors at this time

OriansJ: asciilifeform: sadly they haven't given that yet but let us just assume Industry costs (say $10K) per wafer

asciilifeform: looking at the 'process steps' docs in the linked page, it seems to be a straight wikipedization of ordinary schoolbook description of ic fab process ☟︎

asciilifeform: i.e. there is nothing there to suggest that the author has discovered a peculiarly cheap method of fabbing ic

OriansJ: asciilifeform: It isn't about cost because a Custom IC can be done for under $10K today in a 45nm process

asciilifeform: OriansJ: the french already offer 8k (iirc) for 400nm . this is not the problem.

asciilifeform: right, the problem is specifically that it's happening somewhere other than my kitchen. ☟︎

asciilifeform: and i do not see anything in the linked recipe to suggest a kitchenable process.

OriansJ: asciilifeform: It is a guide for groups of people to pool together resources and setup a 1 micrometer fab to generate trusted chips. Yes it is far from optimal but it is a step in the right direction. ☟︎

asciilifeform: what asciilifeform is looking for, re ic fab breakthrough, is specifically a process that would be to ic what the cd recorder was to cd

asciilifeform: OriansJ: what if my definition of 'trusted chip' is specifically where i own the gear and no other people are involved at any stage ?

OriansJ: asciilifeform: something tells me you would be more excited about Xerox's plastic transistor technology

OriansJ: asciilifeform: honestly, the chemicals and the patents are still a mess in that field plus the never could produce a chip that could exceed 100khz ☟︎

asciilifeform: OriansJ: re patents, there's plenty of folx living in free world, who will piss on whatever patent simply for the pleasure of the piss

OriansJ: asciilifeform: well we can either wait for others to perform miracles or we can get off our asses and make them for the world to see. ☟︎

asciilifeform: OriansJ: 'open source' folx have a professional disease, where they succumb to temptation of redefining a difficult problem into a non-equivalent but easier one

OriansJ: asciilifeform: back to my previous question. What actual really useful thing has been created in regards to Sane Iron so far?

a111: 20 results for "bolix ivory", http://btcbase.org/log-search?q=bolix%20ivory

asciilifeform: vendor supplied lisp, ada, fortran, even c, compilers , which interoperated to the point of safely calling proggy written in 1, from another

asciilifeform: i have the orig. paper docs, they fill a bookcase, but they're actually all mirrored there.

asciilifeform: vendor killed itself via 'enron'-level mismanagement, imploded , so not much known about today outside of specific circles of sane-iron enthusiasts.

OriansJ: ok; do we have software simulators such that people can start developing software for it while we solve the hardware side of the question?

asciilifeform: OriansJ: there's an emulator , though not a cycle-accurate one . asciilifeform is (slowly) gathering the seekrits needed for cycle-accurate reproduction of the orig.

OriansJ: asciilifeform: we don't need cycle-accurate; we just need good enough to be able to write the pieces that will run on it directly ☟︎

asciilifeform: largely to experiment with the orig. os , it was an item quite far ahead of what today is taught as 'state of art'. but the iron also imho is good starting point for hypothetical sane iron.

asciilifeform: OriansJ: you wouldn't want to build a new comp that replicates it entirely. for one thing, iirc could only address 256M , with no possib of expansion

asciilifeform: from pov of this thread, it is a practical example that sane (i.e. typechecking & boundschecking of ALL memory accesses) iron in fact existed, and even fit in 1980s vlsi (2um)