[HN Gopher] The Surprising Story of the First Microprocessors (2...
___________________________________________________________________
The Surprising Story of the First Microprocessors (2016)
Author : areoform
Score : 51 points
Date : 2021-09-16 05:23 UTC (1 days ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| Rochus wrote:
| > _Transistors, the electronic amplifiers and switches found at
| the heart of everything from pocket radios to warehouse-size
| supercomputers, were invented in 1947._
|
| Is this true? Recently this article
| https://people.idsia.ch/~juergen/turing-oversold.html pointed to
| the following invention of the field-effect transistor from 1925:
| https://patents.google.com/patent/US1745175
| causi wrote:
| There's a difference between patenting an idea and actually
| building a working device.
| Rochus wrote:
| The claim in the article was "invented in 1947"; a patent is
| by definition granted for an invention, regardless whether a
| working device was built or not.
| analog31 wrote:
| As I understand it the patent is only valid if it shows
| that the idea can be reduced to practice.
| pacificmint wrote:
| Someone got a patent for a warp drive [1], so I don't
| think being actually possible is a requirement for
| patents.
|
| [1] https://patents.google.com/patent/WO2001057881A1/en
| Rochus wrote:
| No. It must be novel, non-obvious and "useful", which
| obviously was considered to be fulfilled by the patent
| office. The patent describes how the invention can be
| used instead of tubes.
| analog31 wrote:
| Doesn't there need to be a preferred embodiment? Not
| debating, just curious.
| Rochus wrote:
| I have not studied the content of the patent, but the
| "Cited by" list includes the Who's Who of the industry;
| so the invention seems to be relevant.
| xyzzy21 wrote:
| The patent exists but NOTHING was done with it and nothing was
| brought to market or practical use.
|
| Ideas are cheap and worthless - it's the execution that
| matters. That execution in the context of a patent is a viable
| product or use.
|
| MOSFETs were NOT viable until the 1960s. RCA made the first
| practical metal-gate CMOS that is known as the "4000 series" of
| logic parts. And even then, that technology didn't take off
| until all the other problems of mobile ions, threshold tuning,
| etc. were finally solved to give us CMOS as we know it today.
|
| There are always wankers who point to this patent, but it
| really doesn't matter because it took another 50 years to
| achieve anything that mattered.
| Rochus wrote:
| > There are always wankers ...
|
| Gutter language does not make the argument more convincing.
| approxim8ion wrote:
| I'd argue that tone policing doesn't refute the argument
| either.
| dragontamer wrote:
| https://en.wikipedia.org/wiki/Crystal_detector
|
| The cat-whisker detector is commonly described as the first
| solid-state device, discovered in 1874, patented in the early
| 1900s, and used in various experimental radios through the
| development of radio technology at that time.
|
| Its not a "modern transistor design", but its solid state, its
| through a semiconductor... and its one step away from reliably
| amplifying. Its kinda funny that the physics to understand this
| thing were developed after its invention...
| cxr wrote:
| > Although both patents were granted, no records exist to prove
| that Heil or Lilienfeld actually constructed functioning
| devices. <https://www.computerhistory.org/siliconengine/field-
| effect-s...>
| Rochus wrote:
| It's still an invention by definition (patent law). Thanks
| for the article; notably the article makes no doubt that the
| invention by Lilienfeld would have worked; apparently he just
| didn't build it himself.
| xyzzy21 wrote:
| But it means nothing. People patented perpetual motion
| machines throughout the 19th and 20th centuries. So does
| that make the patent meaningful? NO!
| Rochus wrote:
| Apparently this is an emotional topic; personally I have
| no stakes in it (besides that I'm a trained electrical
| engineer and had lectures in patent law), I'm just
| curious; Colby sent me this link which describes an
| experiment where they built Lilienfelds device in the
| nineties:
| http://public.gettysburg.edu/~bcrawfor/BECrawford-MS-
| UVM.pdf
| ggm wrote:
| Some simple maths:
|
| 4004 had 2.5k transistors. 8008 had 3.5k. z80 had <10k
| transistors.
|
| A modern 4 core ARM chip has 16b transistors, in 122mm^2 die
| area. So, if we scale current die area for 16b transistors to a
| Z80, on 10k, we get 1.6m scale factor. 122mm^2 scaled down 1.6m
| times. 16 x 10^9 / 1 x 10^4 == 1.6 x 10^6 == 1.6m
|
| This size is of course slightly preposterous, but if we accept
| there is some linearity in die scaling at current VLSI scale, it
| becomes clear a Z80 will fit inside a hypodermic needle. Its
| within the size of current technology, to be injectable. Power
| would have to be an external RF source, or maybe we can exploit
| brownian motion, or have a motile tail and do some kind of
| strained-crystal voltage, run asynch clock, we can also do a tail
| for WiFi and do power and signal through RF.
|
| Injectable VLSI is a research space. It has great potential for
| in-vivo monitoring. Subcutaneous, or intravienous is a detail at
| this point. (note, this is quite different to the boring RFID
| sealed in some bubble which people get subcutaneous, thats been a
| thing since pet-chipping and before. I'm talking active
| electronics here)
|
| We maybe can't all suffer the bill gates injected 5G nightmare,
| but we could play a mario gameboy, inside our bloodstream. (The
| original gameboy was a custom CPU modelled on a Z80)
|
| I'm fully vaxxed for C19. I wonder if I can hear the "tetris"
| theme inside...
| flohofwoe wrote:
| I wonder how much performance we got out of the 1.6m scaling
| factor. I'd guess somewhere between 10k and 100k faster, but
| nowhere near a million times?
| rnentjes wrote:
| I would like to see that number as well, I actually expect it
| to be a lot more than a million.
|
| Take 1000 times the clock rate, 4 cores, multiple
| instructions per clock instead of multiple clocks per
| instruction. Operations on 64 bits i.o 8 and the Z80 doesn't
| even have multiply or divide operators and would need to loop
| and add to do a multiplication/division. And then think about
| things like ARM SIMD instructions.
| flohofwoe wrote:
| True, but can multiple cores, pipelining, etc... really
| make up for another factor of 1000x? And most of this
| complexity exists because memory latency couldn't keep up.
| zsmi wrote:
| Doesn't quite work like that. If the die needs to interact with
| the world, it needs a pad ring. That's a lot larger.
|
| It will basically be like this die when students placed a small
| MIPS core.
| http://pages.hmc.edu/harris/cmosvlsi/4e/lect/lect2.pdf (See
| slide 29)
|
| But the center will be a whole lot emptier.
| amenghra wrote:
| https://en.wikipedia.org/wiki/Fantastic_Voyage
| jcun4128 wrote:
| One thing that's scifi but would be cool is "smart sand". Using
| tiny parts that communicate with each other/interlock. Form
| larger units.
| timonoko wrote:
| Smart sand that learns like neural nets. Recipe goes like
| this: Mix semiconducting grains and metal and solder bits.
| Apply electric pattern at one end of the bucket and shake the
| bucket until some useful pattern appears at the other end.
| Then you apply much higher current between those patterns.
| Solder bits melt and form more permanent neural routes.
| Repeat until the device works as expected.
| TeMPOraL wrote:
| Obligatory raining on the parade: small enough smart sand
| might be a cancer risk, the way asbestos is (suspected to
| be)[0] - apparently our bodies really don't like having
| small, stiff objects poking at it from inside, causing
| mechanical damage.
|
| That said, I'm all for "smart sand" and programmable matter.
| IIRC, the tricky bits are in making the individual smart
| particles to stick to each other, and then making them behave
| in a coordinated fashion.
|
| It's an interesting challenge to think about: you have a
| thousand, or a million, small little robots - how to get them
| to do something useful as a group? If the robots can barely
| sense their environment, can barely move on their own, can't
| communicate with each other except maybe their nearest
| neighbors - how to make them work together in a controlled
| fashion? Say, I have this bag of "smart sand", I pour it on a
| table and want it to form into a cube when I press "Enter" on
| my laptop - how do I translate a bulk concept like "cube
| shape" into instructions for a random pile of tiny robots?
|
| Does anyone know of good papers dealing with this problem?
|
| --
|
| [0] - https://en.wikipedia.org/wiki/Health_impact_of_asbestos
| #Mech...
| Wildgoose wrote:
| I remember reading of a primitive unicellular organism that
| can link up with its fellows and become mobile, searching
| for water sources if I recall correctly.
| jcun4128 wrote:
| Yeah I was thinking about it, the particles would have to
| be able to transfer power to each other by contact. If it's
| a problem of corrosion maybe through induction. And some
| particles are specialized eg. an IMU or a battery, etc...
| spatial would depend on external direction probably IMU
| combo. But the manufacturing would be insane... scale and
| then hopefully it's cheap enough it could be like dirt. In
| the end what is it for, is it strong structurally.
| Clustering compute of each particle would be interesting
| too.
|
| Anyway at least you can model/simulate it, that would be a
| cool thing to design/program.
| evgen wrote:
| > It's an interesting challenge to think about: you have a
| thousand, or a million, small little robots - how to get
| them to do something useful as a group?
|
| This was a big focus of a lot of the ALife research in the
| late 90s and early aughts. Cellular automata, swarming
| systems, etc. You can generally start with anything coming
| out of University of New Mexico and bounce around the
| citation graph of an interesting-sounding paper. You might
| also want to check out Dave Ackley's T2 Tile project and
| some of the youtube videos he has put out over the past few
| years. One thing he is very clear about is addressing
| robustness in the face of component failure (e.g. his
| 'Moveable Feast Machine' and 'Demon Horde' stuff is rather
| fun to watch as it responds to random and widespread
| failures.) Most of the work in this area is clearly bio-
| inspired, but why re-invent the wheel when you can steal
| from the best available examples...
| hnlmorg wrote:
| I guess in the same way you orchestrate any cluster of
| bots: you give each an ID, design your structure on your
| server and then and then pass those instructions to the
| bots.
|
| They wouldn't be aware of each other in any "smart" way but
| you'd want to keep the logic as low as possible on the
| nodes so you have less compute power to miniaturise.
| TeMPOraL wrote:
| I feel that's not robust enough - what if some of your
| bots are missing? When we're talking millions of
| microscopic robots, I think we need to assume that many
| will break down, get misplaced, or be in a position
| disadvantageous for it to fulfill a designated role. A
| robust system cannot rely on all the robots in a
| predetermined ID range/set to be there - it needs to work
| with what's actually available.
|
| Ideally, I imagine being able to point at a random pile
| of robots and make that pile do something, without
| knowing any of the IDs or health of individual cells up
| front.
|
| So I wonder, is there a way to design the system in such
| a way that individual robots don't need to be
| micromanaged, but instead they self-assign to the
| appropriate role/place, without having full knowledge of
| the shared goal?
|
| Imagine those experiments in making shapes from sand with
| standing audio waves, e.g. [0]. The grains of sand have
| no identity and no awareness. The person setting up the
| experiment doesn't care about what any individual grain
| of sand does. They just set up a pattern, encode it in a
| standing wave, and the sand moves to conform to it. I'm
| wondering if this kind of approach is possible, except
| with the robots moving on their own instead of being
| moved by air. And, as a next step, with a pattern being
| persisted in the pile of robots, instead of being
| supplied externally.
|
| --
|
| [0] - https://www.youtube.com/watch?v=wvJAgrUBF4w
| Wildgoose wrote:
| Similar to "flocking" behaviour in birds that only
| requires notice to be taken of immediate neighbours in
| the flock.
| TeMPOraL wrote:
| Yes, something like that - and I'm wondering if there's a
| way to imprint a pattern on such flock of birds, so that
| they then flock into appropriate shape from whatever
| starting configuration they were in, and maintain the
| shape over time, even in the face of strong winds or some
| of the flock members dying.
|
| Here's one idea I'm thinking about: flocking-like
| equations in "boids" simulations are local, a pure
| function of (the observed state of) the neighbors. In a
| typical implementation, they just compute
| velocity/acceleration vectors out of
| position/velocity/acceleration/class of the neighbors[0].
| And the result are pretty, fluid, and _uniform in steady-
| state_ flocks. But what if we added more observable state
| and equations to this?
|
| Imagine each boid having a "color", a value that is a
| function of not just the color of the neighbors, but also
| of their position/velocity/acceleration/class. And then,
| the equations computing velocity/acceleration take this
| color into account too, e.g. by offsetting the result by
| some function of the neighbors' colors. Could we then
| design the f([colors]) -> v/a offset and f([everything])
| -> color functions so that they end up forcing the flock
| into an arbitrary uniform shape? I believe we could, but
| I'm not sure how to define these functions for any
| _particular_ shape.
|
| (Or, in short: I'm looking for a method to turn an
| arbitrary picture into an error term for boids rules that
| makes the flock assume the shape of the picture, instead
| of an uniform blob.)
|
| I'm sure there must be some pre-existing theoretical work
| behind finding such functions - this problem feels like a
| cousin of the "find a formula that draws a target picture
| on X/Y plot". I just don't know the right keywords to
| look this up.
|
| But this is kind of the idea on the back of my head -
| encoding desired group behavior in a function that is
| common to every member of the group and is entirely local
| (only a function of the immediate observed environment),
| but that forces the system to settle in a desired
| configuration.
|
| --
|
| [0] - "class" being e.g. member of same species, a
| predator, or a prey.
| TheOtherHobbes wrote:
| I don't think that would work. Bloxels would need to know
| their location in the grid. And any kind of closed object
| would cause problems because bloxels would only adhere to
| the surface, not build up bulk inside.
|
| Maybe better would be a kind of 3D printing model, where
| the shape is 2D and changes over time, which leads to
| accretion of a 3D shape.
|
| Even so - without feedback and monitoring you'll get
| errors and holes.
|
| And you'll still have the problem that unless you're
| using some novel form of programmable electrostatic
| bonding, adhesion between bloxels will be weak.
|
| So you won't be able to do much with your finished shape
| except look at it. Probably not even pick it up, in fact.
| TeMPOraL wrote:
| > _Bloxels would need to know their location in the
| grid._
|
| That's the thing I'm trying to work around. If bloxels
| are like boids in the flocking simulations, they don't
| care about their location - they move and change state
| based on the movement and state of their neighbors. In
| the flocking simulations, boids automatically form stable
| shapes and recover from disruptions, and none of them
| have assigned positions or even any kind of unique
| identifier. It's the repulsion and attraction functions -
| identical in every boid - that determine the steady state
| shape of the flock.
|
| That said, I think there's a way for bloxels to tell
| where they are in their "flock". Imagine each bloxel
| continuously publishing a "depth" value that's computed
| as e.g. length of the vector \Sigma_{n}^{Neighbors}:
| Depth(n) x DirectionTo(n). The values would initially
| fluctuate, but I feel it's possible to set this up so
| that over short time the system will settle, with every
| boid's "depth" value being a correct indication of how
| far it is from the centre of the group. So e.g. upon
| activation, a pile of bloxels could wait for "depth"
| values to stabilize, and then each bloxel would remember
| its value as its designated position, and execute some
| different algorithm with that bit of state fixed.
|
| Note to self: there's a bunch of free "agent-based
| simulation" programs I saw on the Internet the other day;
| such "depth" calculation should be a simple thing to
| simulate and verify.
|
| Related keyword: phase-locked loops. See also: fireflies
| that synchronize their flashing patterns over time.
|
| > _And any kind of closed object would cause problems
| because bloxels would only adhere to the surface, not
| build up bulk inside._
|
| Why can't they build up bulk, using each other for
| support?
|
| > _Maybe better would be a kind of 3D printing model,
| where the shape is 2D and changes over time, which leads
| to accretion of a 3D shape._
|
| I'm not sure what you mean. That sounds like regular 3D
| printing using "dumb" matter?
|
| > _Even so - without feedback and monitoring you 'll get
| errors and holes._
|
| Bloxels would be active and reacting to each other - this
| is a feedback-full system.
|
| > _unless you 're using some novel form of programmable
| electrostatic bonding, adhesion between bloxels will be
| weak_
|
| I have no good ideas here. I don't know of any
| programmable bonding system that isn't too energy
| intensive to use with current technology. AFAIK
| electromagnets are power hogs. Mechanical locking systems
| are also energy intensive, and also tricky to use
| (maneuvering the mating endpoints to meet, compensating
| torque, etc.)
| Wildgoose wrote:
| Yes. Imagine that the "boids" change colour as well as
| alter their X, Y, Z position. That supplies additional
| "guiding" information to provide purpose and also alter
| behaviour, in much the same way that hormones act on a
| growing foetus.
|
| And this reminds me of those audience experiments with
| people holding up blue and red cards and using this
| "vote" to successfully steer a vehicle.
| TeMPOraL wrote:
| Yup. Also nothing says the boids have to execute a single
| behavior all the time.
|
| In a parallel comment, I described an idea where boids
| first start doing nothing except publishing a "depth"
| value that's a function of their neighbors "depth" value,
| waiting for the system to settle (as detected by
| neighboring values not changing by more than some fixed
| epsilon over some fixed Dt). They could then record their
| individual values and continue to a second algorithm
| (e.g. traditional "boids"), that uses this (now fixed)
| "depth" value as a parameter.
|
| This is, in general, a pattern for individual unit to
| discover their role in the group, without ever knowing
| the whole group. I just realized this sounds like things
| the field of "distributed consensus" deals with - I'll
| add that to my research list.
|
| I remember the voting games and "Twitch plays X" events.
| It's kind of a different situation (external controllers
| voting on control input to a single actor), but there
| might be some parallels.
| hnlmorg wrote:
| It might be worth first reading up on the research being
| drone performances. The current model is basically what
| I'd already described
| (https://eandt.theiet.org/content/articles/2021/04/there-
| s-no...) but research is happening to use "AI" to
| navigate swarms (eg
| https://www.youtube.com/watch?v=7KIa9FlmbRc)
|
| The real problem with such research is it might work on a
| quadcopter with room for a chipset capable of relatively
| powerful real time compution (be that an off the shelf
| CPU or something more bespoke), but that doesn't scale
| down to the grain of sand level. At that point you'll
| want to offload as much computation overhead as you can.
| Which, again, brings me back to my original post.
|
| Maybe one day in the distant future (if we haven't
| annihilated each other first) we'll have the technology
| to built smart grains of sand. But it's seems pointless
| theorising about something that might just as easily be
| deprecated by some other fantasy device by our current
| technological capabilities.
|
| Anyhow, if you're after a paper on the actual
| calculations you'd run to convert a database of nearest
| neighbour coordinates into a matrix that can be used to
| instruct those robots, then I don't have anything
| directly to hand on that. When I've looked this stuff up
| in the past I've found most of the time it was
| proprietary. Maybe there is a paper I've missed. However
| I have seen papers doing similar work (in the sense that
| there is transferable logic) in a two dimensional fields,
| eg matrix reordering.
| TeMPOraL wrote:
| Thanks! I haven't thought about drone performances. In
| retrospect, it's a good starting point. I've seen plenty
| of videos of drone swarms being synced up to produce
| shapes and animations.
|
| > _Maybe one day in the distant future (if we haven 't
| annihilated each other first) we'll have the technology
| to built smart grains of sand. But it's seems pointless
| theorising about something that might just as easily be
| deprecated by some other fantasy device by our current
| technological capabilities._
|
| Maybe. But I feel this isn't pointless - I find myself
| constantly returning to this topic whenever I follow
| seemingly unrelated avenues of idle curiosity (e.g. "how
| to build self-maintaining systems", "how to do in-orbit
| construction" , "how to get rid of household cleaning
| chores", "how to build a food replicator", "ooh isn't
| biotech kind of fun", etc.). I think we'll eventually
| start building "smart matter" at _some_ scale. Might be
| nanometer. Might be millimeter. Might be meter. Each of
| those scales has its own physics regime, but I think the
| concepts behind self-organization will be common. And we
| 're already working on those ideas when studying biology
| at molecular and cellular level.
|
| > _When I 've looked this stuff up in the past I've found
| most of the time it was proprietary._
|
| Do you remember any names? Might be that some of the
| research is released. Or maybe my employer has access.
|
| > _However I have seen papers doing similar work (in the
| sense that there is transferable logic) in a two
| dimensional fields, eg matrix reordering._
|
| Thanks, I'll look it up.
| hnlmorg wrote:
| > _I feel that 's not robust enough - what if some of
| your bots are missing? When we're talking millions of
| microscopic robots, I think we need to assume that many
| will break down, get misplaced, or be in a position
| disadvantageous for it to fulfill a designated role. A
| robust system cannot rely on all the robots in a
| predetermined ID range/set to be there - it needs to work
| with what's actually available._
|
| Nothing about what I posted assumes that. I'm just saying
| it's the server that would orchestrate them rather than
| them orchestrating each other. The server would obviously
| poll them for positional data (relative to neighbour),
| health status, etc.
|
| > _The person setting up the experiment doesn 't care
| about what any individual grain of sand does. They just
| set up a pattern, encode it in a standing wave, and the
| sand moves to conform to it._
|
| I didn't suggest that someone manually plots each grain
| either. Clearly you'd just set up a design in a CAD and
| then let the server define the algorithm and
| orchestration required.
|
| Much like how when you manage nodes currently, you don't
| manually assign which node to scale up or down. You
| define rules and let the system manage the nodes itself.
|
| Given the problems of miniaturisation and decentralised
| computing, this feels like a problem easier solved in a
| centralised system that then hands out instructions (and
| your requirements clearly stated there was a control
| system that you used to instruct the grains of sand when
| you said "press enter on my laptop").
| gjvc wrote:
| https://en.wikipedia.org/wiki/Gray_goo
| gpderetta wrote:
| gray-goo is _self replicating_ smart sand.
| eru wrote:
| You won't be able to exploit Brownian motion.
|
| It's not about power (as in energy over time), but about free
| energy or entropy.
|
| Brownian motion is essentially just heat. In order to get any
| useful work out of heat, you need two different temperatures.
| amelius wrote:
| Why? Being bounced around by surrounding particles can be
| used to generate power. I once had a watch that could
| "recharge" by moving it.
| hypertele-Xii wrote:
| The motion that winds a self-winding mechanical clock is
| the swinging motion of an arm. Swinging motion is
| directional, back and forth, i.e. predictable. Indeed, the
| very self-winding mechanism is possible only because of
| this predictable movement.
|
| Brownian motion is literally random diffusion. By
| comparison, it'd be like vibrating the watch in every
| direction. It wouldn't wind from such motion. No known
| mechanism exists that would.
| steerablesafe wrote:
| The problem is that once the particles in your watch bounce
| around at the same rate (it is in thermal equilibrium with
| the environment) then it's statistically impossible to
| induce a net flow of energy from the environment into the
| device.
| xsor wrote:
| Unfortunately not, this was a famous problem taught by
| Feynman in his physics lectures. Essentially the Brownian
| motion of the ratchet and pawl mechanism (used in your
| watch) will eventually prevent the mechanism from
| harvesting energy [0].
|
| [0] - https://en.m.wikipedia.org/wiki/Brownian_ratchet
| hnlmorg wrote:
| A Z80 wouldn't be powerful enough to handle decryption of WiFi
| traffic. But it's an interesting thought
| twic wrote:
| You want a fuel cell that burns glucose for power.
| 908B64B197 wrote:
| I'm afraid the support structures around the chip didn't shrink
| at the same scale as the transistors.
| fake-name wrote:
| The issue with this is while the transistors for the CPU scale
| like that, the structures to do wireless transmission don't.
|
| If you go high enough in frequency that you can make it on the
| same scale as the CPU, you're in frequency ranges that are
| trivially absorbed by water. Which your device is surrounded
| by.
|
| Sure, you can just keep upping the power of the applied field
| to get enough energy to the chip to do something useful, but it
| has this messy side effect of causing heating. If you're OK
| with boiling the bodily fluids of person the chip is in, it'll
| work great!
|
| > note, this is quite different to the boring RFID sealed in
| some bubble which people get subcutaneous, thats been a thing
| since pet-chipping and before. I'm talking active electronics
| here
|
| RFID capsules _are_ active. That 's how they work. They're
| powered by inductive coupling into a coil in the device.
| Interestingly, their size is largely set by the power coupling
| requirements, so at least to some extent they are basically
| what you're trying to describe, only actually implemented
| within the constraints of reality.
|
| > Injectable VLSI is a research space.
|
| Lol
| kongin wrote:
| >The issue with this is while the transistors for the CPU
| scale like that, the structures to do wireless transmission
| don't.
|
| https://en.wikipedia.org/wiki/Dipole_antenna
|
| To go over it a bit more: the higher the frequency of
| radiation the smaller you can make the antenna. However in
| the frequencies we have the technology to send signals in,
| and don't intrinsically give you cancer, everything becomes
| more opaque when you increase frequency. As OP says, it's
| like trying to send a light flash from behind a concrete
| wall, when you can see it on the other side you're using
| enough energy to vaporise the concrete anyway.
|
| This is basically the only reason why we aren't living in a
| surveillance dystopia to make the Matrix look tame. Thank you
| physics for limiting the amount of possible surveillance from
| smart dust.
|
| That said, you could still use chemical or physical means of
| communicating with microchips inside you, the issue is that
| you're very limited in how much information you can send
| without having them come in contact with some type of
| macroscopic io device.
| neonate wrote:
| http://web.archive.org/web/20210917072141/https://spectrum.i...
| ableal wrote:
| Outstanding piece. Towards the end, Ken Shirrif has a good
| discussion around this: _" [...] Still others would allow these
| functions to be packaged in a few chips, which would collectively
| make up the microprocessor.[...]"_
|
| Along those lines, there was also a set of "bit-sliced" chips
| from AMD, which looked very interesting:
| https://en.wikipedia.org/wiki/AMD_Am2900
|
| P.S. The "Mick & Brick" book: https://www.amazon.com/Bit-slice-
| microprocessor-design-John-...
| FullyFunctional wrote:
| needs a [2016] in the title
___________________________________________________________________
(page generated 2021-09-17 23:01 UTC)