Slashdot Mirror

On further research, some static RAM chips do retain data (though not all of them). If you really need the data blanked out, storing it in a D-type flip flop might be better then.

The article is very slim on details and dead wrong on some important facts.

The gate can be used the squeeze the electron channel to nothing without the use of junctions or doping.

The lack of a junction is not unique, ever heard of a MOSFET, "There is no pn junction, so there is no depletion region."

And I'm curious how they induce conductivity in silicon without dopants, considering that silicon is a semiconductor and a "semiconductor is a material that has an electrical conductivity between that of a conductor and an insulator", therefore "conductivity may easily be modified by introducing impurities into their crystal lattice" via doping.

And the article includes one other statement that is questionable in my opinion...

We have designed and fabricated the world's first junctionless transistor that significantly reduces power consumption ... Another key challenge for the semiconductor industry is reducing the power consumption of microchips. Minimising current leakage is one of the main challenges in today's complex transistors

Gate leakage is an issue but the true bane of transistor power consumption is Rdson (resistance drain to source when transistor is on). The reason for the massive heat sinks and fans on processors today is not due to gate leakage its due to the resistance of the transistor channels and the various interconnects.

Current flowing through the resistive channel and internconnects in the millions of transistors in a processor generates heat for the same reason that a basic carbon based resistor connected to a voltage source will heat up. And increasing the doping level in the gates and poly silicon interconnects reduces resistance, with no doping it seems the problem of power loss through heat generation will only be worse.

The article is somewhat interesting and perhaps it is just a bad article lacking significant detail.

You don't do it with a CPU. You do it in hardware with a digital counter, like this:

http://www.play-hookey.com/digital/ripple_counter.html

Dividing by two is easy -- just take the output of one of the flip-flops. Dividing by other numbers can be done by connecting the flip-flop outputs and/or their complements to an AND gate. This requires some extra circuitry and wiring, but in an integrated circuit the overhead will be insignificant. Even in a discrete circuit, if you make the reference 2^32Hz (~4.2GHz), you're only looking at maybe two counter ICs to divide down to 1Hz, although no counter IC I know of can handle a 4GHz signal.

The real issue with using this would be whether your manufacturing process can make transistors fast enough for it. The quote in the summary suggests this will be popular in an analog role for high-frequency applications like wireless. Maybe we'll see discrete timing references too.

Be sure to check out the analog computer museum, among others

And don't forget about relay logic

SRAM is also much bigger. DRAM bits are just capacitors with calculated (and designed-in) characteristics coupled with a single gate. SRAM bits are flip-flops. Note that they are each (at least of the three or four types on that page) made of eight gates. That's a lot of real estate for a single bit, I'm guessing two to four times as much (depending on the size of the capacitor...)

From a source of unknown and possibly questionable repute:

However, C was (and is) still highly useful and well worth keeping around, so a sort of extended C language was developed. This language was essentially "C and then some", or C-plus (C+). As the concepts of object-oriented programming continued to develop, C+ had to be upgraded, and became C++.

So I'm not the only one who was mistaken.

But with a little more research we find out Ch is C+. Not what I was thinking of, but interesting in its own way.

There is also a Small C+ sublanguage for developing on the Z88 portable computer. I haven't been able to find anything specifially about Small C+, but it seems to just be C with support for the proper address size on the Z88.

Of course, none of this is really what I thought I was talking about.
After spending a bit of time trying to vindicate myself, it looks like what I remember as C+ is actually a set of headers to implement object oriented-ness in C. This project is a little bit newer than I thought, but is probably what my brain was triggering on.

That's fairly typical; indeed I usually find that most of the time is taken with lightspeed delays; and in congestion.

As a general comment, not aimed specifically at WolfWithoutAClause, also remember that "lightspeed" is only 300,000 km/s in a vacuum, which only applies for the most part if you're looking at a satellite relay (which will travel through mostly vacuum). Fiber-optic's lightspeed is on the order of 200,000 km/s, a full 33% less (reference), which will cause even more delays.

Do a ping across the country and take into account the fact that light is only doing 66% of the speed in a vacuum, and by and large latencies on non-busy servers aren't going to get much better, barring FTL communication networks. Traveling 2000 miles at 124,000 mi/s is going to take 16 ms, period, coming back equally long, and that's 32 ms just to cross the country (USA) right there, not the 20 ms a naive light-speed calculation would give. (And of course it's not like a single piece of fiber is run across, there's delays for hopping and other things.)

Do all the math and normal Internet latencies are as good as they are ever going to get, unless you're hitting traffic problems, barring certain things which as far as we know are impossible.

Please note that the recording industry thinks they can change this sort of thing, by requiring all analog to digital converts (ADCs) to respect some sort of digital protection

I find it hard to imagine how a simple DAC circuit could be "improved" to support DRM. But even a circuit like this would be required to support DRM, no?