Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
News

Sybase to Open Souce Watcom C/C++ & Fortran Compiler 175

Posted by Hemos from the opening-it-to-the-world dept.
Kendall Bennett writes "Rumours have been running around for some time, but now it is official. Sybase has announced that it will be releasing the full source code to the Watcom C/C++ and Fortran compilers under an Open Source license. For more information see the new Open Watcom website." The press release states as well that the license will comply with an OSI approved license.
This discussion has been archived. No new comments can be posted.

Sybase to Open Souce Watcom C/C++ & Fortran Compiler More

Sybase to Open Souce Watcom C/C++ & Fortran Compiler

Comments Filter:
  • Obviously, this is no category killer. However, just having the source open might be a good thing as a reference for others working on compiler projects, such as CS students or GCC hackers...

    GPL would be nice (especially for those reasons listed above)... One can at least hope...
  • It was also the best pre-win95 compiler for PC games development, largely thanks to the free DOS extender. Many fond memories.
  • Oh yesh.
    I'm currently working on my FortranOS. If you thought PerlOS was slow, just you wait. Boots in minutes.

    obviuosly up to no good,
    -Kabloona
  • If Borland opened it's Object Pascal compiler (independent of Delphi), I'd switch to it for many development projects

    Have you tried Free Pascal [freepascal.org]? It supports Object Pascal and Delphi code. And it's already free, so there's no waiting.

    -- Floyd
  • Watcom VI source code will be included as far as I know.
  • Nowadays GCC has very good general optimizations and a lot of x86 specific ones (386, 486, pentium, pentiumpro, amdk6). And in GCC 2.96 and upwards the x86 backend was rewriten for better optimizations, support for amd athlon, etc.
    To enable these, you need something like:
    gcc -O2 -mcpu=pentiumpro -march=pentiumpro ....
    (this example is for pentimpro's and family, ie, PPRO, PII and PIII).

    I have compared the code generated with that of Borland C and MSVC and it's generaly better (at least with C input).

    But stil, it's not perfect. Look at http://gcc.gnu.org/proj-optimize.html , wich describes some probles as February 2000 (some of these are better now...).
  • When Netscape went open-source, the mozilla team still started from scratch because the old code was such a mess. If Microsoft released their code, it too would only serve as a reference. The value of giving away the Watcom compiler is not in the binary you get from compiling the source (which you could already get for a fee), but in the freedom to use whatever useful bits are buried in the source itself.

    That's one of the main points of Open Source.
  • 11.0b still does support NLM development. Stephen Howe [TeamSybase]
  • Oh, sure, it supports a rather castrated sub-set of Pascal.

    None of my platform-clean Delphi code will compile on Free Pascal. Why? I design the code I write. With interfaces (pure virtual base classes, in a sense).
  • Tassach, Do you belong to the Power++ list server? It is the best place to get help if you are still using this. See http://www.neatech.ch/Lists/ Stephen Howe [TeamSybase]
  • Sybase never open sourced ASE. What they did do was make ASE 11.0.3.3 available for Linux for free with (what I consider) a very liberal license.

    You can't get support for 11.0.3.3 for Linux, but you can still buy 11.9.2 for Linux (and get support with that.)
  • Watcom was a great compiler, produced (and I must say, still produces) some of the most highly optimized code of any compilers. I still use it for my minor projects...
  • I *was* going to comment that obfuscated c tends to obfuscate function, while obfuscated fortran tends to hide transfer of control. However, I think I"d blanked out nightmares like that one.

    I never truly understood the horror of spaghettic code until I needed to use a program of my boss's. I was using Fortran 90 at the time (Absoft on x86 Linux and dec/compaq on alpha [and Steve was the one who answered some of my problems, come to think of it {and while I'm abusing subparentheses, my boss probably would have had an alpha if compaq fortran had been available for linux/alpha at the time}[), and the program was allegedly in F77. It was closer to FIV, but hadn't even used parts of *that* that would make it clearer (I suspect it descended from the Numerical Recipes book), so the thing ended up as a mix of II, IV, 77, and 90 . . . but that we could have dealt with. It was all of the gratuitious gotos that meant it took three days to figure out what the program was doing . . .

    hawk
  • I think you'll be interested in

    http://www.geocities.com/SiliconValley/Vista/655 2/compila.html

  • It seems like it would be useful to make a partial distribution of the binary version available for people that can access the platform SDK, etc, through MSDN subscriptions.
  • There are several great things to get out of this source code. The compilers are well optimized, the IDE was great, their tools were nice. I'd love to have some of those nice and familiar tools under Linux.

    It would be nice if the liscence is broad enough so that optimizations can be moved into g77. Watcom's compilers produced tight fast code, that was generally faster than g77. Watcom console executables could run faster with under Windoze than g77 compiled programs outside of X on the same machine. I ended up using g77 anyway because it could compile very old fortran without much modification. I want the speed too.

    Their IDE was straighforward. It was so easy to use that even I could compile mixed C, Fortran code. It took care of grunt work that will take me a long time to learn how to do with make. Compared to MS IDE, which ditched FORTRAN, it was a joy. I can't tell you how much time their GUI debuger saved me.

    Their documentation was informative and well organized. Almost as good as Sun.

    They also had a cute little VI for window called VIW that was specifically set up for code editing. Color coding of integers and keywords made reading code easy on the eyes. It put in different spacing for FORTRAN and C code, and did a load of other things that will take me forever to dupicate with VIM. I'm not sure, but I think it could recognize straight VM commands. Did not know enough VI at the time.

    Over all, Watcom was much closer to normal standards than, Humpf, microsoft. I spent $200 bucks on one of their compilers and it was worth every penny at the time. They helped me grow, and escape the MS trap. Things I learned there I could use elsewhere.

    Great going Sybase!

  • It's FORTRAN-77. I know some people whu use it and they seem to be happy with it.
  • The game Blood was written using Watcom C. I'm pretty sure that's not the only DOS-based game written using this compiler. It seriously kicks butt in compiler optimizations. Now, if could get Borland to open-source the editor environment, we'd have the perfect C development environment...

  • Optimizations (Score:3)

    by Prince Caspian ( 13062 ) on Tuesday August 22, 2000 @10:15AM (#836389) Homepage
    The enduring value of the Watcom C compilers have been their optimizations. Having worked at Sybase/Watcom on a co-op term, I know the Watcom compilers were preferred over Microsoft ones because of the smaller/faster code produced. Sybase eventually decided to give up once began Microsoft pushing technologies that required compiler changes -- like the latest COM stuff.

    In theory, we should be able to take some of the smarts from the Watcom compiler and put them in GCC. I bet this won't be very possible in practice simply because of architectural differences in the compilers.

  • Ought to be GPL (Score:3)

    by jmv ( 93421 ) on Tuesday August 22, 2000 @10:17AM (#836390) Homepage
    I really hope the code is released as GPL (or a GPL-compatible license). That way, the egcs (now gcc) team could incorporate some code (mostly optimizations I guess) in gcc. Also, I *think* the fortran frontend (g77) is missing a lot of features (like pointers). Maybe they'd be able to use Watcom fortran for these features... or even take the code to build a new frontend.

    What's clear to me is that few people would be willing to continue developping watcom. I see more future in incorporating watcom stuff into gcc.
  • Not only does posthumous liberation get a good product out into the community, it accomplishes one more valuable service. It gives people the source for a technologically better (usually) alternative to whatever M$ has crammed down everyone's throat.

    Watcom of years past is better than today's VC++ compiler. Their Fortran was great too. Now they're here and they will benefit gcc - if in no other manner than by letting the gcc developers consider alternative solutions.

  • How useful is this really? (Score:4)

    by Riplakish ( 213391 ) on Tuesday August 22, 2000 @10:18AM (#836392)
    Direct from the OpenWatcom FAQ [openwatcom.org]:

    Q: What compilers will I need to compile the source code?

    A: Initially the Open Watcom 1.0 compiler will require an official copy of the Watcom C/C++ 11.0b compiler, with the 11.0c binary patch release applied in order to successfully compile it. This is due to the need to rely upon proprietry SDK's for platforms such as Windows, and OS/2 that cannot be distributed along with the Open Source 1.0 compiler release. It is planned to eliminate this dependency in the Open Source 2.0 release, by allowing the compiler to work with freely downloadable SDK's for the supported platforms.

    So in other words, to compile the 1.0 Open-Source version, you need the commercial 11.0c version. So everyone run out and buy the 11.0c version for ~$200 so you can compile your free Open-Source version. Or you could wait god knows how long for version 2.0 to come available without the 11.0c dependency.

  • Huh? What planet are you from? MSVC is probably the second best compiler available next to Intel's own C++ 4.5. From an eweek article (which you can find at here [zdnet.com] )

    "Even in pre-release form, Visual C++ 6.0 yielded the fastest time we've ever measured for any development tool running the language-neutral, CPU-intensive Tak benchmark. The Microsoft 6.0 beta compiler yielded code that ran an astonishing 20 percent faster than Version 5.0, when using all of the 6.0 version's aggressive new optimizations for Pentium-class processors. Visual C++ 6.0 even achieved a surprising 10 percent edge in Tak speed over Watcom C++ 10.5, our previous record holder among acceptably stable C++ implementations. We reserve judgment on Microsoft's success in implementing
    new C++ features in this release while also maintaining reliability; in our tests, however, we encountered no problems with generated code. Visual C++ offers several different approaches to pleasing the performance-
    sensitive user. In situations where some of an application's features are rarely used, and where a delay on first invocation is acceptable to most users, Visual C ++ 6.0 applications will be able to defer their loading of dynamic link libraries to accelerate application startup. Alternatively, libraries can be loaded on startup in the usual manner to speed subsequent invocations"
  • Wrong article :P


    Abstainer: a weak person who yields to the temptation of denying himself a pleasure.
  • Well, after having worked for four years + for Sybase Professional Services I consider my support for 11.0.3.3 under Linux better then what 98% of the customers get with supported versions.

    Despite being phased out it's still a great industry strength database engine and if you don't really run heaviest load OLTP systems (and the official support is an issue of course), I don't really see a need to upgrade.

    Despite Sybase' motivation I think they're doing a lot of good for the Linux community (e.g. release of Replication Server) and they deserve more credit for technically great products then their rotten marketing department would make you believe...

  • You should realize that Open Source is much more than just the Linux kernel...

    It's very important to keep the mind open as well, not just the source.

    Regards, Tommy

  • You're the one to correct me if I'm wrong :), but isn't the Compaq compiler for Linux still alpha (the processor, folks, not the status) only?

    When we checked it out (but this was 3 or 4 years ago), the only choices for F90/95 on linux/x86 were NAG and absoft (and see above for NAG).

    Hmm, I guess I need another good look at the market . . .
  • Yeah, X-COM Apocalypse was written using the Watcom C compiler. Their debugger ruled as well.

    Thad

  • In terms of compliance it is F77 compiler with F90 extensions. See the Sybase technical document "FORTRAN 90 Compliant Extensions" http://www.sybase.com/detail/1,3151,44419,00.html I do not know about performance othr than it uses the same code generator as the C/C++ compilers Stephen Howe [TeamSybase]
  • Watcom is fast and will host on DOS/Win16/Win32/OS2 for DOS/Win16/Win32/OS2/Novell/Autocad/QnX targets - surely a worthy thing ...
  • I remember that one of the production versions of Quake (the one burned onto a CD) was compiled in Watcom because it was fastest? :) *shrugs* I believe that is true anyone remember??

    Jeremy

  • Right now the only real compiler on Linux is GNU C

    Actually that isn't true. There are already a couple of (albiet lesser known) commercial compilers for Linux:

    KAI C++ [kai.com] -- Commercial C++ compiler for Linux.
    Portland Group [pgroup.com] -- Commercial C, C++ and Fortran compilers for Linux.

  • The Open Watcom compiler products are the first and only mass-market commercial compilers to be open sourced...

    This, of course, ignores the fact that there is a mass-market compiler which was never commercial, and is the very definition of open-source / free software...
  • I was moderated down for this earler today [slashdot.org], but I'd be willing to buy Hemos a dictionary if he would learn how to spell.

  • Will there be official binaries for OS/2?

    Any chance that it can compile with 10.6?
  • I recently became annoyed at gcc for failing to do the right thing with this expression:
    (unsigned int) ((unsigned long long) x / (unsigned int) y)
    It should produce a 64/32 divide (on 32 arch); instead it produced 64/64, which is not only a lot slower, but isn't even supported in the kernel. Arrgh.
    --
  • We've used the Portland Group Fortran & C compilers for a while. They are quite good...
    I've had major troubles with their OpenMP>/A> parallel support. And their debugger lies to me. [openmp.org]


  • We tried the demo version of nag back before we bought absoft, back in summer/fall 1997. Hmm, now that I think of it, it was probably spring/summer 98 by the timie we bought it, but anyway . . .

    We had problems getting the demo to work. And while it was F95 to Absoft's F90, it generates C rather than an executable (which is where the performance issue comes from)--and performance is a *major* issue for what I do :) What I can solve is limited primarily by the power available.

    Absoft sales was a series problem, though--it took several days for them to call me back. With sales that slow, I didn't want to even *think* about what tech support would be like--absoft tech support had called me back, pre-purchase, well before we eger heard from the sales folks at Nag. In all fairness, I heard later that the tech folks at Nag are much better than their sales counterparts about getting back to people, but the combination of no return calls and the lack of actual executables made absoft an easy choice.

    We never regretted it. Tech support usually got back to me that afternoon if I sent a message in the morning, or the next morning if I sent it in the afternoon. They also sent responses by email to questions I asked in the Fortran Newsgroup (Steve Lionel also answers an impressive volume there).

    hawk
  • Does anyone still use Watcom? Why?

    However, if you do (for whatever bizarre reason) at least you can now be assured of support.

    OSing dead products is better than burying them, but not as good as OSing live products.

    At the time of writing, this is a first post.


    --
  • Well, I had to get used to FORTRAN77 "legacy" code two years ago (that was 7 years after I learned Pascal and C). I know I wasn't the only one who spent ages on finding a very strange bug...

    The formula extended beyond the 72nd character!
    See also this [uga.edu] for good FORTRAN programming style. ALWAYS USE CAPITALS IT LOOKS WAY BETTER THIS WAY;-)
  • Not clear at all. There is a small army waiting to develop the compiler. Thre is more than you realise, it is not just an Intel x86 compiler... Stephen Howe [TeamSybase]
  • Anyone have any information of performance and compliance of their Fortran compiler?

    Bryan R.
  • In what way it is better than DJGPP? Look there [geocities.com] Disclaimer: I don't have watcom c myself, so I cannot verify info there.
  • Yet another compiler with crappy inline ASM. Is it just me, or is MSVC inline ASM the prettiest thing around?
  • Last I recall, I think MSVC took the lead in optimizations around version 6.
  • Half-life was written in Visual C++ (as was Quake, I think), what's your point? As for Borland, they won't even open up their compiler, what makes you think they'd open up the IDE? (Though they should, god knows they're not getting any more market share in the commercial market)

  • Fortran 95 (Score:3)

    by Plastic Puller ( 135870 ) on Tuesday August 22, 2000 @10:26AM (#836420)
    I'm hoping that it is a Fortran 90/95 compiler. A lot of people scoff at Fortran, calling it the cockroach of computer languages (millions of apps out there that just won't die!). I used to be one of them (one of those people, not the apps).

    However, in graduate school, I was developing a biology simulation in Matlab. The development went well, but the execution was painfully slow. Since Fortran 90/95 was syntactically similar to Matlab I was able to port his huge simulation in a few days and keep working in Fortran without much of a learning curve. Say what you want, for high performance numerical computing with lots of vector operations, Fortran is one of the best languages out there.

    Bringing this back to the open source world, numerically intense vector computations can be developed in Octave, and easily ported to Fortran 90/95. It's a one-two punch that I would definitely find useful. Unfortunately, the only free Fortran compilers I've found are for Fortran 77.

    Just my two bits.

  • Sounds to me like, "We've got this product and our sales are really slipping and it's costing us more to maintain it than we're bringing on sales and upgrades. Hmm, let's just throw it away....No, wait! Let's release the source code, let the customers maintain it, call it 'Open Source' and get a temporary boost in our stock price to offset our losses. Yeah, that's the ticket."
  • Have you tried Free Pascal? It supports Object Pascal and Delphi code. And it's already free, so there's no waiting.

    And it compiles 10x slower than Borland's compiler.
  • It seems to me that we got pretty strong warnings from a few locations that the Portland compiler just plain wasn't ready for prime time, and we stayed away from it. Now that I think o it, one of our concernes was multiprocessing, as he'd had the budget for a dual PII (III? 333mhz), and there were libraries available for absoft that would spit out multi-processor code for much of the math (we bought them, but I never got as far as working with them).

    This time around, performance is important, but I'll be developing on my machine and usinc scp/ssh to send the real work to the heavy-duty machines at main campus.

    hawk

  • Re:Watcom (Score:2)

    by PD ( 9577 )
    I never used Watcom, but I respected them mightily. Back in 1992/1993, the compiler that I used was Borland C++ 2.0 and 3.1. That was the state of the art for inexpensive compilers. I had read for years about Watcom's compiler. It was more expensive than Borland's, but it supported the Weitek coprocessor chip that you could install instead of a 387. That made Watcom's compiler favored for scientific and engineering work.

    But, what made me drool was the support for DOS Extenders! Back then I was using Borland C++ and those ghastly overlays to shoehorn a 1 meg+ sized executable into the roughly 580K left over after DOS 5.0 was loaded into memory, along with all the network and CD-ROM device drivers. The idea that I could write a program with a DOS extender that would occupy up to 16 megabytes was an incredible idea. I hoped that Borland would include a DOS extender in their upcoming compiler release.

    Alas, it was not to be. Borland abandoned their hard-core DOS users and threw in some half-assed Windows 3.0 support instead. Sure, I could write a program that occupied up to 16 megabytes, but I was still stuck with a silly resource limitation and a flaky operating environment. What good was it to write a program that would only run for 5 minutes between OS crashes? I abandoned Borland, picked up Linux, and haven't looked back. From the looks of it, just about everybody else using BC++ back then also abandoned them.

    If Watcom had made their C++ compiler just a little bit cheaper, college students everywhere could have afforded it, and perhaps DOS would have held the mainstream a bit longer.

  • Bzzzt! Wrong! See "The Design and Evolution of C++" by Stroustrup for a full explanation.
  • Don't knock Fortran, there's life in teh old girl yet.

    For whatever reason (partly historical, partly due to language sturcture), all the supercomputer optimising compilers that I've got access to use Fortran [0].

    When I say optimising, I mean using vector registars, and al the other funcky gubbins of those babys.

    Fortran also has the complex data type, something sorely lacking in C, from the point of view of mathematical work.

    In fact, I am now in the situation of learning Fortran, after having learned programming in C, purelt because numerical and scientific computing is easier in Fortran.

    And for the supercomputers too :)

    [0] Maybe I just don't get acess to good C compilers for the Cray. I dunno.
  • g77 and f2c cut it or some legacy applications. They don't have the extensions that many of us took for granted in the 80's, let alone anything resembling F90/95.

    For that matter, is there any F90 support in Watcom? Not that it will make much difference; we need to order a Linux Fortran compiler in the next month or so, so it looks like Absoft again (which is a fine compiler with the best tech support I've ever found for *any* product).

    hawk
  • It's just a shame Microsoft's C++ compiler doesn't implement C++.

    for (int ii = 0; ii should compile without errors.

  • I hate to break this to you . . . (Score:4)

    by hawk ( 1151 ) <hawk@eyry.org> on Tuesday August 22, 2000 @10:31AM (#836441) Journal
    . . . but Fortran *is* still changing, sometimes rapidly. No, it doesn't have everything that C does--nor should it. For many types of heavy computation, it is still the language of choice (Including my own research).

    The strengths aren't just from what is *in* fortran, but from what is left *out*. Because certain classes of pointers/objects/whatever aren't there, stronger assumptions can be made while optimizing. You can quickly write fast code faster in Fortran than C.

    Don't get me wrong--it's not that C *can't* produce numerical code as fast as the corresponding Fortran; it can. However, this happens after hand-tuning and optimizing the C, and it generally reaches roughly parity with the initial Fortran program.

    hawk, still using Fortran
  • Sorry, I meant:

    for (int ii = 0; ii < 4; ii++)
    {
    ...
    }

    for (int ii = 0; ii < 8; ii++)
    {
    ...
    }

    Should compile without errors.

  • I got that. I was just hoping :) I've been a fan if Digital Fortran for a *very* long time. I've only hit one bug in it, ever--and that was nearly 20 years ago on a PDP-10 . . .
  • What a large company, listen to their customers? No, never.

    :-)

    Don't get your panties in a wad. It was just my first reaction on reading the announcement. I never said it was true.
  • Way back when, some of the Atari and Amiga folk at UW were lobbying Don Cowan [uwaterloo.ca] to get Watcom to release a 68K version.

    There was an "unofficial tradition" that some of the internal folk had created a 68K code generator, but it never got released publicly.

    It is not at all obvious that the compilers are of vast continuing use; they have been strongly tied to the IA-32 platform for so long that it may well be that the onset of IA-64, combined with, as you say, the "latest COM stuff," meant that a big-time redesign would be necessary for Watcom C to be useful for Windows deployment next year.

    The availability of source code may nonetheless be useful to glean useful optimization techniques that may be redeployed with GCC. I'd heard at CSC [uwaterloo.ca] talks in the late '80s that there was a lot of "slick" static analysis that would be generally applicable to any architecture; as you observe, architectural differences between Watcom C and GCC might make it difficult to make them applicable. Hopefully some of the peephole optimization techniques would be useful for the IA-32 architecture, and by the time the "analogies" would be made to make them applicable, it might become possible to apply "analagous" optimizations to other architectures.

  • It is unfortunate that it requires some proprietary components in order to function.

    This means that if the compiler is to be of any continuing interest as other than a "bare husk" from which GCC might "mine" some useful techniques, there will need to be a project to create a set of tools basically corresponding to Binutils [redhat.com] and perhaps some portion of CygWin [redhat.com] so that there is some "base" set of tools and libraries that can be used to recreate themselves.

    The fact that there are existing GNU tools to that purpose ought to ease the task somewhat...

  • Congratulations and welcome (Score:4)

    by Junks Jerzey ( 54586 ) on Tuesday August 22, 2000 @01:36PM (#836455)
    This is a very good thing. I see a lot of people either putting down the Watcom compiler or making fun of Watcom for no longer being a major player in compilers. I'm surprised to see such sentiments from what is supposedly the open source community.

    Watcom's open sourcing of their C++ compiler is a good thing all around. It has generally been accepted that open source is of the most value for system software, because it serves as a foundation for the work of many other people. It is difficult to bet on a lesser known vendor, when they could go out of business without warning. This has happened to be me several times. Open sourcing compilers, or even just releasing them free of charge, as Borland has done, is The Right Thing. It removes unneeded pressure from choosing development tools.

    It is also excellent that gcc is getting more competition. gcc is a good compiler, and it has many boosters in the UNIX world, but it is crusty in manys ways, especially in the Windows environment. gcc has also been peculiarly slow in evolving for the x86 architecture, presumably because of initial personal grievances from FSF members. Watcom throws in a little competition. Maybe it is a better compiler. Maybe it generates better code. Maybe it has better error reporting. I don't know if it has any of these things, but it certainly has a good reputation.

    I would love to see other vendors follow suit. If Borland opened it's Object Pascal compiler (independent of Delphi), I'd switch to it for many development projects.
  • Visual C++ is useless if you need to target anything other than Win32.
  • WATCOM C includes MFC, at least with the commercial version they used to sell. My copy has MFC 2.5 and MFC 4.1. I don't write software that uses MFC so I can't say how good WATCOM's support is for MFC.

  • Just dont use it :) I've always wondered why C compilers included such foul beasts. Sprinkling one's code with machine-specific assembly is probably the easiest way to make sure code is impossible to maintain, and never ported to another platform!
  • GCC and Watcom are pretty useless if u need to target anything other than computers
  • Watcom was excellent for working multiple platforms (last two employers had OS/2 on the enterprise with a little DOS stuck in; say what you want but to date OS/2 has been far more stable than anything Microsoft has offered). I think it would be majorly cool if the multiplatform support was extended to Linux. I have used a couple of IDEs for Linux as well as GCC on the command line and frankly there is no good reason for a compiler to be as beastly to use as that. Watcom sports a basic IDE with basic project support as well as making fast and small executables. The Linux world could do far worse that porting Watcom to Linux.

  • Re:First Project: The Bootstrap Project (Score:3)

    by KendallB ( 4565 ) on Tuesday August 22, 2000 @01:53PM (#836474) Homepage
    > It is unfortunate that it requires some proprietary components in order to function.

    The only proprietry components are the SDK's, not the tools that are used. Included in the Open Source release will be full source code to *all* utilities such as the compiler, linker, librarian, assembler, resource compiler and much more.

    We are planning the Open Source 1.0 release to require the 11.0c compiler in order to build, but be able to rely on freely available SDK's to actually produce programs. Ie: you can download the Open Source 1.0 official binaries and the Microsoft Platform SDK (from the M$ web site), and start happily writing Win32 programs.

    One useful addition to the project would be additional support for non-OMF and non-PE executeable formats. Ie: support for ELF would be nice, so that it can directly generate Linux executeables.
  • No one knows what the language will look like in the year 2300 that scientists and engineers use, but they'll call it FORTRAN.

    But seriously, I'm glad that Watcom's doing this. It won't affect me for several years (and then only if they integrate their optimization techniques into gcc). But I think that it is a good idea nonetheless.

    I mainly use Alphas, so Compaq's compiler set (which does include F95) is good for me. I wish that they would open its source, but I don't really care since it works. They typically generate code that's 3.5 times faster than gcc, so maybe better optimization is possible for Intel boxes, too.
  • Deja doesn't go back before 1999 right now. Go to http://www.cir.nus.edu.sg/~dkiong/compilers/97/ [nus.edu.sg] and look through the articles titled as
    Problems with Hardware, Languages, and Compilers

    Definable operators (was: Problems with Hardware, Languages, and Compilers)
    Re: Definable operators
    It might be there somewhere.

    Hal Duston
    hald@sound.net
    If Al Gore invented the internet, why is it named after George W. Bush?

  • That's irrelevant, I was talking about speed. Still, VisualC++ isn't as standard complient as one would like. Of course moving a large-code base from one compiler to another is something I'd only wish upon those I really hated.
  • Inline assembly is useful for writing device drivers. You can keep everything in C and insert bits of assembler where needed.

    WATCOM C is also useful when you need to call libraries or ROMs with unusual calling conventions.

  • The following is from comp.arch, by Craig Burley, a brilliant C programmer and compiler writerwho has probably written more C than any other three of us -- and open-sourced it!! -- the primary author of "g77" and one of the "gcc" team:

    C is a great *tool*. It's *such* a great tool that because it, like awk, sed, perl, make, tar, and so on, necessarily defines an input "language" in the comp.sci (formal language) sense, the inexperienced conclude that it is a great *language*.

    Fortran comes from an older tradition when formal languages were less understood, and artificial languages (my term for true languages designed to meet artificial, e.g. technological, needs, covering computer languages and stuff like GUIs) even less so. As such, it didn't show the benefits of good formal-language design (e.g. nobody can say what "X(Y)=Z" really means in Fortran without knowing the context, and this does confuse programmers in practice), but it also didn't show the disadvantages of formal-language design techniques (e.g. the arrogance that says "if I can write a small-enough yacc input file for my language, it is therefore a Good Language").

    Yet, despite my long decades of distate for Fortran, the more I've learned about what constitutes good *language* design, the more I've had to conclude that, for scientific/numeric processing, Fortran not only *was* a better language in its day than C in *its*, but it (Fortran 90) is *today* a better language than C *today*. (And C++ is even worse a language than C. At least programmers know what `a = b + c;' means in C.)

    The essential lesson I finally learned was:

    Formal languages are to languages what mathematics is to music.

    I think the creation of the term "formal language" itself was a mistake, because it misleads the audience into thinking that *some* kind of language is being described, in a useful sense, but in fact "formal language" encompasses much more than the tiny portion of the generally useful term "language" than is connoted by the term, in much the same sense that "formal music" would have been a poor term instead of "mathematics".

    So we end up with "brilliant" C programmers who assume that, because C is (mistakenly) called a "language", and because C is a great *tool*, it is a good language, and since Fortran isn't such a great tool, it must be a lesser language, when the opposite is true....

    ...and he continues on for a couple of more pages, in news article reference y67mbmu7wr.fsf@tweedledumb.cygnus.com

  • I too enterred graduate school a fortran programmer, and I too did my thesis relying on Matlab. But the Matlab/C integratgion was really tight - so I learned C and didn't get stranded in a dying language. Since I learned C, I have never seen *any* non-legacy situation where Fortran was to be preferred over C.

    Why did you choose Fortran over C?
  • If you want to talk to Kendall Bennett about Open Watcom, then come to Warpstock 2000 [warpstock.org] on September 9-10 in Philadelphia. He will be giving a presentation [warpstock.org] on it.
    --
  • Sybase Power++ is [was] a great C/C++ development tool for doing client/server apps under Windows; much better than VC++ IMHO. I still use Power++ 2.1 a lot because it's the perfect tool for what I use it for -- developing front ends for Sybase databases. I for one am very happy at this news. I may even wind up making some contributions to this project.
    "The axiom 'An honest man has nothing to fear from the police'
  • I must be living in a different reality - since when has F77 pointers?

    Pointers are not in the F77 spec, but it's an extension so common that a good F77 compiler needs to have it. I know pointer support is one of the major reason people who need a fortran compiler can't use g77.

  • Watcom (Score:3)

    by pb ( 1020 ) on Tuesday August 22, 2000 @10:01AM (#836490)
    Watcom was an excellent C compiler; I hope some of their floating-point optimizations will eventually be folded into egcs, because I remember the default DOS-compiled BYTEMarks had a bit of an edge there.

    (Also, someone told me that when IBM recompiled the Windows source with it, it was about 30% faster at the time. I think that was for OS/2, but it was funny at the time. :)
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
  • The Watcom compilers are the compilers of choice by the people at QNX [qnx.com].

  • Open Fortran compiler, huh? (Score:3)

    by Rombuu ( 22914 ) on Tuesday August 22, 2000 @10:03AM (#836499)
    I hope we see lots of great new additions to Fortran as a result of this :)
  • Fortran 77 is a lousy language. Fortran 9x, on the other hand, is quite decent for numerical computations.

    C doesn't have efficient array bounds checking, multidimensional arrays, parallel array operations, or a host of other features useful for numerical computations. The workarounds people use in C are inefficient and/or cumbersome.

  • When I was working there, Sybase tried to "open-source" the protocol specification for TDS (the protocol for Sybase SQL on-the-wire). This was hoped to benefit groups like freetds.org.

    They ended up putting it out... but with a license that would have prevented anyone from producing a free workalike. The freetds guys couldn't even look at spec thing without possibly binding themselves to the license, and no longer being able to work on the project.

    I know it says they will have a "open" license.. I hope it actually works out that way. The old Watcom guys are a pretty clever bunch. I think it will be nice for them to have their work available to the general public for free.
  • Too bad it's easier to write unreadable code with Fortran than even with C.
    Like the following? (That's why they have "obfuscated C contests...)
    #include <stdio.h>
    #include <malloc.h
    main(togo,toog)
    int togo;
    char *toog[];
    {char *ogto, tgoo[80];FILE *ogot; int oogt=0, ootg, otog=79,
    ottg=1;if ( togo== ottg) goto gogo; goto goog; ggot:
    if ( fgets( tgoo, otog, ogot)) goto gtgo; goto gott;
    gtot: exit(); ogtg: ++oogt; goto ogoo; togg: if ( ootg > 0)
    goto oggt; goto ggot; ogog: if ( !ogot) goto gogo;
    goto ggto; gtto: printf( "%d goto \'s\n", oogt); goto
    gtot; oggt: if ( !memcmp( ogto, "goto", 4)) goto otgg;
    goto gooo; gogo: exit( ottg); tggo: ootg= strlen(tgoo);
    goto tgog; oogo: --ootg; goto togg; gooo: ++ogto; goto
    oogo; gott: fclose( ogot); goto gtto; otgg: ogto= ogto +3;
    goto ogtg; tgog: ootg-=4;goto togg; gtgo: ogto= tgoo;
    goto tggo; ogoo: ootg-=3;goto gooo; goog: ogot= fopen(
    toog[ ottg], "r"); goto ogog; ggto: ogto= tgoo; goto
    ggot;}

  • That's what #ifdef is for.

    I mean, come on. We can't just remove stuff because people abuse it. The goto statement is bad, remove that. Way too many programmers write code that overflows buffers, remove pointers. Way too many people dividing by zero. Remove the division operator.

  • WATCOM C includes SDKs and libraries from IBM, Microsoft and others. WATCOM's license to distribute these components does not give them the legal right to open source other people's software.
  • Watcoms Cross compiling abilities could add new Uses to FreeDOS. For Embedded developers FreeDOS/Watcom is the perfect combination. The ability to create 16 bit code means you can port applications to run on an 8088, and many older palmtops that use dos are powered by that venerable chip.
  • That way, the egcs (now gcc) team could incorporate some code (mostly optimizations I guess) in gcc.

    I rather doubt any code from Watcom would be immediately portable to gcc's rather different architecture. That will not, however, stop gcc's developers from studying the Watcom source code to extract algorithms that could be applied to gcc.

    I agree that the GPL would be better, but let's not forget that there are applications of open source code that run beyond cut-and-paste.


    --

  • MSDEV pros:

    1. Edit 12Mbyte text files as easily as 12k.
    2. Allows multiple pre-compile, post-build, custom compile, etc, features.
    3. Lots of cool dockable windows.
    4. Menus, toolbars, etc. fully customisable.
    5. Piss-easy MFC dialog boxes.
    6. Will write you a 1000-line program with half a dozen key-presses: boosts productivity!
    7. No paperclip.
    8. Works better than most M$ software.
    9. It's not EMACS.

    MSDEV cons:

    1. Constant pauses as it loads its browse info.
    2. Annoying autocomplete windows you have to press escape to get rid of.
    3. Bizarre regexp syntax: \( is a grouping operator, \* is an asterisk.
    4. Second-rate binary editor.
    5. Occasionally decides to remove all menus, toolbars, etc, from display, leaving only a blank window and you have to re-install.
    6. 'Can't see the wood for the trees' help system.
    7. Not as easy as Borland C++ Builder.
    8. Can't auto-colour VHDL, Fortran, Perl, etc.
    9. Using M$ product inspires feelings of guilt.

    The other argument in its favour: have you ever tried using Visual C++ from the command line? Ugh!

  • I'm starting to notice a new strategy (well, its not THAT new) in the software industry. If you have a product which really isn't bringing any revenue in, just open source it and claim it as PR.

    This isn't a bad thing, its just kind of funny to note. Now on an interesting note, how easy is it for someone to look into the code of the compiler and get helpful ideas and hints to incorporate into their own compiler? What I mean is, will this move help out gcc in any way?

  • This is Dan Nimrod reporting for WJRK news. We are speaking with Shirley Macbeth from Sybase Inc. regarding the recent announcement concerning the Watcom compiler series being released under an Open Source license.

    Ms. Macbeth, why has Sybase decided to do this?

    Well Dan, the last release version of Watcom C++ was in February of 1996. We just really don't have the energy to do another one, and don't see any reason to since we the last money we made off this was when we accidently put "Watcom Linux" on the box and sold 6 copies to roblimo, who though it was a cool new Linux distribution.

    I see. Why have you chosen SciTech Software as the official maintainer of the Watcom complier products?

    As far we can tell, they are the only ones who have ever used them. Of course, it was to compile Vigor.

    Any parting words Ms. Macbeth?

    Could John Gugeheiman please stop calling us for support? For the last time, we don't know what a "long long int" is...

  • sorry, you're wrong. From the c++ standard, page 97:
    If the for-init-statement is a declaration, the scope of the name(s) declared extends to the end of the for-statement.
    [Example:
    int i = 42;
    int a[10];
    for (int i = 0; i 10; i++)
    a[i] = i;
    int j = i; // j = 42
    --end example]
  • If all you need is the Win32 Platform SDK and a working compiler to compile the compiler (as Watcom's answer indicates),
    • You can get the Win32 Platform SDK here [microsoft.com].
    • You can get a Win32 compiler here [wisc.edu].
  • Okay, MSVC's problems could be fixed, it could not be fixed. (Actually, the linux kernel seems to have some not-standard dependencies so you can't totally blame them.) Either way, I meant fastest. The person I was responding to was talking about speed, the quote that I included was talking about speed. I thought I made myself sufficiantly clear.
  • Watcom's inline assembly is better than most. It doesn't allow the level of optimizations that gcc does, but it's much, much easier to use. In addition, it also lets you modify the calling convention of functions, which is extremely useful in device drivers (especially DOS and OS/2), where function calls are register-based. I don't think gcc's inline assembly supports that.
    --
  • It was the great game-developer compiler.

    Indeed it was. Doom and Duke 3D were the two most high-profile games written using Watcom but there were some other good ones as well - Epic Pinball, One Must Fall and Toxic Bunny also spring to mind.

    The game and demo programmer's paradise at x2ftp [x2ftp.oulu.fi] was - and still is - chock full of Watcom goodies. Some of those have been further developed to be successful commercial cross-platform rendering libraries [egerter.com] in their own right.

    But it was Doom that brought Watcom its popular fame - without a doubt. Game programmers and players everywhere were suddenly asking "DOS/4G? What the hell is this?" And when they found out that it was Watcom that could compile extended DOS programs (with none of the 16-bit memory model restrictions), there was a huge surge in games compiled using Watcom. Instead of all sorts of tricks with segments, EMS and/or XMS, you had a flat memory model. I remember drooling at the time because I'd just about had enough of huge pointers...

  • So in other words, to compile the 1.0 Open-Source version, you need the commercial 11.0c version. So everyone run out and buy the 11.0c version for ~$200 so you can compile your free Open-Source version.

    Actually you will find it difficult to buy the 11.0b compiler commercially these days. However for developers who wish to join the Watcom developer team, we do have rights to provide copies of the compiler specifically for Open Source development purposes.

    If we could simply make 11.0c freely available on the web with all required components, we wouldn't have this problem. But remember that Watcom includes the Win32 SDK, MFC and many more components that are licensed and cannot be simply re-distributed on the web for free.
  • It is F77 with extensions. See Sybase Technical Document: "FORTRAN 90 Compliant Extensions" http://www.sybase.com/detail/1,3151,44419,00.html Stephen Howe
  • It's a decent quality compiler, can generate 16-bit code, cross-compiles to other platforms, supports DOS (16-bit and 32-bit), OS/2 (16-bit and 32-bit), Win16, Win32, Novell.
  • Sybase got a lot of respect from me when they open sourced their ASE database software, especially when they expanded the license to include the BSDs in addition to Linux. Now, I'm starting to like them even more.

    Watcom is a great C compiler, that has a great deal of good optimization tricks that other compilers could benefit from. While GCC has been gaining ground rapidly, certainly you can always benefit from looking at someone else's code.

    Watcom is what you use on microsoft when you need something better than ms visual studio products. (note, not a flame, those compilers are good for things, they just arent very optimizing). I've heard of people writing code in the MS suites and then compiling on watcom. Never underestimate the advantages of seeing someone else's ideas, we can always gain something

    hoorah for sybase

  • It was the great game-developer compiler.

    Not only was it a good optimizing compiler, but it had some really handy stuff for integrating with assembly routines.

    For example, you could specify which arguments go in which registers, which registers would be modified by the operation, and where to expect the return result. The inline assembly stuff was also very handy.

    As an added bonus, it came with WASM, so you didn't have to go out and buy TASM.

    ---
    Despite rumors to the contrary, I am not a turnip.

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close