There is free cutting-edge software development going on. Lots of it. The only problem is that when you try to tell anyone about it, they reply "Sure, but what's the point?" By the time most people realise something is important, it isn't really cutting-edge any more...:^)
Sounds like an excellent thing to collect! Anything that is so common and cheap that it is disposable can become very valuable indeed if you keep a copy in good condition for a few years. This is because very few other people will do so, and yet the number of people who will appreciate the thing is fairly large. (this has happened in the past with other comics, books, fine art, furniture, etc. so there's no reason to suppose it won't happen again.) And it's not even a difficult or expensive thing to get into doing...
Oh yes. Especially from Brazil and South Korea (though not so much of those today, thanks to the DDoS over the weekend that took out a fair bit of the core 'net.) Which just left the field open to those spamming in what would nominally be called English.
If only spammers would always spam me in Korean, it'd be ever so easy to block...:^/
These techniques have been known for quite a while, but they are quite viable. A few points of note:
The major commercial excitement about asynchronous hardware derives from the facts that it has much lower electromagnetic emissions (no great big synchronous clock pulse) and it can stop and start on a dime (HALT instructions are cheap and really do save power.) These make asynch. hardware very interesting for people working in embedded and portable environments.
Amulet3i is a fully asynchronous processor core which provides a standard programming interface by being machine-code compatible with the ARM - you don't notice that it is asynchronous except when you do crazy things like varying the power from 1V to 5V, or by popping a load of dry ice on it, and even then the chip "takes a licking and keeps on ticking!" The speed of the ticks just changes a bit.
Experience with Amulet at Manchester indicates that asynchronous logic is competitive with synchronous logic of the same generation in terms of speed, though it can be designed by a much smaller team of engineers.
The hardest part of it all is definitely tools since there are a lot of very good tools out there for synchronous development. I'm working on this, but it doesn't happen overnight!
There are also a lot of different design methodologies around, so when people say asynchronous, they are really referring to a whole bunch of different technologies as opposed to the single tech that is synchronous design. Some of these technologies scale much better than others. For example, petri-nets are very good at very low-level design, but they don't scale up very well and are a pig to actually use. OTOH, micropipelines (which is what Sutherland is working with, though he's looking more at the low-level end of them) are much less close to optimal at the transistor level (i.e. it takes more effort to squeeze out the last drop of efficiency) but they scale up to whole CPUs and even entire computers much better. Speaking as someone who's designed toy processors that way. (OK, so I've not the patience to go through and implement a whole pre-defined instruction set - I only did it one week as a proof-of-concept.:^)
It is far easier to compose micropipelines with each other since you have no setup-and-hold timing nonsense. Those restrictions which do exist tend to be pretty easy to spot, and we've developed tools for automatically checking for the main async. design bloopers.
Did you know that during the design phase for the Amulet3i, benchmarking was done by running real operating systems (RiscOS IIRC; nowadays we'd use ArmLinux instead) and applications (ghostscript, rendering the tiger picture) on it in simulation?:^)
A couple of years ago, a workman with a road-drill hit the 33kV supply to the city-block where I work. Apparently the ensuing explosion was something to behold, and put the guy in hospital (which happened to be one of the institutions worst hit by the power failure...:^) However, it was at that point that we discovered just how inadequate our building's UPS system was, since our network went completely belly-up and every machine in the whole building needed a hard-reset to recover (including all the file, database and NIS+ servers.)
Just as my uptime was starting to get impressive too...
The UK already uses energy caches, a.k.a. pump-storage hydro schemes. They are incredebly expensive to build, are not very efficient, but work. Alas, they can only store a few minutes power at full output, and their only major advantage is that they can come on-stream in a few seconds (limited by the amount of time it takes for a large water column to fall through a mountain, I believe...)
In my experience, it is harder to analyse a twenty LoC C program working at the assembler level than a 20kLoC C program at source level. (Yes, I've done this.)
Also, it is possible for not only the compiler to have obfuscated backdoors, but also the debugger, decompiler and code-dump utility. Hell, if you monkey around with the OS enough, you can create a file which contains code that cannot be viewed using any tool but which can execute and contain any backdoor you care to name. Of course, that's a scenario only for the paranoid, and it would be very difficult to exploit in any systematic way too. You would also be able to use 'cat' to strip the offending code...:^)
Slashdot Mirror
There is free cutting-edge software development going on. Lots of it. The only problem is that when you try to tell anyone about it, they reply "Sure, but what's the point?" By the time most people realise something is important, it isn't really cutting-edge any more... :^)
Sounds like an excellent thing to collect! Anything that is so common and cheap that it is disposable can become very valuable indeed if you keep a copy in good condition for a few years. This is because very few other people will do so, and yet the number of people who will appreciate the thing is fairly large. (this has happened in the past with other comics, books, fine art, furniture, etc. so there's no reason to suppose it won't happen again.) And it's not even a difficult or expensive thing to get into doing...
I wonder if it would be easy to use this to keep my coffee mug hot? Too easy to forget to drink occasionally until it's gone cold and nasty...
If only spammers would always spam me in Korean, it'd be ever so easy to block... :^/
Just as my uptime was starting to get impressive too...
The UK already uses energy caches, a.k.a. pump-storage hydro schemes. They are incredebly expensive to build, are not very efficient, but work. Alas, they can only store a few minutes power at full output, and their only major advantage is that they can come on-stream in a few seconds (limited by the amount of time it takes for a large water column to fall through a mountain, I believe...)
In my experience, it is harder to analyse a twenty LoC C program working at the assembler level than a 20kLoC C program at source level. (Yes, I've done this.)
:^)
Also, it is possible for not only the compiler to have obfuscated backdoors, but also the debugger, decompiler and code-dump utility. Hell, if you monkey around with the OS enough, you can create a file which contains code that cannot be viewed using any tool but which can execute and contain any backdoor you care to name. Of course, that's a scenario only for the paranoid, and it would be very difficult to exploit in any systematic way too. You would also be able to use 'cat' to strip the offending code...