Hi-Tech Software bought by Microchip - no more other compilers

Only IBM could have shot themselves in the foot that well...

As you say, the results were the same. I can't be sure I've remembered everything accurately, and certainly some of your details here ring a bell, so I expect you are right about the licensing. IBM certainly got a lower price than others, and they certainly sold few or no pre-installed OS/2 PC's - but any particular deals there would have to have been unofficial to avoid the DOJ (not that the DOJ came close to doing its job in this case).

Not when the IDE is coming from an entirely different vendor than the compiler and debugger.

That is why I spent a weekend writing scripts to integrate the toolchain with an IDE. I could have used a stand alone gdb front end, but I'm not convinced it would be any simpler. What I go for my trouble is a convenient work environment that can be run on either linux or windows/cygwin.

Hehe. Well, there is that, I suppose. But the point remains for those cases where it applies.

Jon...

I doubt that. Judging from the IDEs from Keil and IAR they spend too little time on their IDEs. Its a pile of crap. There is a good reason everybody seems to move to Eclipse. I'm not saying Eclipse is perfect (it is a Java application after all) but it does a lot of wonderful things that make it easy to deal with sourcecode and it helps to organize different builds as well. I have projects that produce over

It would be inappropriate for me to name names here. But as I said, the fact is I've asked and on occasion received direct answers to this question. I'm not speaking from entire ignorance.

Jon

It would seam that perhaps the reason for the move to Eclipse is so they can spend less time working on the IDE itself.

Personally I decided eclipse was just too slow on perfectly functional computers, and tied things into codeblocks instead.

The idea of using an industry standard open source IDE instead of reinventing the wheel is a good one, I'm just not yet convinced that Eclipse is the best choice, though if you are developing in java that might make more sense.

Quite a while back I installed Hi-Tide which was the HiTech implementation of Eclipse.

During the first day I decided to delete a project and found that the source files were automatically deleted as well. I complained to HiTech and got the response yeah it does that. I haven't tried it since.

I like the idea of a separate effort for IDE development and your feelings about Eclipse seem close to mine. However, even if it is a perfect solution, works well under a variety of O/S environments, is open source and free to all, has active support going on year after year, somehow it just sings in everyone's minds and everyone loves it.... compiler vendors will find it removing some of their differentiation. I'm not sure how they'd take to the idea. (Many do so know with MPLAB, so perhaps they have formed some opinions about this by now.)

Jon

I was merely pointing out they should stick with building compilers and not try to make IDEs. Especially if it takes most of their time :-)

hehe. Sorry!! And yes, I agree!!

Jon

Several things have changed. Primarily, the FPGA vendors have cleaned up their acts. Their tools work. ...and the tools are free for not just the low-end devices, rather for all but the largest. No, I don't anticipate having to use the largest FPGAs anymore. I'm no longer in the land of infinite budgets and defense contracts.

You do realize there really are such things as antitrust laws? IBM was deathly scared of another runin with the DOJ. For good reason.

The bottom line is that one can't restrict the market as overtly as you give M$ credit for, and get away with it. ...and get away with it, they did.

Actually, I know a little (though not much) about such laws, and I /do/ know that IBM was paranoid about them. But you have to admit it sounds daft that IBM would have to pay themselves to install their own software on their own computers! And the anti-trust laws are designed (amongst other things) to stop abuses of monopoly - since IBM did not come close to having a monopoly on either the hardware or the OS, and would have offered a choice to customers, I don't see why there would have been a problem with very low costs for OS/2. But of course, I am not a lawyer, and I probably wouldn't understand the details if I heard them - I'm an engineer who is frustrated that a technically superior product failed through one company's criminal manipulation of the market, and another company's apparent stupidity.

What has come out in the court cases was some *very* overt market manipulation and control by MS ("simplified accounting" being one example) - they didn't need to go that much further. But MS have clearly demonstrated that they are happy to commit knowingly criminal acts in getting such control, and rely on either getting away with it entirely (certain US administrations have tending to let big, important companies get away with almost anything), or delaying cases and eventually paying a fine. From MS's viewpoint, it is still "getting away with it" even if they must pay substantial fines in the future - criminal market manipulation is just another type of long term business investment to MS.

Of course. Everyone else must pay, so... TANSTAAFL, is another good reason.

The reason for much of what IBM has done extend back to the '56 consent decree, which *was* a antitrust issue. The consent decree has only been lifted in the last few years.

It's not so much "administrations" letting them get away with anything, but that the government, in general, is simply clueless. The DOJ's case was weak because the issues were irrelevant.

Turning off optimizations never helps promote a compiler. It is counter productive for the compiler company. A couple numbers that are worth mentioning about compiler development is a good compiler for a new processor typically costs about 10% of the silicon development cost and currently generates about 1% of the total revenue.

The development teams are about two to one in size. The silicon development costs are dominated by technology costs and software tool costs. Compiler development costs are dominated by code generator design, and target specific test suites.

Regards,

-- Walter Banks Byte Craft Limited

About half of our customers have company standard IDE's. that integrate their tools. They use tools sets that support error reporting standards and tool execution standards. Source level debugging is done using one of about

They do well at mixing compilers, processor simulators, system simulators jtag and other background mode emulators with a common IDE.

Regards,

-- Walter Banks Byte Craft Limited

So raising the selling price of the silicon to get an extra 1% into the till (i.e. negligible) would offset the loss of revenue from giving away the tool, even if you ignore the increase in small volume sales that such a move would generate.

Partly correct. The business perspective in much more complicated. It would mean contracting out compiler development and funding that at the same non revenue time that the silicon was being non revenue putting more financial pressure on the silicon company when they can least afford it.

You are correct in the long term.

The tools needed to support small volume sales effectively are different than the tools that are needed for large volume sales. The initial question is, "Why should that be?" Most of the differences are around source management, application metrics, code maintenance, debugging, validation and regression testing.

Small volume stresses fast time to market, solid reference designs low debugging costs and testing.

The needs of the two markets are quite different.

Regards,

-- Walter Banks Byte Craft Limited

cular

rface

nd

ut

So many of these things become possible when you are willing to put that critical hacking session to make them work. For example, gcc can be launched out of Visual Studio just fine... if you write a script to reformat the error messages to what VS expects. Abandoned that long ago, but it was a useful capability for a while, building embedded code from the same environment used to debug a desktop build of the algorithms.