In many cases, a higher level language would cost you time. I know an engineer who spent a week trying to debug something that was the result of the C compiler doing something non-obvious to the code. It reordered a few things in the name of efficiency and ended up doing an access to the FLASH after the write operation had been started.
Yes. It was an unfortunate accident.
Not necessarily a fault
The language and the culture are entangled. A real mess.
Maybe somebody will invent a better language and an institute to train truly good programmers. The demand will be impressive.
John
i7 advertising specifically mentions how many threads it can run, and there is, apparently, a huge difference in machine ability on such systems. They are getting far batter returns than back in the old "2 CPUs doesn't mean double performance" days. As if we ever thought it did or should then either. Several cores ARE, however, far better than one or even two.
Face it KeithTard, you are behind the curve.
:
hard
almost
net, we in fact are
The chordate brain is not exactly parallel (small parallel like a supercomputer, though parts of it are). The brain is massively distributed, with different areas/spaces (brains are 3d) doing different things at the same time. No computer yet it the equal of any chordate in visual recognition. No man-made optical (well known) sensor has the resolution of the human eye, let alone a such a huge real time processor backing it up. Hello, the optic nerve bundle feeds parallel to the brain. The per nerve cell data rate may not be all that impressive, but multiple that by many, many millions of pixels will give you some hint of the aggregate data rate. Do have _some_ respect for your own eyes and brain.
Absolutely clueless.
Face it DorkSplatter, you're as dim as ever.
PowerPC has a set of instructions that are used to avoid such things. EIEIO (Enforce In-order Execution of I/O) being one of the more memorable ones. ;-) There were also SYNC instructions with differing levels of instruction execution/memory access order enforcement.
The Cell has taken a departure from that.
desktop
BRRRRRRRRRTTTTT You are showing arrogant ignorance. Every X86 is on the imperative von Neumann model. For that matter so are every uP that i have heard of, such as: 6500, 6800, 68000, MIPS, SPARC, HP-PA-RISC, 805X, 804X, PIC, AVR, ACORN, ARM, Transputer, MicroNova, MicroVAX, Alpha, Itanium, PPC and others for sure. So are many mainframes like IBM s/360, s/370, s/390, Crays, CDC Cybers, DEC 10s and many more. Not all of these are still made. Yet every one at the machine level is imperative procedural hardware. Nor does it matter what user language interface is used, the hardware is the same.
Lots of machines actually do out-of-order execution, but it's (usually) not visible in computed results.
John
On a sunny day (Sun, 14 Jun 2009 18:08:47 -0700) it happened John Larkin wrote in :
Although purely from a philosophical POV you both have a point, I think you are overlooking the obvious. Buildings are still build with bricks, some with concrete. There is also some pre-fab going on.
The versatility of the bricks and concrete allows endless creativity and solutions.
Same with C (C++ is a speech disability and it does not count, I dunno C++, as it is only for those who cannot program, but C is really easy, and) there are a zillion C libraries (say pre-fab solutions) or even libraries written in other languages that have a C interface, so that are a few of the reasons that C is so omnipresent. Portability is an other one (if written in a sane way), now everybody uses gcc and libc... portability is great. That is great compared to other languages.
I remember I received so crypto code for X86 may years ago, it did what could not be done, but some of it was in x86 asm. I spend a little time changing the asm to C, and low and behold it would all of the sudden run on any processor anywhere. And it actually was just as fast give or take a few microseconds.:-)
C is a standard solution, if you can analyse a problem, and think of a step by step way to solve it, then you can program it in C. That is all there is to programming. The rest is philosophy, and leads to discussions that waste more time then writing the C code would take. As this discussion.
ity?
. rosts
ed
at
in in
ge of
he
gThis was a compiler issue not an instruction issue. Things like:
a=3D1; b=3DBig * Long + messy * math * thing; c=3Da;
Will often become something like:
b=3DBig * Long + messy * math * thing; c=3D1; a=3D1;
when compiled.
In most cases, moving the assignment later in the code is the right thing to do because it lets the compiler notice that a simpler version would produce the same results.
solutions.
Yes, but civil engineering and construction are mature processes. When we did the seismic retrofit to our building, registered professional engineers did the math and other professional engineers checked their work and signed off on it. The re-rod was inspected before the concrete was poured. Every load of concrete was sampled and the samples aged and tested to failure. It was fixed-price and happen on-cost, on-schedule, and came out right. Putting buildings together, even daring designs, is a mature process, so mature that buildings rarely fail, and when they do it makes world headlines, and commissions are set up to discover why and to make sure it doesn't happen again.
Electronic hardware design is similar: we predict performance and cost and make it happen withour drama. The creativity is in the architecture and the performance, and less in the implementation.[1]
Software, on the other hand, is an immature and chaotic handcraft that anybody can do and nobody can control. Billion-dollar software failures are so routine they aren't even news.
It won't always be that way.
are a zillion
languages that
and libc...
The bad code and the bugs are portable, too.
not be done,
the sudden
step way
Some people can, especially for small problems. But small problems can be coded many diffferent ways that all work. Big software systems have about a 50% failure rate.
John
[1] Which brings up an interesting point: electronic design increasingly involves connecting ic's and boxes; we have moved up the abstraction stack from the discrete tube and transistor days. Software, in theory, also does a lot of connecting of standard boxes.The difference is that an opamp has 3 active pins and comes with a
20-page datasheet. A DRAM has a 200 page datasheet, appnotes, and apps engineers available to answer any questions. Most chips have eval boards and free human support available.I read some Windows module code. There's a standard form at the top of every subroutine that the author is supposed to fill out. One field is "Desciption of function" which was often filled out with useful info like "What it says." So the documentation is the code itself.
Imagine building a big system out of undocumented ICs.
On a sunny day (Mon, 15 Jun 2009 08:29:10 -0700) it happened John Larkin wrote in :
That is not fair, ;-) you are using a failed project (windows) as example, and on top of that it is in C++, so it can never even make sense,
When you compare stringing chips together with stringing software libraries and programs together, then you will find that often the software also has huge sets of documentation. the chip vendor may not give you a fully detailed diagram, let alone the mask of the silicon in the chip, but the datasheet shows you all you need to know to use it. I gave this project as example recently:
You wouldn't know a Cell program if it bit you on your stupid ass, DimBulb.
As long as there is no I/O in there, who cares?
Sure, but if any of the interim results are used, ordering has to be enforced. The processor takes care of itself (I/O doesn't). The same must hold true for the compiler or it is junk. The results are *not* the same.
simplicity?
costs
in
of
Unfortunately he did because the memory writes were to a FLASH. It was the "magic" string of writes that unlocked the FLASH.
simplicity?
costs
win in
range of
Then it is I/O and guarded instructions should have been used to enforce ordering.
I probably know more about the Cell BE API than you do. The way you talk, it will likely register as more than you ever will as well.
desktop
costly.
evaluation
A little reordering on the fly does not change the instructions from imperative to declarative, every one is a "machine do this" command.
But programming languages that are known to be much safer that C/C++ already exist. However, industry has chosen to go the low reliability and cheap route as a commercial decision. And it seems to be what the mass market wants.
Safety critical software for trains, ABS brakes and engine management tend to be developed in a much more conservative and controlled environment. But that makes it more expensive there is a steep learning curve and a shortage of qualified engineers to do the work.
solutions.
The Blade of Light bridge in London was the most recent example of a civil engineering design that by pushing the envelope fell foul of entrainment resonance effects. It didn't help that they ran a walking race across it on the first day. Once it started bouncing slightly people lockstepped and the oscillation amplified alarmingly.
Or another was the new Paris CDG terminal collapse.
It is also worth pointing here that virtually all civil engineering projects make extensive use of CAD and finite element analysis
*software* to draw up the designs, visualise and simulate them before any construction takes place.And again without the CAD software and the layout *software* tools you would be back to the dark ages of clear coloured sticky tape and tedious manual layouts. Modern CPU chips would be impossible to design by hand without the aid of software tools.
Billion dollar software failures are still quite rare and high profile. Very large projects that push the boundaries are often high risk. They become very high risk when the project managers are clueless.
Agreed. But the best prospect of getting an improvement is for the future generations of languages to move more towards specifying accurately and unambiguously *what* a program is supposed to do. And then leaving it to the compiler writers to convert what into how. This is already happening to some extent in that current Pentiums translate the x86 assembler code on the fly into internal parallelised micro-ops and then executes those. A tight loop executes the micro-ops from the tracebuffer.
One language I use is capable at compile time of detecting by dataflow analysis if there are any paths that could allow a variable to be used before it is initialised. If there are then by default it issues a warning and compiles a hard trap at the requisite point. I have promoted that particular warning message to a compile time error.
are a zillion
languages that
gcc and libc...
Not quite. Usually you do learn something new whenever a program is ported to a new environment or compiler. And unlike hardware and physical objects software becomes more reliable with age and runtime experience. It does not wear out in the same way that mechanical things do.
not be done,
of the sudden
by step way
But the problem is with the size of the project and the inadequate use of tools to support the development. Often the lack of anything even vaguely resembling a self consistent specification at the outset condemns the thing to fail.
If you started to build a house by showing the customer the newest solid gold bathtaps you were planning to use in the master bedroom ensuite bathroom and hanging the rest of the house of that he would thing you were crazy. The same sales pitch works all too well for bespoke software.
Would that this were true in practice. There are plenty of standard libraries that are well tested and developed by experts NAGLIB for instance being a very old example. But there are also no end of programmers that try to roll their own code without understanding any of the intricacies. Your fixed seed N-R sqrt being a case in point.
Some software has similar levels of support although not free.
You may have been unlucky. Some programs are better written than others. The executable code is never the documentation.
There is no silver bullet for programming found so far. You can write unreadable and unmaintainable programs in any language - even Cobol.
Many ICs do have a few quirks that are not mentioned in the datasheet.
But there is a point here that software has not yet reached a point where the equivalent of Whitworth in mechanical engineering has standardised screw threads from the infinity of possibilities to a workable subset. Buying in well documented and tested modules is not common practice (in part because you can be left up the creek if your supplier goes under). JPGELIB is an example of a free library that is very well field tested now.
A posteriori we can say of various DOS or Windows versions which ones were good and which were dogs. A bit like medieval cathedral builders if it is still standing after 5 years then it was a good one.
Regards, Martin Brown
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.