Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Open Watcom 1.0 Released 307

Posted by michael from the competition-is-good dept.
JoshRendlesham writes "The Open Watcom C/C++ and FORTRAN 1.0 compilers have been officially released. The source, and binaries for Win32 and OS/2 systems, are available. This release also means that outside developers can join and contribute to the project." Or if you prefer, gcc is up to 3.2.2.
This discussion has been archived. No new comments can be posted.

Open Watcom 1.0 Released More

Open Watcom 1.0 Released

Comments Filter:

  • Rise of the Triads (Score:3, Interesting)

    by Anonymous Coward on Saturday February 08, 2003 @02:48PM (#5259985)
    Does this mean that I can finally use the ROTT-source for something else than just looking at? :-)

  • DOS days (Score:4, Interesting)

    by Graspee_Leemoor ( 302316 ) on Saturday February 08, 2003 @02:51PM (#5260001) Homepage Journal
    Back in the days of DOS, if you were a developer, the Watcom C compiler was *the* thing to pirate.

    graspee

    • Re:DOS days (Score:5, Informative)

      by ctr2sprt ( 574731 ) on Saturday February 08, 2003 @03:19PM (#5260130)
      Wasn't it the first mainstream compiler to include a complete DOS extender and feature full 32-bit support? I remember wanting it so badly in the DOS days, but I was a broke student and could barely afford the modem I used to download porn. I had to make do with Borland C++ (which was great, but lacked 32-bit support unless you felt like writing a lot of assembler).

      Anyway, I'm excited by this because, well, competition is almost always a good thing. Hopefully gcc and Watcom can feed off each other and both products will improve. And perhaps more importantly for the build-everything users, another open source compiler might start moving people (like the developers of autoconf) to better support non-gcc compilers. This way, users who prefer Watcom's (or Intel's, or...) compiler can use it without as much tweaking.

      • Re:DOS days (Score:5, Informative)

        by Graspee_Leemoor ( 302316 ) on Saturday February 08, 2003 @03:21PM (#5260144) Homepage Journal
        The version of gcc for dos: DJGPP had a DOS extender and 32-bit support but it was slower than Watcom by a large amount.

        graspee

        • Re:DOS days (Score:3, Funny)

          by Reziac ( 43301 )
          Not to mention that DJGPP is responsible for the worldwide shortage of sacrificial chickens and goats!! Installing it has been described as a black art, and getting good performance from the resulting binaries.. lordy. Talk about bad juju.

          (And will someone PLEASE fix the stack overflow/memory leak in CWSDPMI?? It's been there since the Go32v2 days!!)

        • DJGPP & Quake (Score:3, Informative)

          by wideBlueSkies ( 618979 )
          >>The version of gcc for dos: DJGPP had a DOS extender and 32-bit support but it was slower than Watcom by a large amount

          Though that didn't stop ID software from using DJGPP to build Quake 1 way back in 96.

    • Re:DOS days (Score:3, Interesting)

      by ma++i+ude ( 580592 )
      First of all, for the uninitiated, if your program shipped with dos4gw.exe (as most games did), it was compiled in Watcom. Such was the performance difference that nobody really bothered with any other compiler, especially with games.

      Back in the days of DOS, if you were a developer, the Watcom C compiler was *the* thing to pirate.

      I remeber using a stripped-down copy which was missing a good part of the standard C++ libraries and still doing most of my development on it. Having gotten used to such luxuries as the IDE Borland C++ (and Turbo Pascal) shipped with, it took a while to get used to but produced superb code.

      • Re:DOS days (Score:2, Interesting)

        by bawb ( 637210 )
        it took a while to get used to but produced superb code

        Personally, I found it to be a disappointment and all my side-by-side comparisons with Borland's Turbo C++ usually fell short. Especially if I was unrolling a lot of loops. IIRC, snooping the output revealed that it ignored them and no amount of tweaking the compiler would correct it.

        There's no arguing that Watcom made it pretty easy to access more memory, but if you already had a code base set up to handle that there didn't seem to be much of a point.
      • What exactly did dos4gw.exe do, incidently? I always used to wonder.

        • Re:DOS days (Score:5, Informative)

          by ma++i+ude ( 580592 ) on Saturday February 08, 2003 @04:25PM (#5260429) Homepage
          What exactly did dos4gw.exe do, incidently? I always used to wonder.
          It allowed the programmer to use all of the available memory. Remember when you had problems getting programs running because there was not enough conventional memory (ie. the first 640KB)? Well, dos/4gw made is easy to write programs free of these memory limitations. More information at http://www.tenberry.com/dos4g/ [tenberry.com]

          • Re:DOS days (Score:3, Informative)

            by Ninja Programmer ( 145252 )
            More specifically, it "EXTENDED DOS" to the 32 bit flat address model. The problem was that the entire DOS API was 16 bit, and assumed that everything happened in the first 640K. So if you wanted to use the DOS services with your data that was not in the first 640K, you needed a translation layer -- this is what the DOS Extender (typically via an API called "DPMI" -- DOS Protected Mode Interface) provides.

            Some of the better DOS Extenders had a built-in virtual memory mechanism as well. Actually it turned out that DOS4GW was kind of weak in comparison to the other extenders like "CauseWay" which Open Watcom is supposed to be using now.

            • Re:DOS days (Score:3, Interesting)

              by Mike Monett ( 48534 )
              More specifically, it "EXTENDED DOS" to the 32 bit flat address model. The problem was that the entire DOS API was 16 bit, and assumed that everything happened in the first 640K. So if you wanted to use the DOS services with your data that was not in the first 640K, you needed a translation layer -- this is what the DOS Extender (typically via an API called "DPMI" -- DOS Protected Mode Interface) provides.

              You can run 32 bit code in dos without the restrictions and performance penalty of DPMI. It's called Flat Real mode, and has been around since 1988. Himem and Smartdrv use it to access extended memory.

              But you don't have to go through Himem to access memory above 1 meg. You can do it yourself and eliminate the time wasted.

              The problem is debugging your code to ensure data is transferred correctly. DOS debuggers cannot recognize 32-bit addresses, so you cannot verify data is stored correctly or that you are pointing to the correct area in memory.

              Here's the solution

              http://www3.sympatico.ca/add.automation/flat/frm.h tm [sympatico.ca]

              Best Regards,

              Mike Monett

  • cool ! that's great news (Score:3, Interesting)

    by jacquesm ( 154384 ) <j.ww@com> on Saturday February 08, 2003 @02:53PM (#5260008) Homepage
    I used the watcom tools extensively on QNX and they were of excellent quality, this is really good news !

    Hopefully this sets a trend.

  • Re: (Score:2, Informative)

    by account_deleted ( 4530225 )
    Comment removed based on user account deletion
    • No, 3.2.1-r6 does not ruin Gentoo machines. There were a couple of initial problems due to a lack documentation on *how* to upgrade GCC. Take a look at the "Gentoo Weekly Newsletter" of a few weeks back.

      I have run 3.2.1r6 on my Gentoo machines since it came out with no problems whatsoever.

      BTW, anyone know when some more Duron/Morgan specific optimisations will appear? I'm using cpu=athlon-xp at the moment...

  • Watcom was great. How about today? (Score:5, Interesting)

    by CresentCityRon ( 2570 ) on Saturday February 08, 2003 @03:03PM (#5260060)
    In the late 80s (?) Watcom products were really great. They were beating on everything for the Intel platform.

    I received the email yesterday about Watcom's "release" to open source. In that email it says that Sybase felt there was no commercial value in the product anymore so they released it. My question is "Has Sybase been keeping this thing up? Is it useful today?" Or is this a scam to try to give life to a dying patient? I mean perhaps people working on this might be better off working on gcc or something.

    Thanks!

    • Re:Watcom was great. How about today? (Score:5, Interesting)

      by robbyjo ( 315601 ) on Saturday February 08, 2003 @05:42PM (#5260741) Homepage

      One thing I know is that their optimization routine rocks.

      Well, optimization routines can be divided into two parts: One is architecture independent (which involves simplification of AST and stuff) and the other is architecture independent. IIRC, their architecture-independent optimization was really great. It can correctly detect redundant codes and simplify it.

      I used to be an ASM programmer as I was a performance freak. When I compile my C/C++ program using Watcom, it almost always produced near optimized (i.e. the "gold-standard") asm code. I knew this when I dumped out the assembler code.

      I knew that their arch-independent optimization is really good because when you add things such as calculation of busy expression (i.e. expression that you used over and over) and stuff, it correctly cache the calculation before hand. So, you will save a tremendous time, especially if you do it in a loop. The problem was (again, IIRC) that was not perfect and some of the expressions are left undetected. But, that's probably a bug.

      IMHO, arch-independent optimization play a lot greater role than the arch-dependent one (ok, some of you may not agree with me). Things like peephole optimization is great, but is of limited usefulness once you apply the correct transformation of the AST and other internal structures.

      This is also partly why Intel optimizing compiler is also great. I heard that some of the folks are doing partial evaluation on the code -- which can greatly help speeding up the result. The idea was: If you use a particular routine (like function) only with a handful of value range, it will automatically create a specialized and optimized function for you exploiting the nature of the input values. For example: You probably have seen the routine that calculates (-1)^n used in a routine that calculates x^y. The optimizing compiler thus should be able to generate: return (n && 1 == 0) ? 1 : -1; instead of the looping. This only involves some (expensive) static analyses computations. I have yet to see this in other compilers.

      Therefore, this release is really really good thing. I hope that GNU compiler teams would pickup some of their good stuff.

      • Or is this a scam to try to give life to a dying patient?
      No, it is not a scam. Sybase truly does not care what happens to WATCOM C/C++ (so long as it doesn't come back and bite them on the butt.)

  • Superb! (Score:2, Funny)

    by occamboy ( 583175 )
    Another version of FORTRAN! Yeah! Now if I can just find a card punch machine and reader on eBay, I'll have hutled into the 1970s!

    • Re:Superb! (Score:5, Informative)

      by grub ( 11606 ) <slashdot@grub.net> on Saturday February 08, 2003 @03:44PM (#5260240) Homepage Journal
      Don't laugh, Fortran is still widely used in the scientific field. Optimizing compilers such as the SGI/MIPS compilers do good jobs at generating tight code from Fortran. C and C++ are not the easiest things to optimize automagically.

      It's no coincidence that SGI and Cray have excellent Fortran compilers, their customers demand it.

      (sorry I spent all of last Wednesday in 2 seminars with a fellow from SGI's Canadian HPC group, I'm still buzzing. :))
      • what version of FORTRAN does their compiler support? (I'd check myself but their site is horribly slashdotted.) I've been wanting to learn FORTRAN for a good while, but F77 is a bit of a drag and AFAIK it's the only version supported by a free toolset (g77). (If somebody could point out a free tool(set) that could handle F9x that I'm unaware of, I'd greatly appreciate it.)

        • Re:Superb! (Score:2, Informative)

          by RV.eq.VFG ( 609123 )
          If somebody could point out a free tool(set) that could handle F9x that I'm unaware of, I'd greatly appreciate it

          Its not free in the FSF sense but intel do a f95 compiler which is free for personal use on linux (x86 or itanic only).

          The g95 project is developing a free f95 compiler but it is not ready yet: http://g95.sourceforge.net/

    • Another version of FORTRAN! Yeah! Now if I can just find a card punch machine and reader on eBay, I'll have hutled into the 1970s!

      The state of the art supercomputers in this country, the ASCI machines, primarily run Fortran codes. I would say that half of all new scientific applications are still written in Fortran. Your post isn't funny, its ignorant.

  • GCC performance and another thing... (Score:3, Interesting)

    by 00_NOP ( 559413 ) on Saturday February 08, 2003 @03:03PM (#5260068) Homepage
    1. GCC: My sense is that it is not a very high performance compiler - is that true? Would a better GCC make a big difference to the free software/oss world?

    2. Does the Watcom WIN32 binary run under WINE?
    • Depends on the platform. Generally, GNU C/C++ is a good compiler. Sometimes, it lags a bit behind one or the other proprietary compiler for some specific chip (e.g., P4), but it usually catches up quickly. The best way to make it catch up quickly is to come up with specific examples where it could do better--the gcc developers are responsive.
    • "1. GCC: My sense is that it is not a very high performance compiler - is that true? Would a better GCC make a big difference to the free software/oss world?"

      That depends on what you mean by "high performance".
      If you mean how fast GCC can compile stuff, then it's probably not the fastest compiler in this world. Hopefully precompiled headers support will change this.
      But if you mean code speed, then GCC 3.2 is great. It generates code that rivals that of Intel C++.
  • What's the difference between using WatCom's complier and GNU's? How do you make a choice over which compiler to use?

  • Performance comparisons (Score:5, Interesting)

    by golrien ( 528571 ) on Saturday February 08, 2003 @03:14PM (#5260114) Homepage
    I was going to ask if there were any performance comparisons around showing how Watcom performed, but then I realised that anyone with half a brain ran something through Google before Slashdot.

    Win32 compilers (not including Watcom - and with good reason, it's a bitch to set up on Win32) [willus.com]

    as linked from the djgpp FAQ, some info on DOS compilers [geocities.com].

    So, hooray! A lesson in using Google before Slashdot mixed with some blatant karma-whoring.

    PS. this [bagley.org] is good too.
    • The choice of optimization flags for GNU C/C++ is pretty simplistic in those benchmarks, and yet it's only about 35% difference in performance. I think the conclusion should be: it doesn't really matter which C/C++ compiler you use.

      One particular issue that comes up again and again is that GNU C/C++ doesn't use inline special functions by default because the Pentium instructions are not standards conformant (they apparently don't give correct results for large arguments). Intel seems to inline those with no hesitation. Any benchmark comparison should probably be run with "-ffast-math", in which case the difference between Intel and GNU C/C++ shrinks to 12%. And I wouldn't be surprised if that remainder weren't due to some other questionable shortcuts Intel is taking.

      • (not including Watcom - and with good reason, it's a bitch to set up on Win32)
      How is Watcom a bitch to set up? You must be crazy! Its far and away the easiest compiler to set up, or change the install for. The only tricky points is setting up the debugger device, and the environment variables, but those should be done automatically, and is explained completely in the various FAQs and readmes.

  • No Time (Score:4, Funny)

    by Anonymous Coward on Saturday February 08, 2003 @03:15PM (#5260116)
    Sorry, no time to read this now. Will catch it on the repost....

  • Who is using Watcom in production? (Score:3, Interesting)

    by Anonymous Coward on Saturday February 08, 2003 @03:18PM (#5260125)
    Could someone post information on what companies are using Watcom and which products they've built with it?

    This would also be excellent information for Watcom to put on their site. It would give them much more legitimacy.
  • Has anybody heard any news recently from Watcom/Sybase about the 370 versions of Waterloo C, WATFIV, WATBOL, Pascal, Basic etc?

  • GCC (Score:5, Informative)

    by mark_space2001 ( 570644 ) on Saturday February 08, 2003 @03:35PM (#5260195)
    I'm with michael on this one. There are a lot of free compilers out there now, including Microsoft VC++ [microsoft.com] and Borland [inprise.com]

    Gcc is good, open, and could use some work, so please think about helping out. My favorite is MinGW [mingw.org] which is a really nice and decently maintained Win32 version of gcc and binutils. MinGW also distributes MSYS [mingw.org] which is a bash shell and other gnu utilities that make a windows box capable of running a Linux configure script. This allows much easier porting of GNU applications to windows and vice versa. There are several GUI compilers based on MinGW too, see the web page FAQ. A nice GUI GCC based compiler for Win32 is Bloodshed Dev-C++ [bloodshed.net], which I've used.

    Cygwin [cygwin.com] is good too but I prefer MinGW (obviously).

    So think about helping out, our tools will only get better if folks work on them.

    • Re:GCC (Score:2)

      by ryanr ( 30917 )
      Since when is VC++ free? What you linked to is the .net SDK download... does that include a compiler?

      • Re:GCC (Score:3, Informative)

        by The Bungi ( 221687 )
        Yes. It includes the C#, VB.NET and JScript.NET compilers, as well as the C and C++ compilers, along with the up to date libs and headers.

        This is surprising (was to me), because although the MS linker had been available previously with the Platform SDK, the compiler itself had never been (the libs and headers were).

        The .NET compilers have to be present in any .NET-based environment, so they have no choice but to ship them. But the C++ compiler does not. I'm not sure why they're doing this now, but hey.

        In fact, there are a couple of projects now trying to get together a free front end/IDE for the compiler, although I'm not sure if that violates their EULA. There are free/open front ends for C# (SharpDevelop and WebMatrix) available today, of course.

    • I'm with michael on this one. There are a lot of free compilers out there now, including Microsoft VC++ [microsoft.com]

      Last I checked,the MS VC++ compiler ran you over 1000 dollars for the basic version [microsoft.com] or 549 for an upgrade. The .Net development kit you point at only has a C# compiler for .Net, it can't make native executables.

      • I've never actually downloaded that package. It's from a list of free C++ compilers, the same one I got the Borland link from.

        I'm taking someone else's word that there is a command line version of VC++ in there somewhere. If I'm wrong, *shrug* I use MinGW anyway. ^_^
      • I'm looking at the program folder now and it includes the C++ compiler which compiles to native and .NET managed.

  • Watcom Memories (Score:3, Insightful)

    by Lucas Membrane ( 524640 ) on Saturday February 08, 2003 @03:44PM (#5260238)
    The IDE's that Watcom had were refreshingly different. Their C++ IDE was good, but when they upgraded the C++, they came out with Power++, which was a very nice RAD product, but it was too buggy. If the compilers are cleaned up and they open source the IDE's too, this might be of value.

    What killed them? Did they pull all their brains off C++ to work on PB? Was competition from MS too tough? Was their GUI builder (licensed from some 3rd party) too lame? Was the cost of implementing the C++ standard too high? (Watcom was late to offer STL -- they included their own (way different) libs instead.)

    We were a couple of generations back on chips when Watcom pretty much stopped pushing their compiler technologies. I wonder how much they lose by not having optimizations targetting new hardware features.

    • Re:Watcom Memories (Score:5, Informative)

      by Locutus ( 9039 ) on Saturday February 08, 2003 @04:28PM (#5260437)
      What killed them? If you remember when this all was happening, Microsoft was out to take over C++ and all the companies who did cross-platform frameworks were attached in standard MS style. Monopoly money funded subsidizing of their Visual C-- product and MS-MFC. Then when Watcom wanted to include MFC with the Watcom C++ compiler package, Microsoft said that would only happen if ALL other frameworks on the CD were removed. Remember, Watcom C++ shipped with DOS16, DOS32, Win16, Win32c, Win32, OS/2-16, OS/2-32 compilers with the IBM OCL framework and some others like Zinc if I remember correctly.

      Watcom would have to eliminate all the support for the other platforms to license MFC and ship it with their compilers. And Microsoft was all but giving Visual C-- away at the time also.

      The Watcom compiler was one of the fastest on the market from what I remember. I had heard that IBM used it for the WinOS/2 subsystem on OS/2 to make it a faster Windows than Dos/Windows.

      Think about it, Microsoft HATES anything that abstracts the Win32 API and crossplatform frameworks and crossplatform compilers where one of the early targets of the beast in Redmond. Borland was the only one that got any money out of taking Microsoft to court for attacking it's business using illegal means. The others were too small and just folded and looked for other ways to make a business.

      LoB
  • Now all we need to see is Intel releasing their compiler. As other posts have mentioned, gcc could use some optimization improvments, and Intel has em.

    It's been a long time since I've used the Watcom compiler, but it used to be the bomb. I use gcc exclusivly now, and sometimes pine for the day when a build was done in seconds instead of minutes. I'm betting it will be a difficult undertaking to incorprate the Watcom code, though.

    • gcc could use some optimization improvments, and Intel has em.

      I'm not so sure. In many of the benchmarks I have seen, differences have been to questionable optimizations by the Intel compiler; often, you can enable the same optimizations in GNU C/C++ if you like, but they aren't on by default.

      I suspect that GNU C/C++ might see some improvements in P4-specific optimizations, but they are going to happen.

      In general, the best way to help GNU C/C++ to improve is to do benchmarks and track down performance bottlenecks. Throwing out GNU C/C++ for Intel C++ won't be a good solution in the long run.

    • No, actually (Score:5, Interesting)

      by exp(pi*sqrt(163)) ( 613870 ) on Saturday February 08, 2003 @04:44PM (#5260500) Journal
      Intel have a long history of claiming that they produce a fast compiler, after all they know the Intel specs. However I have never found this to be true over the last 7 or 8 years (I think it was called Proton years ago). I am not sure I have found any code that is significantly faster compiled with the Intel compiler and have found much that is slower. I haven't tried v6 of their compiler though. Maybe, just maybe, they've now picked up some tricks from the KAI guys.

      Incidentally, vectorization in Intel C/C++ is a joke. I put so many hints into my code (aligned variables, processed stuff in suitable sized chunks etc.) and still couldn't trigger the compiler to vectorize. It's much easier to insert SSE instructions yourself.

      The Intel compiler has better error reporting than MSVC++. I use it when I don't understand why MSVC++ is barfing on my template code. This is more useful than it sounds!

      • Most people who have looked into this have not found your claim to be true. The Intel compiler *does* produce better code on average. I will agree with you about the code vectorization of the Intel compiler except for the very latest version of it which has actually shown itself to vectorize pretty much any time there is a reasonable opportunity for it.

  • Cross compiler for PIC microcontrollers? (Score:3, Interesting)

    by EMIce ( 30092 ) on Saturday February 08, 2003 @03:58PM (#5260305) Homepage
    I have been told that gcc made assumptions about processors in its design that preclude it from being made to compile for the PIC line of microcontrollers. These are great inexpensive chips that are used commercially and very accessible to hobbyists, with many "el-cheapo" programmer designs that can be hacked together with a few Radio Shack parts. They are a great way to get into the hobby, with plenty leeway to build the simplest to advanced projects, but I haven't yet found a free C compiler that targets PICs. Any idea if this new compiler will support the PIC's odd architecture?
    • PIC microcontrollers only have one general purpose register. The limitation with GCC is that it probably assumes a minimum of a certain number of registers.
    • The PIC can only store 8 return addresses on its stack, and it can only store return addresses--you can't use the stack for saving register values, for instance. This basically rules out almost all high level languages, usless they want to muck around with simulating a stack through some slow and tedious process.

      I believe there are some limited HLL's designed specifically for the PIC's limitations. However, I think the best course of action is to use a decent macro assembler. PIC assembler is easy enough to learn that it shouldn't be an obstacle for any project that could reasonably be implemented on its meager architecture.

      Oh, by the way, Atmel AVRs are the fashion this decade. No self-respecting nerd is using PICs unless they are stuck in the '90s.

  • The more compilers the better. (Score:3, Interesting)

    by Anonymous Coward on Saturday February 08, 2003 @04:51PM (#5260535)
    Borland's C++ compiler pumps out some fairly slow code, but it's really good at catching mistakes the others will tolerate. Some of the problems it flags are technically legal by the standards but indicative of brain farts. Even if you throw away the binaries, it's a nice tool for weeding out slop.

    VC++ is okay, beware that the cheap/free edition leaves out the optimizations. The standard library is much improved in the 7.0 release, but MS still like to disable some default warnings to paper over their own historical sins to keep things like MFC happy. The IDE is pretty nice and the documentation for the standard library is usually damn good, but I will never forgive Visual Studio's authors for the way they chose to dedent the case clauses in switch blocks.

    g++ is finally a nice compiler in its 3.x incarnation. In the 2.9x days it was utter trash. The generated code is good and usually quite fast, but a bit on the bloated side. It is a little more permissive than I'd like even with -Wall -pedantic, but that's okay since it's not the only compiler out there. This is a good choice for producing final executables.

    The verdict is still out on Watcom. Bundling STLport already puts it a step ahead of most, that thing can be a bitch and a half to get working with some of the commercial compilers.

  • Long File Names Support (Score:5, Interesting)

    by Anonymous Coward on Saturday February 08, 2003 @05:16PM (#5260633)
    I downloaded and installed RC2 last week and it went into the C:\Program Files\watcom\ directory. By default, it wanted to install to the C:\watcom\ directory.. with good reason.

    The long file name support is broken everywhere in this new release of Watcom C/C++/Fortran77. Even the included IDE doesn't do long file names. So you can imagine my disappointment when I opened C:\Program Files\watcom\\hello.c and hello.cpp in the IDE, only to get a blank file named "C:\program".

    This is 2003 and Windows 95 didn't just come out last month. I mean, Sybase told us on June 30, 1999 that v11.0 would be the last major release of Watcom C, and long file names worked just fine there. Reincarnated as open source now without LFN support, does this mean that this feature got left behind in the afterlife?

Slashdot Top Deals

Your own mileage may vary.

Close