News for hackers. Stuff that matters.
Re:Paper Processor – What is fetch, decode, and execute? by Razengan on Sunday May 29, 2016 @12:40AM (#11794829)
While we're at it, why not use that opportunity to experiment with alternative fundamentals, like ternary or quaternary (like our DNA I suppose) instead of binary, or further explore things like belt architectures [1].

I see no reason why we should forever stick with things the way they are, just because they seemed simple to implement at the time. The trend you mention could be a chance to reinvent computers, as it were.

[1] https://en.wikipedia.org/wiki/Mill_CPU_Architecture#The_Belt...

Re:Paper Processor – What is fetch, decode, and execute? by nickpsecurity on Sunday May 29, 2016 @01:10AM (#11794903)
Possibly. I brought up ternary or quaternary to hardware guys on Schneier's blog. I considered them since they shouldn't be much harder to work with than Boolean. In theory. That led me to two reasons that Boolean prevailed over most: simple rules allowed easy transformation and verification by computers; just two states means you can aim for high noise immunity at the gate level vs one with more precision required for its analog implementation.

However, there is research in the other stuff. Here is one of the papers I found:

http://facta.junis.ni.ac.rs/eae/fu2k51/bundalo.pdf

There were also other types of logic used in digital with interesting advantages. Two good ones, one for speed and one for reliability, are below. I particularly found the computer made with diode logic to be pretty amazing.

https://en.wikipedia.org/wiki/Emitter-coupled_logic

https://en.wikipedia.org/wiki/Diode_logic

https://en.wikipedia.org/wiki/D-17B

Re:Paper Processor – What is fetch, decode, and execute? by oasisbob on Sunday May 29, 2016 @01:41AM (#11794987)
Don't forget ternary content addressable memory (TCAM), which is common in contemporary network routers because it turns out having a third state to mean "don't care" is incredibly useful:

https://en.wikipedia.org/wiki/Content-addressable_memory#Ter...