They did it because they couldn't find a satisfactory chip for the machine they wanted to make. They wanted low and reasonably predictable interrupt latency - and remember, these were the days when CPUs for personal computers took between 3 and 20 clock cycles per instruction, and no cache - they wanted to maximise the use of memory bandwidth. The 6502 for instance typically was in a computer with 150ns memory, but would at full speed in a BBC Micro only fetch something from memory every 1000ns (fastest instruction 2 cycles). They looked at the National Semi 32016, but that had a multiply instruction that would take a staggering number of clock cycles (over 100!) which couldn't be interrupted, which would lead to very bad memory bandwidth utilization, unpredictable and poor interrupt latency. Steve Furber said in one of his talks that the interrupt latency was so poor with the 32016 they would only be able to support single density floppy discs without needing additional hardware (i.e. added cost) to buffer the data.
They were inspired by the simple design of the 6502 and decided they could do something similar but 32 bits. Hence the ARM. When the ARM came out most of its instructions would execute in a single CPU cycle (versus the 68000, which would often take 8 cycles or more), and had very low interrupt latency. I remember using a PC emulator on an original ARM system (an Archimedes) running at something like 8MHz. The emulator would run faster than the original IBM PC despite being on a computer with less than double the clock speed and having to emulate not just the CPU but the screen and other peripherals.
They most certainly were designing chips in the 80s. The ARM was designed by Steve Furber (hardware) and Sophie Wilson (instruction set), both founding employees of Acorn.
Acorn needed to move off the 6502, and they explored several different architectures for the new computer they wanted to build. They wanted very low interrupt latency, and they wanted a chip that could use all of the memory bandwidth - back in 1986, the processors for a personal computer were generally much slower than memory and had no cache, for example, the MC68000 takes often 8 or more clock cycles per instruction and doesn't have a cache, the 6502 takes 3 to 4 clock cycles per instruction at 1MHz etc. In particular, Steve Furber (designer of the original ARM chip) was horrified by the Nat. Semi 32016 (if I remember right) that had some instructions that took over 100 clock cycles to execute - and instructions cannot be interrupted while they are executing, so this would result in unpredictable and possibly very poor interrupt latency.
So they decided no one was making a chip they wanted for the price they wanted, so inspired by the simple design of the 6502, they decided to design the ARM. They wanted to make it cheap so it had to be in a plastic package, so it had to dissipate less than 1 watt. They had no tools to estimate power, so everything they did about the chip design was low power to make sure they hit their 1 watt target. When they got the first chips back from the fab (VLSI, if I remember right), they found they had massively overachieved, the ARM1 prototype dissipating only 0.1 watts.
The early processors were tested in a BBC Micro second processor box, but the real goal was to put them in their new computer, the Archimedes.
RiscOS still had the BBC BASIC interpreter (which included a built in ARM assembler). You could use BASIC in a RiscOS window pretty easily (it wasn't hidden), and there's a key combination to drop you out the GUI straight into the * prompt (and you could just type BASIC, and you'd have a full screen BASIC interpreter, just like the older BBC Micro).
That won't work with ARM though. The reason why so many people build ARM is that you can license the core and add whatever peripherals you want onto the die. Or you can license the whole architecture and design your own complete ASIC around it, like what Apple does.
With Intel, you get what Intel makes. You can't make your own custom Atom. You can't license the Atom architecture and make it part of your ASIC. You get only what Intel decides it wants to put on the die. So they can't even compete even way below cost price because they aren't offering the hardware manufacturer the same thing.
There's another timing perfect FPGA version (on a purpose designed PCB the size of the Raspberry Pi) coming out shortly called the ZX Uno. The Uno is based on the reverse engineering of the original ULA and as such is timing perfect.
It's been done. There are several timing faithful clones (based on Chris Smith's work on reverse engineering the ULA - he had the ULA die photographed and built the complete circuit diagram at the transistor level and an analysis of the complete circuit - search for the Spectrum ULA on Amazon and you can buy his book). You can buy a kit on the clone designed from this work - there's a thread currently on World of Spectrum Forums, and if you're quick you may still be able to get one.
Alternatively, on OpenCores, there is a Spectrum ULA in Verilog which was created from the same work. You can use this for a FPGA based clone.
If you want to build a modern recreation of the Speccy (absolutely timing perfect too) there's a clone called the Harlequin which was designed by a guy who recently reverse engineered the ZX Spectrum's Ferranti ULA and wrote a book about it. The book's great:
There's a thread on World of Spectrum Forums - a German member has arranged to get the components and PCBs to make a kit. He may still have a few going if you jump in soon:
Now those old crashy Issue 1 Spectrums are worth a great deal of money (the later (and much more numerous) more reliable ones aren't worth nearly as much)
Those behind the Kickstarter have already failed to pay the developers of games they used in their iOS emulators (despite signing contracts etc.). The company has liabilities almost as big as the Kickstarter and few assets. They still haven't demonstrated a real prototype (it wouldn't have been that hard for them to show an actual rubber key Spectrum case driving a Bluetooth HID module, but all that's been shown is a retail POS keyboard driving some emulated games).
I hope I'm wrong but I seriously doubt this will ever see the light of day.
There was no speculation involved. An expert witness (a team of embedded platform engineers) analysed the source code.
Not only did Toyota not follow MISRA C, they didn't even follow their own coding standards. Reading the source code showed recursion was being used and Toyota's own internal standards were not being followed (let alone MISRA C). An 800 page report was produced. If you dig into TFA a bit you can see the 45-odd page presentation that the expert witness gave to the course. The TLDR version of that presentation is that Toyota was grossly negligent in the way they developed this system.
The thing is an aggressor who launches a first strike is committing suicide even if you don't retaliate. The nuclear winter will kill them.
Recent studies have shown that the original 1980s nuclear winter theory was in actual fact optimistic, in reality had the USSR and NATO exchanged, "nuclear winter" would have been a misnomer, really "nuclear six month long night followed by 10 year nuclear winter" would be more accurate with daylight levels not even reaching that of a moonlit night. A simulation was also done concerning two subtropical aggressors (imagine India and Pakistan) each hypothetical combatant firing only 50 Nagasaki sized weapons at the other side. The resulting "nuclear autumn" would shorten the growing season sufficiently over the next year or two that while it would not threaten starvation or anything so drastic, food prices would end up sharply increasing due to lowered production.
Before anyone says "We tested thousands of weapons, many hundreds atmospherically and what about the Tsar Bomba, why didn't testing cause a nuclear winter?" - this is because the testing wasn't done by setting off hundreds or thousands of warheads in the space of one or two days on live, highly flammable (and hydrocarbon filled) cities. It's not the bombs themselves that cause the nuclear winter, but the thick soot lofted by burning cities, and our cities today are extremely flammable being full of hydrocarbon fuels and other petrochemical products that cause very nasty soot, along with traditional flammable materials such as wood. You could make the same effect if you caused firestorms in a few hundred cities in a period of 2 days with non-nuclear means.
Normally I would agree with you, but if you dig into TFA you can read the presentation the expert witness provided to the court. In this case it looks like Toyota was pretty negligent in the way they developed the firmware, violating not only industry standard coding practises but their own! The witness and his team produced an 800 page report on the shortcomings of Toyota's engine management system (he had full source code access).
But what motorcycles have that cars don't is a kill switch. Many modern cars with a start button and proximity key don't have a way of being turned off except by the button (i.e. software). My modern motorcycle has a start button and electronic everything, but it DOES have a kill switch. So if there was an unintended acceleration (and in the owner's forum for this bike, this has happened to at least one person when the throttle physically stuck on his bike after a spirited overtake) you can turn it off with the kill switch. Not so with a car. Why cars which only have software start and stop don't have a kill switch is puzzling (especially here in Europe where no one drives an automatic, so the engine will continue to be turned by the wheels if you kill the ignition, and will continue therefore to turn things like the power steering pump. If you're lumbered with an automatic gearbox the engine probably won't get turned so the steering will go very heavy but it will still function).
I'm embarrassed of the UK (my home country). It takes longer to get into the UK from Spain as a British citizen than it does to get into the United States (which is famous for its slow immigration lines) as a British citizen. While the rest of Europe is opening up, the UK is insisting on "tougher checks" largely because of the whining of trashy newspapers like the Daily Mail who hates everyone not British (and hates a significant subset of British citizens too). They were even talking about getting rid of the Common Travel Area meaning you wouldn't even be able to enter the UK from Ireland or one of the British islands like the Isle of Man or Channel Islands without a passport check.
Frankly it's embarrassing. The UK should be in the Schengen agreement along with the rest of the EU instead of wasting our time with pointlessly drawn out border checks to make little Englanders feel happy.
That's precisely what happened in the UK. Go to somewhere like Liverpool Airport and you can jump the security queue by paying a fee called "fast track".
You have to reduce what Facebook paid a bit, in reality. Most of what they paid for Whatsapp was paid not in money, but in hugely overinflated Facebook stock. They "only" paid $4bn in cash.
But of course most of this purchase was made with massively overvalued Facebook stock, not actual cash. I think "only" 4 billion or so was cash, the rest was inflated Facebook stock.
You probably did the boni thing just to troll, but we speak English, not Latin. Latin is a dead language (as dead as dead can be - it killed the ancient Romans, and now it's killing me...)
In English, it's bonuses. The plural of virus is viruses. The plural of nexus is nexuses. We don't speak Latin, plurals from a dead language aren't needed in English.
Slashdot Mirror
They did it because they couldn't find a satisfactory chip for the machine they wanted to make. They wanted low and reasonably predictable interrupt latency - and remember, these were the days when CPUs for personal computers took between 3 and 20 clock cycles per instruction, and no cache - they wanted to maximise the use of memory bandwidth. The 6502 for instance typically was in a computer with 150ns memory, but would at full speed in a BBC Micro only fetch something from memory every 1000ns (fastest instruction 2 cycles). They looked at the National Semi 32016, but that had a multiply instruction that would take a staggering number of clock cycles (over 100!) which couldn't be interrupted, which would lead to very bad memory bandwidth utilization, unpredictable and poor interrupt latency. Steve Furber said in one of his talks that the interrupt latency was so poor with the 32016 they would only be able to support single density floppy discs without needing additional hardware (i.e. added cost) to buffer the data.
They were inspired by the simple design of the 6502 and decided they could do something similar but 32 bits. Hence the ARM. When the ARM came out most of its instructions would execute in a single CPU cycle (versus the 68000, which would often take 8 cycles or more), and had very low interrupt latency. I remember using a PC emulator on an original ARM system (an Archimedes) running at something like 8MHz. The emulator would run faster than the original IBM PC despite being on a computer with less than double the clock speed and having to emulate not just the CPU but the screen and other peripherals.
They most certainly were designing chips in the 80s. The ARM was designed by Steve Furber (hardware) and Sophie Wilson (instruction set), both founding employees of Acorn.
Not quite accurate.
Acorn needed to move off the 6502, and they explored several different architectures for the new computer they wanted to build. They wanted very low interrupt latency, and they wanted a chip that could use all of the memory bandwidth - back in 1986, the processors for a personal computer were generally much slower than memory and had no cache, for example, the MC68000 takes often 8 or more clock cycles per instruction and doesn't have a cache, the 6502 takes 3 to 4 clock cycles per instruction at 1MHz etc. In particular, Steve Furber (designer of the original ARM chip) was horrified by the Nat. Semi 32016 (if I remember right) that had some instructions that took over 100 clock cycles to execute - and instructions cannot be interrupted while they are executing, so this would result in unpredictable and possibly very poor interrupt latency.
So they decided no one was making a chip they wanted for the price they wanted, so inspired by the simple design of the 6502, they decided to design the ARM. They wanted to make it cheap so it had to be in a plastic package, so it had to dissipate less than 1 watt. They had no tools to estimate power, so everything they did about the chip design was low power to make sure they hit their 1 watt target. When they got the first chips back from the fab (VLSI, if I remember right), they found they had massively overachieved, the ARM1 prototype dissipating only 0.1 watts.
The early processors were tested in a BBC Micro second processor box, but the real goal was to put them in their new computer, the Archimedes.
RiscOS still had the BBC BASIC interpreter (which included a built in ARM assembler). You could use BASIC in a RiscOS window pretty easily (it wasn't hidden), and there's a key combination to drop you out the GUI straight into the * prompt (and you could just type BASIC, and you'd have a full screen BASIC interpreter, just like the older BBC Micro).
That won't work with ARM though. The reason why so many people build ARM is that you can license the core and add whatever peripherals you want onto the die. Or you can license the whole architecture and design your own complete ASIC around it, like what Apple does.
With Intel, you get what Intel makes. You can't make your own custom Atom. You can't license the Atom architecture and make it part of your ASIC. You get only what Intel decides it wants to put on the die. So they can't even compete even way below cost price because they aren't offering the hardware manufacturer the same thing.
There's another timing perfect FPGA version (on a purpose designed PCB the size of the Raspberry Pi) coming out shortly called the ZX Uno. The Uno is based on the reverse engineering of the original ULA and as such is timing perfect.
It's been done. There are several timing faithful clones (based on Chris Smith's work on reverse engineering the ULA - he had the ULA die photographed and built the complete circuit diagram at the transistor level and an analysis of the complete circuit - search for the Spectrum ULA on Amazon and you can buy his book). You can buy a kit on the clone designed from this work - there's a thread currently on World of Spectrum Forums, and if you're quick you may still be able to get one.
Alternatively, on OpenCores, there is a Spectrum ULA in Verilog which was created from the same work. You can use this for a FPGA based clone.
Or the Microsoft Surface keyboard...
If you want to build a modern recreation of the Speccy (absolutely timing perfect too) there's a clone called the Harlequin which was designed by a guy who recently reverse engineered the ZX Spectrum's Ferranti ULA and wrote a book about it. The book's great:
http://www.amazon.co.uk/The-ZX...
There's a thread on World of Spectrum Forums - a German member has arranged to get the components and PCBs to make a kit. He may still have a few going if you jump in soon:
http://www.worldofspectrum.org... (go to near the end of the very long thread)
Also there is a Verilog HDL description of the ZX ULA on OpenCores (based on Chris Smith's reverse engineering work) if you like to play with FPGAs.
Now those old crashy Issue 1 Spectrums are worth a great deal of money (the later (and much more numerous) more reliable ones aren't worth nearly as much)
Don't count on it.
Those behind the Kickstarter have already failed to pay the developers of games they used in their iOS emulators (despite signing contracts etc.). The company has liabilities almost as big as the Kickstarter and few assets. They still haven't demonstrated a real prototype (it wouldn't have been that hard for them to show an actual rubber key Spectrum case driving a Bluetooth HID module, but all that's been shown is a retail POS keyboard driving some emulated games).
I hope I'm wrong but I seriously doubt this will ever see the light of day.
There was no speculation involved. An expert witness (a team of embedded platform engineers) analysed the source code.
Not only did Toyota not follow MISRA C, they didn't even follow their own coding standards. Reading the source code showed recursion was being used and Toyota's own internal standards were not being followed (let alone MISRA C). An 800 page report was produced. If you dig into TFA a bit you can see the 45-odd page presentation that the expert witness gave to the course. The TLDR version of that presentation is that Toyota was grossly negligent in the way they developed this system.
The thing is an aggressor who launches a first strike is committing suicide even if you don't retaliate. The nuclear winter will kill them.
Recent studies have shown that the original 1980s nuclear winter theory was in actual fact optimistic, in reality had the USSR and NATO exchanged, "nuclear winter" would have been a misnomer, really "nuclear six month long night followed by 10 year nuclear winter" would be more accurate with daylight levels not even reaching that of a moonlit night. A simulation was also done concerning two subtropical aggressors (imagine India and Pakistan) each hypothetical combatant firing only 50 Nagasaki sized weapons at the other side. The resulting "nuclear autumn" would shorten the growing season sufficiently over the next year or two that while it would not threaten starvation or anything so drastic, food prices would end up sharply increasing due to lowered production.
Before anyone says "We tested thousands of weapons, many hundreds atmospherically and what about the Tsar Bomba, why didn't testing cause a nuclear winter?" - this is because the testing wasn't done by setting off hundreds or thousands of warheads in the space of one or two days on live, highly flammable (and hydrocarbon filled) cities. It's not the bombs themselves that cause the nuclear winter, but the thick soot lofted by burning cities, and our cities today are extremely flammable being full of hydrocarbon fuels and other petrochemical products that cause very nasty soot, along with traditional flammable materials such as wood. You could make the same effect if you caused firestorms in a few hundred cities in a period of 2 days with non-nuclear means.
If you dig into one of the cited articles, you'll find they DID reproduce it in the lab. The Toyota software turns out to be very flawed.
Normally I would agree with you, but if you dig into TFA you can read the presentation the expert witness provided to the court. In this case it looks like Toyota was pretty negligent in the way they developed the firmware, violating not only industry standard coding practises but their own! The witness and his team produced an 800 page report on the shortcomings of Toyota's engine management system (he had full source code access).
But what motorcycles have that cars don't is a kill switch. Many modern cars with a start button and proximity key don't have a way of being turned off except by the button (i.e. software). My modern motorcycle has a start button and electronic everything, but it DOES have a kill switch. So if there was an unintended acceleration (and in the owner's forum for this bike, this has happened to at least one person when the throttle physically stuck on his bike after a spirited overtake) you can turn it off with the kill switch. Not so with a car. Why cars which only have software start and stop don't have a kill switch is puzzling (especially here in Europe where no one drives an automatic, so the engine will continue to be turned by the wheels if you kill the ignition, and will continue therefore to turn things like the power steering pump. If you're lumbered with an automatic gearbox the engine probably won't get turned so the steering will go very heavy but it will still function).
I'm embarrassed of the UK (my home country). It takes longer to get into the UK from Spain as a British citizen than it does to get into the United States (which is famous for its slow immigration lines) as a British citizen. While the rest of Europe is opening up, the UK is insisting on "tougher checks" largely because of the whining of trashy newspapers like the Daily Mail who hates everyone not British (and hates a significant subset of British citizens too). They were even talking about getting rid of the Common Travel Area meaning you wouldn't even be able to enter the UK from Ireland or one of the British islands like the Isle of Man or Channel Islands without a passport check.
Frankly it's embarrassing. The UK should be in the Schengen agreement along with the rest of the EU instead of wasting our time with pointlessly drawn out border checks to make little Englanders feel happy.
That's precisely what happened in the UK. Go to somewhere like Liverpool Airport and you can jump the security queue by paying a fee called "fast track".
Nope, not even for a website will 150ms latency be a killer.
You have to reduce what Facebook paid a bit, in reality. Most of what they paid for Whatsapp was paid not in money, but in hugely overinflated Facebook stock. They "only" paid $4bn in cash.
You don't need to be so pessimistic. Facebook "only" paid $4bn in cash, the rest of the price was paid in hyperinflated Facebook stock.
But of course most of this purchase was made with massively overvalued Facebook stock, not actual cash. I think "only" 4 billion or so was cash, the rest was inflated Facebook stock.
You probably did the boni thing just to troll, but we speak English, not Latin. Latin is a dead language (as dead as dead can be - it killed the ancient Romans, and now it's killing me...)
In English, it's bonuses. The plural of virus is viruses. The plural of nexus is nexuses. We don't speak Latin, plurals from a dead language aren't needed in English.
He certainly does have a job - he makes a living from public speaking engagements at least.
On a point of pedantry, you can't have 123.456.78.90 because 456 is greater than 255.