I disagree with you. Your reason for supporting a standard driver interface is that it makes it difficult for companies to provide Linux driver support. It is not necessary for the device manufacturers to provide Linux drivers. They only need to provide the documentation for their hardware interfaces, which I'm sure the companies already have internally. This would allow the open source community to develop Linux drivers for the boards.
The hardware companies want to keep information on the hardware interface a secret, as they fear their competitors will be able to gain advantage by knowing this information. But by doing so, they force themselves into the necessity of writing a driver for each operating system/processor that they intend to produce boards for. Historically, this was not the case. When someone bought a chip, they could also get the information needed to write software that uses the chip.
Good post. I first started using C back in the mid 80's and the first time I saw the definition of 'gets()' I could see that it was essentially a worthless function because it fails to account for the buffer size. I've never used it in production code. For a quick and dirty program that only I use, I might have
considered it. scanf() is another one of those essentially worthless functions.
I wholeheartedly agree with you. This was definitely one of the worst software bugs ever. A really, really, stupid idea it was to automatically execute VB scripts in Outlook.
Besides that, there really were only 8 software bugs mentioned. One, the pentium floating point error is a hardware error. The other, the CIA messing with the software for the soviet pipeline was intentional.
Jobs was looking at chips for notebook computers. The Pentium M is still the chip to beat in this application. These aren't the fastest chips produced, but they've got power enough for the usual business apps.
AMD was using tools from Synopsis. A hdl simulator along with a graphical
front end called VirSim. Intel had their own in-house developed tool set.
(They may have been using a commercial simulator, I don't know.)
I'm sure the tools that both companies are using have advanced quite a bit since then.
The VirSim front end allowed you to run multiple simulators at the same time.
(Some simulators were faster, others would have been more 'true' to the actual
hardware.) VirSim also let you define sets of break points, so you could automatically set a whole bunch of break points with a click of the mouse. If you've used something like Model Sim, VirSim was similar (but more powerful).
You could set a breakpoint on a certain instance (of an object) executing
particular source statement, or when some expression evaluated true.
You can collect data from a long simulation run, and then use VirSim to analyze the data 'offline' as well. The data files generated tend to be rather huge (we're talking hundreds of megabytes or event gigabytes) and
VirSim would allow engineers to quickly see what they needed to see from
this mountain of data.
You might think of VirSim as something like your software debugger on steroids.
Actually, there is some recent debate as to whether or not the milky way galaxie is a spiral galaxie. Some astronomers think it has a different shape, something like a bar if i recall correctly.
I'm not sure if it's the case right now, but back 5 or 6 years ago, AMD's chip development engineers were using design automation tools substantially superior to those that Intel's engineers were using, allowing AMD's engineers to be much more productive. Intel's management, of course, didn't envision a 64 bit future
for the x86 architecture.
I once had a rat killing dog. The dog would grab a rat by the head, whip it back and forth a couple of times in its mouth, and toss it 10 feet up in the air. It was a quick death for the rat. Their necks broke from being whipped around.
Well, Intel wasn't exactly blindsided. They knew what AMD had set out for a roadmap. Intel had a roadmap too. That roadmap was increasing the processor speed of the Xeon's to beyond 4GHz and developing the 64 bit Itanium solution. Only thing is, the roads on Intel's map were rather bumpy and rough. The Itanium took longer than anticipated to get into production plus it hasn't been all that well received. Pushing the GHz on the pentium also ran into problems. To increase the clock speed, they went to longer pipelines. Only thing was that their branch prediction logic wasn't good enough to keep those long pipelines from stalling and the performance improvement wasn't what they had hoped for. They realized then that they were kind of in a hard place and have been frantically struglling to overcome these missteps. They've got a start now with the dual core Xeons, and I'm sure they'll be back in the lead in the not too distant future.
The one thing they did do right was the Pentium-M. Their Israeli design team did a good job with this one. Because of the great success they've had with the Pentium-M chips in notebooks, they're not really struggling financially.
this must be some sort of light rail--or at least lighter than standard heavy rail.
I'm guessing you're correct about this being lighter than standard heavy rail. I'm wondering how the high altitudes affect the performance of the engines that will be pulling these trains. At those altitudes the atmosphere is like half as dense as at sea level.
They remarked that the passenger cars on the line would be pressurized. The atmosphere even at 16,000 feet would not be thin enough to be fatal for most healthy people should pressurization be lost. Some would develop high altitude pulmonary endima, however, and would need to be evacuated to lower elevations
within a few hours. A supply of bottled oxygen on board the train would be a
good idea.
I'm also wondering how warming temperatures would affect the operation of the
train. Would it cause some of the permafrost to melt and destabilize the
tracks? Would the atmosphere become still less dense making operation of the
locomotives at the altitude very difficult?
Re:hats off to Bram, Bill Joy, and ATT
on
Vim 6.4 Released
·
· Score: 1
Vi is indeed usable at 1200 baud. This mode of editing allowed me to avoid a 1 hour commute each way for 3 months. The old vi used the 'curses' libray and the
termcap settings which allowed it to be very efficient, in terms of minimizing the number of characters that needed to be sent across that 1200 baud line to control the display.
Vim users can only type one key at a time,
Not true. Vim users often need to use the control key along with another key.
You should modify this argument so that it states vim users use at most two
fingers at a time. I haven't used emacs much so I can't comment on how many
keys emacs users can use at once. But if it's more than two, yes they'ld certainly be more productive.
I'm quite sure that Samsung, Micron, and the others still made out quite well on the deal. Memory prices during the period were absurdly high, like 2 to 3 times what they probably would have been without the price fixing. That's a lot of bucks. $25/computer times 100 million computers is a lot of money. That's a ballpark estimate.
Actually it would have to access memory twice. Once to read, once to
write. A good code optimizer would put the temp in a register. But also
in the xor version, a good code optimizer would also not write the initial
xor value back to memory. But after writing pseudo assembly code for
both, I'll concede, the swap version is likely to be faster.
Swap version:
Load R0 A
Load R1 B
Store R1 A
Store R0 B
Xor Version
Load R0 A
Load R1 B
XOR R0 R1 ; R0
XOR R1 R0
XOR R0 R1
Store R0 A
Store R1 B
These would essentially be the instructions executed by a 2 operand risc
processor. Although each requries the same number of memory accesses,
the swap version doesn't require the three xors. One may be able to execute the xor version in fewer instructions, but it would require a additional memory accesses, which (if cache is not present) could be much slower than the three xors.
However an xor verson could work even if only one Register is available:
Slashdot Mirror
4. SPark plugs stop firing
These were diesel engines. They do not have spark plugs. The engine can run without
a battery.
What should have he ended it with?
The hardware companies want to keep information on the hardware interface a secret, as they fear their competitors will be able to gain advantage by knowing this information. But by doing so, they force themselves into the necessity of writing a driver for each operating system/processor that they intend to produce boards for. Historically, this was not the case. When someone bought a chip, they could also get the information needed to write software that uses the chip.
I'm sorry, but I didn't see any mention of the parrots.
Ever hear of a little country called VietNam? Yes, the U.S was fighting against a democratically elected communist leader.
Good post. I first started using C back in the mid 80's and the first time I saw the definition of 'gets()' I could see that it was essentially a worthless function because it fails to account for the buffer size. I've never used it in production code. For a quick and dirty program that only I use, I might have considered it. scanf() is another one of those essentially worthless functions.
I wholeheartedly agree with you. This was definitely one of the worst software bugs ever. A really, really, stupid idea it was to automatically execute VB scripts in Outlook.
Besides that, there really were only 8 software bugs mentioned. One, the pentium floating point error is a hardware error. The other, the CIA messing with the software for the soviet pipeline was intentional.
About 85% of lung cancer deaths are from smoking. I'm not sure how prevalent this is as far as the total percentage of deaths go.
Hah, I know of a few hills where they probabaly could hit 80.
Jobs was looking at chips for notebook computers. The Pentium M is still the chip to beat in this application. These aren't the fastest chips produced, but they've got power enough for the usual business apps.
4. Prophet
Waldo made an appearance in my Computer Engineering class last Friday.
AMD was using tools from Synopsis. A hdl simulator along with a graphical front end called VirSim. Intel had their own in-house developed tool set. (They may have been using a commercial simulator, I don't know.) I'm sure the tools that both companies are using have advanced quite a bit since then.
The VirSim front end allowed you to run multiple simulators at the same time. (Some simulators were faster, others would have been more 'true' to the actual hardware.) VirSim also let you define sets of break points, so you could automatically set a whole bunch of break points with a click of the mouse. If you've used something like Model Sim, VirSim was similar (but more powerful). You could set a breakpoint on a certain instance (of an object) executing particular source statement, or when some expression evaluated true.
You can collect data from a long simulation run, and then use VirSim to analyze the data 'offline' as well. The data files generated tend to be rather huge (we're talking hundreds of megabytes or event gigabytes) and VirSim would allow engineers to quickly see what they needed to see from this mountain of data.
You might think of VirSim as something like your software debugger on steroids.
Actually, there is some recent debate as to whether or not the milky way galaxie is a spiral galaxie. Some astronomers think it has a different shape, something like a bar if i recall correctly.
I'm not sure if it's the case right now, but back 5 or 6 years ago, AMD's chip development engineers were using design automation tools substantially superior to those that Intel's engineers were using, allowing AMD's engineers to be much more productive. Intel's management, of course, didn't envision a 64 bit future for the x86 architecture.
I once had a rat killing dog. The dog would grab a rat by the head, whip it back and forth a couple of times in its mouth, and toss it 10 feet up in the air. It was a quick death for the rat. Their necks broke from being whipped around.
The one thing they did do right was the Pentium-M. Their Israeli design team did a good job with this one. Because of the great success they've had with the Pentium-M chips in notebooks, they're not really struggling financially.
I'm guessing you're correct about this being lighter than standard heavy rail. I'm wondering how the high altitudes affect the performance of the engines that will be pulling these trains. At those altitudes the atmosphere is like half as dense as at sea level.
They remarked that the passenger cars on the line would be pressurized. The atmosphere even at 16,000 feet would not be thin enough to be fatal for most healthy people should pressurization be lost. Some would develop high altitude pulmonary endima, however, and would need to be evacuated to lower elevations within a few hours. A supply of bottled oxygen on board the train would be a good idea.
I'm also wondering how warming temperatures would affect the operation of the train. Would it cause some of the permafrost to melt and destabilize the tracks? Would the atmosphere become still less dense making operation of the locomotives at the altitude very difficult?
Vi is indeed usable at 1200 baud. This mode of editing allowed me to avoid a 1 hour commute each way for 3 months. The old vi used the 'curses' libray and the termcap settings which allowed it to be very efficient, in terms of minimizing the number of characters that needed to be sent across that 1200 baud line to control the display.
Vim users can only type one key at a time, Not true. Vim users often need to use the control key along with another key. You should modify this argument so that it states vim users use at most two fingers at a time. I haven't used emacs much so I can't comment on how many keys emacs users can use at once. But if it's more than two, yes they'ld certainly be more productive.
You'ld want to make sure you had at least two cupcakes for each of the teenage boys. They tend to have large appetites.
99% does seem rather extreme, but I'ld say that 80% would be in the ballpark.
I'm quite sure that Samsung, Micron, and the others still made out quite well on the deal. Memory prices during the period were absurdly high, like 2 to 3 times what they probably would have been without the price fixing. That's a lot of bucks. $25/computer times 100 million computers is a lot of money. That's a ballpark estimate.
Actually it would have to access memory twice. Once to read, once to write. A good code optimizer would put the temp in a register. But also in the xor version, a good code optimizer would also not write the initial xor value back to memory. But after writing pseudo assembly code for both, I'll concede, the swap version is likely to be faster.
Swap version:
Load R0 A
Load R1 B
Store R1 A
Store R0 B
Xor Version
Load R0 A
Load R1 B
XOR R0 R1 ; R0 XOR R1 R0
XOR R0 R1
Store R0 A
Store R1 B
These would essentially be the instructions executed by a 2 operand risc processor. Although each requries the same number of memory accesses, the swap version doesn't require the three xors. One may be able to execute the xor version in fewer instructions, but it would require a additional memory accesses, which (if cache is not present) could be much slower than the three xors.
However an xor verson could work even if only one Register is available: