38200+ entries in 0.021s
OriansJ: Ethernet frames need
to look like
this and Serial buffers need
to behave like
this
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
OriansJ: BingoBoingo: I am
thinking libresilicon which we could do
today
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.
OriansJ: asciilifeform: all FPGAs have hardware blocks specific
to certain function
to speed up common functionality
OriansJ: well lets see, we can add a short wave radio but
that might be blocked with
tempest hardware layers
OriansJ: a hardware rom and a remote
trigger
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.'
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 ? )
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.
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.
OriansJ: There are very good reasons why
typed memory systems appeared after high level languages did.
☟︎ 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
OriansJ: bootstrap hardware should not have any features
that are not absolutely required.
OriansJ: asciilifeform:
those conversions should be software NOT hardware
OriansJ: asciilifeform: just use a generic block
type for range checking
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.
☟︎ 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.
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.
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
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
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-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)
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
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.
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.
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.
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
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
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.
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.
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.
☟︎ Mocky: whoever wants can write
their own. why start with idiocy in mind
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.
☟︎ Mocky: "someone will certainly want X"
therefore "we make X easy"; mno
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: Mocky: yes
that was my point; floating point will either exist in hardware or software because of
Turing completeness.
☟︎ Mocky: I've gotta run
though, worn motorcycle
tire needs wrangling
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.
Mocky: and in addition you suggested floating point as software addon.
turing completeness can now be achieved after
the fact!
☟︎ 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.
☟︎☟︎ 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.
☟︎ diana_coman: BingoBoingo: is WU
the only option for
those wff?
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.
spyked: that is, for whatever architecture it's implemented on, it doesn't have
to be
the same DOS
spyked: ogrammer's way most of
the
time
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:
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: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)
Mocky: OriansJ: why
the hell support floating point at all?
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: 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: 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: 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: 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: 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: 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)
☟︎☟︎☟︎ bvt: i guess asciilifeform will comment
tomorrow if he feels good enough (gute besserung!); i have
to go
to sleep right now
bvt: yes, with
tape writers/serials, os can be delayed much further; persistent storage would complicate bootstrap a lot.
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, i agree
that a simple and clear boot sequence is a requirement
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
☟︎ 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
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: although if one wanted good backwards compatability with x86 and
the rest; simply add load/store instructions
that work on little endian data
☟︎ 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: 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)
BingoBoingo returns
to Accounting and Spanish Practice lair
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.
☟︎ 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: 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.
☟︎☟︎ 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.