Newsgroup: it.lavoro.informatica
Titolo: Articolo interessante sui tools di sviluppo

Da Embedded Muse
Tool Guardians
--------------
One difference between hardware and firmware development is the shelf
life of the tools. Even when pushing the bleeding edge of technology,
a five year old scope or logic analyzer is usually more than
adequate. Some dedicated folks still crank out 8 bit systems using
old Tektronix 545s - 30 year old vacuum tube beasts that invite a
hernia each time they're moved.
Our software tools have lifetimes of microseconds. Microsoft's
regular Patch Tuesday creates an organically-evolving OS and Office
suite. Much of the current embedded hardware technology is all
designed to speed firmware upgrades - flash memory lets us reprogram
devices on the fly.
Of all the tools we use, though, compilers are the most problematic.
Compilers create the code that is our product. A line of C is nothing
more than a series of commands asking (pleading?) for a stream of
machine code that implements an algorithm. Most other tools, like
debuggers, fly in an orbit around the designer, helping him design
and implement the product, but never becoming a part of the unit a
customer sees.
A compiler problem becomes a product problem. A compiler change
changes the product. When your compiler vendor releases a version
that generates tighter code, simply recompiling changes the product.
Though the tighter code is nice, it raises the specter of new, lurking
bugs.
Before the vendors start sending unibomber email, I'm not implying
that compilers are bug-ridden monstrosities. In my travels I see
system after system that works until something changes. It may be a
compiler upgrade, or perhaps a different set of parts used in
manufacturing. Bugs lurk everywhere, and a compiler change often
uncovers problems previously hiding in your code. Sometimes the risks
of upgrading outweighs the benefits.
The problem is more severe for older products. If your five year old
widget works great, and only needs a very occasional software tweak,
do you instantly rebuild the code on each new compiler release? This
implies a product change, with perhaps little benefit. Or, do you
wait till a crisis requiring a code change hits, and then both fix
the bug and use the new version. perhaps changing a ten minute fix to
a week of hell?
The right thing to do - technically speaking - would probably be to
rebuild all the old stuff. Who can afford that? The testing alone
consumes vast amounts of valuable development time.
The risk is high, the benefits are vague. We need compiler guardians
who keeps old versions around, with associated antique linkers and
other support tools.
Perhaps "compiler guardian" is too narrow a focus. Most tools require
some level of attention and management. Someone, or some group of
people, have to keep all electronic tools metaphorically sharp. One
friend told me this week that the old DOS editor he's been using for
20 years still runs under Windows XP, but for some reason sucks so
much processor power his laptop batteries die very quickly. It's
ironic that some change in Windows means this editor, which ran fine
on an 8088 at 4.77 MHz, sucks every compute cycle a 2 GHz Pentium can
provide.
Take for instance a PCB layout program, a staple of every engineering
department. I was bitten by an upgrade to one of these products, and
discovered to my horror that all of the libraries were now obsolete.
What a joy it is to maintain both old and new versions of the software.
One friend addresses these sorts of problems by never upgrading. When
the path becomes too rocky he idles, using the old but presumably
reliable software for years after the vendor declares it obsolete. I
worry that getting stuck in such a tool time warp will backfire.
Support becomes non-existent.
However, "good enough" may be all that's required, as the goal of
engineering is to get a product out on time, on budget, that meets
specifications. Using the latest and greatest goodies does, I feel,
keep us more productive. Does the continual upgrade cost balance the
productivity increases? I wish I knew.

productivity increases? I wish I knew.
In effetti e' un bel problema, sentito a quanto pare solo nel mondo
embedded.
Nel mondo PC si cambiano tools e linguaggi, imho spesso (non sempre
ovvio) piu' dettati dalla moda o la voglia di diversificarsi che da
vera necessita'.
Non sarebbe male davvero avere un "tools guardian", solo ... chi lo
finanzia ?
Ciao
	Steve
-- 
Legge di Flon
Non c'e' linguaggio in cui sia difficile scrivere cattivi programmi.
FAQ del gruppo : 
http://aledeniz.blogspot.com/2006/11/le-faq-di-itlavoroinformatica.html


Io penso sia più sentito perchè:
1) E' più difficile farsi riconoscere economicamente il lavoro di port
di un firmware
2) Almeno per me, ci vuole un bel pò per "fidarmi" di un nuovo tool:
mi è capitato di scoprire bachi su compilatori che usavo da una vita
Capoccetta

mi è capitato di scoprire bachi su compilatori che usavo da una vita
Quello si' !
E piu' di una volta :-(
E si rientra un po' sul thread dove discutevo con Franco.
In genere in ambiente PC e' difficile trovare qualcuno che va
effettivamente a vedere cosa fa un compilatore.
In ambiente emvedded quando l'apparato fa le bizze, si va a fare le
pulci anche al compilatore, per motivi di sicurezza e di
ottimizzazione.
C'ya


 
Capoccetta

Ho visto cose veramente diaboliche in proposito!
Non sei il solo, coraggio :-)
C'ya
	STeve



Purtroppo me lo son perso, le prime esperienze nel settore le ho avute
nel '95.
Capoccetta