4 ms·
It's just a very, very optimized & elegant design. Reminds me of this: He had located the data he was working on near the top of memory --- the
by generalizations 2y ago
It's just a very, very optimized & elegant design. Reminds me of this:
He had located the data he was working on
near the top of memory ---
the largest locations the instructions could address ---
so, after the last datum was handled,
incrementing the instruction address
would make it overflow.
The carry would add one to the
operation code, changing it to the next one in the instruction set:
a jump instruction.
Sure enough, the next program instruction was
in address location zero,
and the program went happily on its way.
And it's not like our own transistors aren't probabalistic when you look closely enough.
- JoeAltmaier 2y agoAnecdote: had an 8086 system-call jump table that fielded up to 64K calls, but using a jump table of 4K. Address mode was segment:offset where segment was 17 bits and offset 16, but shifted by 4. The table consisted of the same trap instruction throughout, which took 4 bytes. If I remember it all right. Anyway the system call trap examined the caller stack, found the return address (to the trap table), picked out the combination of segment and offset used to construct a system-call index. Following so far? We went paged. Changed syscall segment to indirect, 16 segment descriptors all mapped to the start of the jump table. Started failing on one particular system call out of thousands - it would page fault! Why? The auto-increment and prefetch of the trap opcode in the jump table would fault, for only one syscall, the one that mapped to the last entry in the trap table where the offset came out to 0FFC. Wrapped to 1000, which with that particular segment meant next-page! Which was unmapped (system trap table was in low memory, alone). My solution: change the syscall index for that operation to something else, and document in the syscall comments to never use it.
- roywiggins 2y agoIf a computer running a probabilistic calculation got it right 90% of the time, and the next one over running the same calculation on identical hardware got it right 10% of the time, there would be something wrong with the computer. This is not true with cells.
- generalizations 2y agoYour point only stands when the percentages are exaggerated. What if it were 99.99 vs 99.999? Let's not forget cosmic ray bitflips. Just because the two machines operate at different levels of probabalistic exactitiude, does not mean they are not both machines. Do you really think modern computers are fully deterministic at the lowest levels?
- roywiggins 2y agoCells behaving randomly is a fundamental part of their ordinary operation. Computers are tractable because we've done our best to engineer out the randomness and, when we can't, layer on enough error correcting codes so we can mostly not think about it. But cells don't operate on such nicely bifurcated scales (small and random vs large and mostly predictable). If they did, the dream of cellular wiring diagrams allowing cells to be understood would be a lot more achievable.
- generalizations 2y agoYour example of randomness upthread was brownian motion: I'm not surprised a transport mechanism relies on stochastic behaviors. To me, that looks comparable to electrons bouncing down a wire, or minimizing quantum tunneling effects between transistor layers - random at a very low level, but averages out to the behavior we need. Put guardrails at the extremes, so the random behavior stays within bounds, within a margin of error - that's just good engineering. Compare to loggers, floating trimmed trees down a river to the sawmill: the logs bouncing down the river are behaving in an entirely random manner, but it's within bounds and doesn't matter, because they'll still make it downstream where they get caught by another system. It's a "machine" with random behaviors. Maybe this (obligatory) xkcd illustrates my point: https://www.explainxkcd.com/wiki/index.php/2916:_Machine https://www.explainxkcd.com/wiki/index.php/2916:_Machine I get the impression that what this is coming down to is massive complexity rendering the machine incomprehensible - but again, that doesn't mean it isn't a machine.
- roywiggins 2y ago