Slashdot Mirror

Or various CPU properties, such as haveged uses.

You're simply underestimating the propensity of some people to proudly display their ignorance to the world.

Indeed. Go here. Then read: Conguration Cell Technology: FLASH

The Flash chip is typically just a helper chip outside the FPGA. The logic configuration is transferred from the Flash to the FPGA every time when the system is started. But the general concept of FPGA is not about Flash. The general concept of FPGA is about a type of digital logic which can be changed easily.

You're simply underestimating the propensity of some people to proudly display their ignorance to the world.

Indeed. Go here. Then read: Conguration Cell Technology: FLASH

"The software, written in Ada....."

That says it all.

Not the important part, no. The problem was bad engineering practice, not Ada.

Ariane 5 : Notable launches

The software, written in Ada, was included in the Ariane 5 through the reuse of an entire Ariane 4 subsystem despite the fact that the particular software containing the bug, which was just a part of the subsystem, was not required by the Ariane 5 because it has a different preparation sequence[21] than the Ariane 4.

Ada is well proven software engineering technology that can help you produce better software, but it isn't magic. You still have to follow sound procedures for it to help you.

For anyone that is interested, there is more useful detail in these links:

I heard tell that Ada was to blame for the Ariane V disaster. Is this true?
Put it in the contract: The lessons of Ariane

What about XCast? Seems perfect for groups around the size of a typical torrent, and if the torrent gets too large you can just use multiple XCast groups because the number of groups is unrestricted. Even if you need many groups you'll still save a ton of bandwidth compared to unicast.

Seems to me like the multicast people have been going about it the wrong way all these years, with tons of state inside the network. What happened to the dumb network philosophy? A stateless protocol like XCast is what is needed. I don't know if it can help with the billing problem, but surely the fact that each packet lists all of its destinations can't hurt.

x86 gets a big boost because of register allocation. All that ugly spill code produced because of the register-limited architecture gets translated into register moves (or eliminated entirely). Unless code for a PPC, MIPS etc. was compiled assuming a lot more than 32 register (which it can't, due to the instruction format), there won't be much gain here.

Unless Transmeta adds partial evaluation/specialization a la DyC or Tempo, I don't think the benefit of code morphing on, say, a PPC will overcome the cost. I suppose they could do something like Dynamo and implement a software trace cache.

One interesting avenue of research would be to compile to a virtual ISA that included lots of registers and other fancy hardware structures the compiler could use. Taking advantage of new compiler innovations would then be a matter of designing a new ISA and writing the code morpher. Not having to re-do the silicon would be a big savings.

--

http://www.irisa.fr/prive /dmentre/smp-faq/smp-howto-3.html

3. x86 architecture specific questions

1.Can I use my Cyrix/AMD/non-Intel CPU in SMP?

Short answer: no.

Long answer: Intel claims ownership to the APIC SMP scheme, and unless a company licenses it from Intel they may not use it. There are currently no companies that have done so. (This of course can change in the future) FYI - Both Cyrix and AMD support the non-proprietary OpenPIC SMP standard but currently there are no motherboards that use it.

The thing about static compilers is that they have no idea what happens at run-time. Profiling has been used to mitigate this somewhat, but it's still a huge problem.

Accesses through memory are slow, so you want to get rid of them. One way to do this is through register allocation. Unfortunately, even if an infinite number of registers was available, you couldn't allocate everything to registers.

Why? Because we use pointers. There are multiple names for the same data running around in our little electronic brain. When you allocate something to a register, you bind it to one name. This is by definition incorrect for aliased data (data with multiple names).

Optimizations like register promotion try to get around this by allocating things in regions where the compiler can prove it only has one name. But this is exceedingly difficult when you have things like function calls which must be assumed to access and modify lots of data.

I won't even get into the problem of static instruction scheduling or other optimizations like partial redundancy elimination.

In short, aliasing through memory is nearly impossible to track accurately at static compile time. At run-time, the machine knows exactly which memory accesses reference which data, so things like run-time register allocation can do a better job. Crusoe does this to a limited extent.

Dynamo is essentially a software trace cache. Except that when forming the trace, it does transformations like Common Subexpression Elimination and other traditional compiler manipulations.

IBM has the Daisy project, which does code morphing from PPC to a VLIW ISA. I believe it also does some run-time optimizations. Projects like DyC and Tempo have been compiling at run-time for a while now.

I like to think of dynamic compilation in terms of the stock market. Which would you rather do: trade stocks with only limited information about their past behavior (and sometimes none at all), or trade stocks after having observed the absolutely most recent trends? I'll bet that if you pick the first strategy and I pick the second, I'll beat you every time.

That said, there are tricks ou can pull with static compilation. IA64 has the ALAT, which lets the machine track when store addresses match load addresses. This lets the static compiler speculatively move a load ahead of the store. If the store conflicts, the machine will execute some compiler-provided code to fix up the error. Essentially, the compiler is making an assumption that the load and store do not reference the same data and is communicating that assumption to the machine. The machine checks the assumption and invokes some fixup code if it proves to be incorrect.

--