One thousand years from now

Yes. You evidently don't know how the computer business was run.

All of it. Both IBM and DEC shipped everything with full sources. A

*lot* of development was done by customers and the work then fed back into the tools.

purposes

cases

of=20

overpopulation,=20

=20

Dodo birds which had been around millions of years though the same as well, man has not been around nearly so long. The point is that such mechanisms do exist and that they can suddenly overwhelm another species. Man nearly wiped out the anopheles mosquito, but stopped short due to backlash from greenies.

up

NASA).

proper

it

I would feel better if you did put forth some modicum of effort to try and learn this stuff, your continued ignorance does nothing to make me feel better. Learning requires intention on the part of the learner.

Nothing there explains "irrelevant".

the

The term "economic freedom" has no meaning without context. Do you have some definition without reference to responsibility? If so it is bogus.

in

storage

Yes BAH did have it all. Now what do you have?

during=20

detect.

I

software=20

work=20

cause.

universe,

their

So sad that you missed the point so badly. First, you try to generalize to the universe from this hyper microscopic instance of this planet. Worse, you barely have any clue about the fantastic variety of life on this planet! Admittedly, i am an electrical engineer, not a zoologist, but i manage to not be so amazingly ignorant.

Nowadays, the patching tools all suck. We also were able to patch software, even the kernal while it was running. And we did it using machine code, not some wimpy HLL interfacing.

/BAH

You have already stated that you had to deal with bugs in the compiler which makes it your problem. If you had the sources to the compiler, you could fix the bugs, set it in hard bits, recompile the compiler and never have to deal with the same bug again.

/BAH

I answered the question. Yes.

Yes. I even knew how to cold start a computer with only a boot tape (which I built) and a set of sources. We used what we shipped and we shipped what we used.

So did you have to copy that code everywhere you might encounter the bug? Editing the compiler sources, rebuilding the compiler, would have guaranteed that you wouldn't have that particular problem again.

And some bugs don't have a workaround.

Did you maintain a library of all your workaround code? Did you maintain a testbed to determine if the software updates for that compiler still had the problems? Now you're talking about man-year/year to keep track of the mess.

/BAH

In other words, having no cogent rebuttal, you cast insults at your enemy?

Shame on you.

Well! Stick THAT in you link and layer it!

Read the friggin' thread!

Indeed. You should be ashamed of yourself!

You could, but you would need some compiler expertise in house, or buy the expertise from external consultants. The compilers are such complex beasts that it's not easy to fix them without special knowledge of the compiler internals. It's easier to just work around the bug, or get the original vendor to fix the bug.

My experience is that for commercial compilers (VHDL, Verilog etc.) the bugs have been fixed quite quickly when there is a reasonable sized testcase to point out the bug. Or during the conversations the vendor tells that my understanding of the standard is not correct ;)

--Kim

Yes. The job is not about fixing compilers, but about getting the project done.

In the later case, it helps to compare the behavior of the compiler to some well known compiler, such as MS Visual C++. Not that MSVC is such an etalon, however this gives the arrogant vendor some doubts.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Don't need no stinkin' layers. JMF wrote the MERGE. UUO.

/BAH

Are they really? Gee, it's only software ;-).

Sure it's easier but it can also be a RPITA if you have to maintain a test bed or library for workarounds.

Yep, and then there is that. :-)

/BAH

Which, in the described case, had to deal with fixing a compiler bug. You really don't know how to work, do you?

Oh, my dear. That is not a good way to do things.

/BAH

There are sometimes many ways to interpret the language standards. If many compilers do the transformation in one way, and one vendor is different, it is easier to persuade that one vendor to fix their behaviour to match the others. Or at least that opens interesting discussion about the standard and how to interpret it.

--Kim

Yep. When the aspect is rather recent, all the software will take a while to adapt. If this change breaks existing code, then there will also have to be the accepted method plus the "old" method.

If the vendor has had its code out in the field for some time, the software will have to provide the "old" way, too.

And then there are the underlying differences in hardware. To tweak or not to tweak; that is the questionable bit.

/BAH

30 years ago - you are absolutely right, I do not know.

Impressive. I would prefer the compiler supplier to do the job it was paid to do. I have a lot of other things to do.

--
Andrew

Impressive, but hard to believe. Or there was a limited amount of software.

I see. It was long age when software was written by the great programmers using hex numbers.

It was a great time, but it passed for the better or for worse.

Yes. workaround was not that complicated.

And retest compiler modification to make sure you did not break something else.

I am not in the compiler design business and I am sure people designing compilers can do it better.

Did you maintain a library of all you compiler fixes? Did you have to apply the same fixes to the subsequent version of the compiler? Did you run complete set of compiler tests to make sure that your fix did not break something else? Did you retest all your other projects to make sure that updated compiler did not break them either?

Now your are talking man-years of support and maintenance for what supposed to be compiler supplier's problem.

--
Andrew