Forum logs for 05 Apr 2019

Monday, 16 March, Year 12 d.Tr. | Author:
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) [03:14]
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) [08:36]
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 [12:51]
bvt: !!up OriansJ [18:04]
deedbot: OriansJ voiced for 30 minutes. [18:04]
OriansJ: !!register http://wotpaste.cascadianhacker.com/pastes/Ppnt8/?raw=true [18:11]
deedbot: BDA9B87D4B1F46D4D5616035212E02A02E1A8FB7 registered as OriansJ. [18:11]
bvt: !!rate OriansJ 1 stage0 author [18:13]
deedbot: Get your OTP: http://p.bvulpes.com/pastes/6ojPb/?raw=true [18:13]
bvt: !!v 3E663D0A962864DA7A238FA8497667A046916568FA36ED6112CEAE9C25A9FBAE [18:14]
deedbot: bvt rated OriansJ 1 << stage0 author [18:14]
OriansJ: So I hear there is some interest in bootstrapping architectures here [18:17]
OriansJ: !!up [18:20]
deedbot: You may not $up yourself. [18:20]
bvt: indeed there is the relevant thread is http://trilema.com/forum-logs-for-18-mar-2019#2525665 [18:22]
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 [18:22]
bvt: so far everything points into the direction opposite of linux/c (http://mocky.org/Log-Reference-Why-Ada/ may be interesting) [18:24]
bvt: of course, ada/gnat is too complex for bootstrapping as-is, but i guess equivalent safety properties would be still required [18:25]
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. [18:26]
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 [18:31]
BingoBoingo: !!up OriansJ [18:43]
deedbot: OriansJ voiced for 30 minutes. [18:43]
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 [18:44]
OriansJ: thank you BingoBoingo [18:44]
BingoBoingo: diana_coman put together a crypto library, ave1 has a leaner GNAT, and asciilifeform has a bignum library and other products. [18:45]
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 [18:45]
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. [18:46]
BingoBoingo: The constant time bignum work helps to inform the crypto work [18:47]
BingoBoingo: http://www.loper-os.org/?cat=49 << FFA, the author asciilifeform is dealing with a fever, but he is usually around [18:48]
BingoBoingo: !!rate OriansJ 1 Loaning voice [18:48]
deedbot: Get your OTP: http://p.bvulpes.com/pastes/LN8mM/?raw=true [18:49]
OriansJ: Linux is much too big for a bootstrap core piece [18:49]
BingoBoingo: !!v 8733D65D9BE134634734EDA7D4BD9D91B09A1BB8D6A1370D7CCE24EA546CEE30 [18:49]
deedbot: BingoBoingo rated OriansJ 1 << Loaning voice [18:49]
BingoBoingo: Indeed Linux is. [18:49]
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. [18:50]
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? [18:51]
BingoBoingo: Eventually the direction seems to be leading it towards burning the whole stack down, POSIX and all. [18:52]
BingoBoingo: But we have people deploying things in the present and the things have to have something while the burning continues. [18: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. [18:53]
bvt: http://btcbase.org/log/2019-04-05#1906987 << well, this depends on the subset of ada re contributors - this is a known issue [18:55]
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. [18:55]
BingoBoingo: This isn't quite an area I'm incredibly specialized in, hopefully others can chime in. [18:55]
BingoBoingo: OriansJ: Anyways, with my rating you can voice yourself by sending a private message to deedbot [18:55]
OriansJ: Thank you BingoBoingo [18:55]
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? [18:57]
bvt: i.e. re 1 you opted for architecture where instruction encoding is easy to do by hand [18:57]
bvt: but are there any other features that help the bootstrap? even if this increases hardware complexity a bit [18:58]
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. [18:58]
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 [18:59]
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. [19:00]
bvt: re 1, both worth using (but no lisp cpus here yet) and with features useful for bootstrapping [19:00]
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. [19:02]
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) [19: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. [19:03]
* BingoBoingo returns to Accounting and Spanish Practice lair [19:03]
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) [19:03]
OriansJ: Big Endian instruction and data encoding seem the most obvious great ideas for simplifying the task of bootstrapping (especially in regards to troubleshooting) [19: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 [19:06]
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 [19:08]
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 [19:11]
bvt: re add with carry, http://www.loper-os.org/?p=1913#selection-2329.9-2347.129 [19:12]
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 [19:12]
bvt: yes, i agree that a simple and clear boot sequence is a requirement [19:13]
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. [19:18]
bvt: yes, with tape writers/serials, os can be delayed much further persistent storage would complicate bootstrap a lot. [19:21]
bvt: (iirc asciilifeform has a SU keyboard-driven prom burner, which may be a valuable device for bootstrap) [19:22]
bvt: i guess asciilifeform will comment tomorrow if he feels good enough (gute besserung!) i have to go to sleep right now [19:22]
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) [19:25]
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. [19:38]
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. [20:07]
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 [20:45]
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 [20:45]
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 [20:52]
OriansJ: fixed) [20:52]
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) [21:00]
OriansJ: well good night [21:21]
Mocky: OriansJ: why the hell support floating point at all? [21:31]
Category: Logs
Comments feed : RSS 2.0. Leave your own comment below, or send a trackback.
Add your cents! »
    If this is your first comment, it will wait to be approved. This usually takes a few hours. Subsequent comments are not delayed.