diana_coman: asciilifeform, hope you get well soon! and no, don't get to delirium (or even serious shivers as that's likely to come first anyway)
auctionbot: Buy order # 1046: 500 WFF, WU esta bien Heard: 150mn from PeterL. Ending: 2019-04-07 12:12:39.925433 UTC (59 hours 30 mins)
feedbot: http://qntra.net/2019/04/gps-disciplined-time-to-experience-undisciplined-event-this-weekend/ << Qntra -- GPS Disciplined Time To Experience Undisciplined Event This Weekend
bvt: !!up OriansJ
deedbot: OriansJ voiced for 30 minutes.
deedbot: BDA9B87D4B1F46D4D5616035212E02A02E1A8FB7 registered as OriansJ.
bvt: !!rate OriansJ 1 stage0 author
deedbot: Get your OTP: http://p.bvulpes.com/pastes/6ojPb/?raw=true
bvt: !!v 3E663D0A962864DA7A238FA8497667A046916568FA36ED6112CEAE9C25A9FBAE
deedbot: bvt rated OriansJ 1 << stage0 author
OriansJ: So I hear there is some interest in bootstrapping architectures here
OriansJ: !!up
deedbot: You may not $up yourself.
bvt: indeed there is; the relevant thread is http://btcbase.org/log/2019-03-18#1903170
a111: Logged on 2019-03-18 15:31 asciilifeform: http://bvt-trace.net/2019/03/mes-part-1-stage0/#selection-29.94-29.340 << imho ~100% of the attempts on record , made exactly same mistake -- they assumed that 'architecture-specific aspects creep into the design of the boostrapping process' only concerns ~what is there~ in the arch, and not ~what is not there~ (e.g. sane memory management, type tags) . if you dun put the complexity of certain necessary sanities where it belongs -- i
bvt: so far everything points into the direction opposite of linux/c (http://mocky.org/Log-Reference-Why-Ada/ may be interesting)
bvt: of course, ada/gnat is too complex for bootstrapping as-is, but i guess equivalent safety properties would be still required
OriansJ: bvt: well to be honest, an Ada subset would be much easier to implement than a C subset; the problem however is always available contributors.
OriansJ: To be honest if it wasn't for wanting to support developers who use division; M2-Planet wouldn't have even included support for it and honestly bootstrap hardware really doesn't need that complexity
BingoBoingo: !!up OriansJ
deedbot: OriansJ voiced for 30 minutes.
BingoBoingo: OriansJ: Well right now we have some people working on flensing a minimal linux from Gentoo-MUSL and other people building utilities in ADA
OriansJ: thank you BingoBoingo
BingoBoingo: diana_coman put together a crypto library, ave1 has a leaner GNAT, and asciilifeform has a bignum library and other products.
OriansJ: BingoBoingo: well I guess we need to discuss short term vs long term expectations as those pieces seem to be multiple pieces pulling in different directions
BingoBoingo: Well, they tend to build on each other. The Linux (dubbed Cuntoo) is to escape all of the distributions constantly changing the base and tools.
BingoBoingo: The constant time bignum work helps to inform the crypto work
BingoBoingo: http://www.loper-os.org/?cat=49 << FFA, the author asciilifeform is dealing with a fever, but he is usually around
BingoBoingo: !!rate OriansJ 1 Loaning voice
deedbot: Get your OTP: http://p.bvulpes.com/pastes/LN8mM/?raw=true
OriansJ: Linux is much too big for a bootstrap core piece
BingoBoingo: !!v 8733D65D9BE134634734EDA7D4BD9D91B09A1BB8D6A1370D7CCE24EA546CEE30
deedbot: BingoBoingo rated OriansJ 1 << Loaning voice
BingoBoingo: Indeed Linux is.
BingoBoingo: But gotta have a fairly hygenic platform to build things from and deploy them on, so trinque has been working on capturing a hygenic and stable one.
OriansJ: well let me ask it this way; are you planning to use a posix subset or a subset which will portable upon posix and other OS bases?
BingoBoingo: Eventually the direction seems to be leading it towards burning the whole stack down, POSIX and all.
BingoBoingo: But we have people deploying things in the present and the things have to have something while the burning continues.
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.
bvt: http://btcbase.org/log/2019-04-05#1906987 << well, this depends on the subset of ada; re contributors - this is a known issue
a111: Logged on 2019-04-05 22:26 OriansJ: bvt: well to be honest, an Ada subset would be much easier to implement than a C subset; the problem however is always available contributors.
BingoBoingo: This isn't quite an area I'm incredibly specialized in, hopefully others can chime in.
BingoBoingo: OriansJ: Anyways, with my rating you can voice yourself by sending a private message to deedbot
OriansJ: Thank you BingoBoingo
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: i.e. re 1 you opted for architecture where instruction encoding is easy to do by hand
bvt: but are there any other features that help the bootstrap? even if this increases hardware complexity a bit
OriansJ: 1) Did you mean in regards to minimal hardware requirements or the set which would make it a host platform worth using after the bootstrap is done and 2) Generally a higher level language such as Ada or C.
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
OriansJ: bvt: well believe it not; previously most architectures were easy to encode by hand (PDP-11, PDP-10, Vax, 6502, z80, 8086) but MIPS changed the game by showing with high enough languages one can be brain dead in regards to human understanding of the encoding rules and squeeze a drop of extra performance out.
bvt: re 1, both worth using (but no lisp cpus here yet) and with features useful for bootstrapping
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.
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)
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.
BingoBoingo returns to Accounting and Spanish Practice lair
OriansJ: actually I am extremely familiar with ARMv7's instruction encodings as I have been porting M2-Planet to it recently (boy it is a shitshow)
OriansJ: Big Endian instruction and data encoding seem the most obvious great ideas for simplifying the task of bootstrapping (especially in regards to troubleshooting)
OriansJ: although if one wanted good backwards compatability with x86 and the rest; simply add load/store instructions that work on little endian data
OriansJ: an 8bit immediate can be very useful for dense code and it would fit most bootstrapping constants if it is signed; support for 16, 32 and up immediates makes supporting compilers for C/Ada easier to write but it isn't a real issue if you have support for IP relative loads of 32bit and up values
OriansJ: add with carry (in, out and in/out); substract with borrow (in, out and in/out) really simply the task of writing arbitrary precision libraries in assembly
bvt: re add with carry, http://www.loper-os.org/?p=1913#selection-2329.9-2347.129
OriansJ: If one doesn't want to have a boot rom; one needs either a hardware tape reader (which writes tape to memory on power on and jumps to address 0 to run it or a toggle board. A serial bus just moves the bootstrap trust issue to another piece of hardware
bvt: yes, i agree that a simple and clear boot sequence is a requirement
OriansJ: hence why I assumed a hardware mechanism for loading paper tape into memory and setting all registers to zero and then boot; as it eliminates the bootloader and the operating system entirely from the question.
bvt: yes, with tape writers/serials, os can be delayed much further; persistent storage would complicate bootstrap a lot.
bvt: (iirc asciilifeform has a SU keyboard-driven prom burner, which may be a valuable device for bootstrap)
bvt: i guess asciilifeform will comment tomorrow if he feels good enough (gute besserung!); i have to go to sleep right now
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)
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.
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: fixed)
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)
OriansJ: well good night
Mocky: OriansJ: why the hell support floating point at all?