Re: The Manifest Destiny of Computer Architectures

I think that is a large part of the "rub": we're in what might be a local minimum (or at least inflection) of the language space, and the trouble with heading in what seems to be the right direction is that performance gets significantly worse until the runtime/compilation systems are a

*lot* more sophisticated than we have at the moment. So we don't go there, and they don't get developed.

Someone is probably working on the right answer, somewhere, already. If I can imagine it then brighter people than me are bound to be giving it a go: my first rule of the internet...

Cheers,

--
Andrew

I guess stress on the pads are also a parameter that may influence growth of whiskers..

I've been doing lead-free boards on my commercial products, and after some trouble, mostly with solder wetting, I now have the process working quite well. But, the boards have to be made with FR-406 and lead-free finish to make it work.

Since the research products I make are intended to have a much longer operating life (like 20+ years) I have been making them with Sn/Pb solder, but components are very hard to get in this finish. Anyway, these existing boards were not made for lead-free temperatures, and so I CAN'T run them at 250 C or they will likely delaminate.

Jon

Nope, no way. This is a living space, and I am in there for several hours every day. Temps below 20 C might be possible, but not below that.

Jon

There is a really good reason why the Aerospace and Military have been exempted from the ROHS mandates. That's because under extreme environments (maybe including humid basements), ROHS doesn't work well. It is well known that it grows Tin Whiskers.

It is a real PITA for those industries because suppliers would rather drop the old parts. Every component gets a review by our manufacturing experts to determine if it compatible with our soldering processes. Sometimes we go to the trouble of 're-balling' parts to get the 'right' kind of solder that is known to work. Sometimes they just reject the component outright and tell us to find another one...

By all means you should understand your issue - maybe there is room for some process improvement. I'm just suspicious that there is no solution, yet.

Rob.

Scott Michel sent: |--------------------------------------------------------------------------| |"On Sep 14, 2:06 pm, glen herrmannsfeldt wrote: | |> > 6.  A new language with APL-like semantics would allow programmers to| |> > state their wishes at a high enough level for compilers to determine | |> > the low-level method of execution that best matches the particular | |> > hardware that is available to execute it. | |> | |> APL hasn't been popular over the years, and it could have done | |> most of this for a long time.  On the other hand, you might look | |> at the ZPL language.  Not as high-level, but maybe more practical." | |--------------------------------------------------------------------------|

Languages can allow compilers to optimize in a way which compilers do not bother to do. That was true of APL and other languages.

|----------------------------------------------------------------| |"ACM killed off SIGAPL about 5-6 years ago. Sorry to see it go."| |----------------------------------------------------------------|

SIGAPL exists. In what way was SIGAPL "killed off"?

|-----------------------------------------------------------------------| |"Have a look at the DARPA HPCS languages, notably, Chapel, Fortress and| |X10. Not entirely sure about their respective statuses, but they were | |an attempt in the HPC arena to raise the level of abstraction. | | | | | |-scooter" | |-----------------------------------------------------------------------|

Someone of Oracle authored an article in "The Journal of the ACM" or in "The Communications of the ACM", mainly re replacing efficient Fortran code with fewer lines of Fortran with "only" a drop in performance of circa 100%. Fortress and circa two other languages (maybe Chapel and Fortress) were briefly mentioned.

In a manuscript by myself which is currently under review, I mention Fortress (and Fortran). In some drafts of the manuscript I mentioned part of Fortress which is less abstract for efficiency (or maybe at a higher level and less efficient). I edited that observation out before submitting the manuscript to the journal because of a space constraint and the focus of the manuscript is something else.

The edited Fortress section still shows that the idea that the notion that high abstraction is deployed in Fortress is laughable.

Sincerely, Paul Colin Gloster