Why did ID choose DJGPP for Quake?
Kalum Somaratna aka Grendel
Could anyone please tell me the reason's why ID, who earlier used
Watcom/DOS4GW for DOOM etc switched to DJGPP. I know that
DJGPP is better than Watcom but were there any other reason's
(like financial - no royalties etc, better DPMI support etc) for
making there choice. I ask this because there was an earlier thread
which said that nearptr was added at ID's request.
The reason I'm asking this question is that I first got to know about
DJGPP after playing Quake. I thought that the compiler used for
the game must be quite good for ID to make the switch and ditch
DOS4GW, had a peek at the EXE to find the compiler name and I
downloaded it, got rid of that monstrosity Borland 4.5 and I have
used DJGPP ever since.
Thanks in advance,
Kalum
RushFan357
good compiler to port the source to DOS. Since DJGPP is a DOS port of a UNIX
compiler it was what id used.
Eli Zaretskii
On Sun, 26 Dec 1999, Kalum Somaratna aka Grendel wrote:
> Could anyone please tell me the reason's why ID, who earlier used
> Watcom/DOS4GW for DOOM etc switched to DJGPP. I know that
> DJGPP is better than Watcom but were there any other reason's
> (like financial - no royalties etc, better DPMI support etc) for
> making there choice.
All of the above.
id Software initially wanted to make Quake extensible with C code, and
DJGPP was the only free protected-mode compiler (they eventually
switched to a scripting language, so this reason is not obvious
today). And the DJGPP support simply blew Watcom out of the water,
even in those days, when Watcom was still in active development.
If you want more details, search the DJGPP mail archives for related
items. This issue comes up from time to time, and people who have
first-hand knowledge (I'm not one of them) sometimes reply.
Prashant TR
> Could anyone please tell me the reason's why ID, who earlier used
> Watcom/DOS4GW for DOOM etc switched to DJGPP. I know that
> DJGPP is better than Watcom but were there any other reason's
> (like financial - no royalties etc, better DPMI support etc) for
> which said that nearptr was added at ID's request.
This is a bit off topic, but here's what I think could be the reason
(for the real reason, you'll have to ask id Software ;-)). DOS4GW
requires more real memory to run. I requires anywhere from 128K to 256K
which is quite bad. And DJGPP programs require just around 64K of memory
(that includes the DPMI). DJGPP programs run very reliably on the
WINDPMI as well and it can take as less as 2K (if you stubedit) of real
memory to run!! Naturally, DJGPP *is* better.
Secondly, there are some bugs in DOS4G. Eg: If you have a 16-bit program
like TC++ 3.0 and you shell out and try running DOS4G, it runs!, but
finally crashes the system. So, maybe these were _possibly_ some of the
reasons.
Prashant
---------------------------------------------------
One pound of learning requires ten pounds of common
sense to apply it.
salvador
> Greetings for the season to all,
>
> Could anyone please tell me the reason's why ID, who earlier used
> Watcom/DOS4GW for DOOM etc switched to DJGPP. I know that
> DJGPP is better than Watcom but were there any other reason's
> (like financial - no royalties etc, better DPMI support etc) for
> making there choice. I ask this because there was an earlier thread
> which said that nearptr was added at ID's request.
I'm not sure, but I heard they wanted to allow people to create plug-ins using a
compiler. For this reason they needed to ship the compiler in the CD, so only a
free tool applied for it. But then they changed your mind and created QuakeC.
Of course djgpp is better. One big plus is portability (gcc is available for
most UNIXes, Watcom don't).
> The reason I'm asking this question is that I first got to know about
> DJGPP after playing Quake. I thought that the compiler used for
> the game must be quite good for ID to make the switch and ditch
> DOS4GW, had a peek at the EXE to find the compiler name and I
> downloaded it, got rid of that monstrosity Borland 4.5 and I have
> used DJGPP ever since.
GCC is currently generating better code than Watcom, but gcc 2.7.x (used in the
Quake years) was comparable with Watcom (very small differences). Watcom is much
better than Borland compilers.
So the reason wasn't just the generated code. Additionally: All the important
code in Quake is pure assembler, the rest isn't even well optimized.
One important thing of djgpp is the availability of sources, so you can fix the
C library is it have a bug, I don't know if Watcom released the code of your
libraries (Borland did it, not for free, but was available).
SET
--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-...@usa.net s...@computer.org
s...@ieee.org set-...@bigfoot.com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013
Jens Luedicke
Different theory:
Commercial compilers require a special licence, which allows the
software firms to sell their software legally. If they choose a
GNU Compiler they don't need special licening.
Jens Luedicke <je...@irs-net.com> // YAPW32H
======================================================================
>> Remove NO-SPAM to reply!
>> PGP-Keys: pgp-...@irs-net.com
======================================================================
perl -e unlink("microsoft")
Andrew Jones
(platform), and then brought it over. Although it was probably also so
people could write plug-ins for it.
But don't let these folks fool you. IMNSHO, Watcom (still) produces better
code than GCC. DJGPP seems very convoluted to me (typical of programs which
originate on UNIX), where Watcom is very clean and easy. Although DJGPP
does have much better support in every area you could imagine, and if you
don't like something, you've got the sources to change it.
Someone also said something about a commercial licence being needed. With
DOS4G/W you've got an unlimited run-time licence, so you don't have to pay
any more than you did for the compiler.
Andrew Jones
Kalum Somaratna aka Grendel <ka...@newmail.net> wrote in message
news:94622...@out.newmail.net...
> Greetings for the season to all,
>
> Could anyone please tell me the reason's why ID, who earlier used
> Watcom/DOS4GW for DOOM etc switched to DJGPP. I know that
> DJGPP is better than Watcom but were there any other reason's
> (like financial - no royalties etc, better DPMI support etc) for
> making there choice. I ask this because there was an earlier thread
> which said that nearptr was added at ID's request.
>
> The reason I'm asking this question is that I first got to know about
> DJGPP after playing Quake. I thought that the compiler used for
> the game must be quite good for ID to make the switch and ditch
> DOS4GW, had a peek at the EXE to find the compiler name and I
> downloaded it, got rid of that monstrosity Borland 4.5 and I have
> used DJGPP ever since.
>
> Thanks in advance,
> Kalum
Kalum Somaratna aka Grendel
>
> Commercial compilers require a special licence, which allows the
> software firms to sell their software legally. If they choose a
> GNU Compiler they don't need special licening.
>
And IMHO they won't have to pay any royalties which taken a
game like Quake would add up to a sizable amount saved and
would help to swell the already bloated moneybags at ID software.
Vinzent Hoefler
>Commercial compilers require a special licence, which allows the
>software firms to sell their software legally.
Sorry, but that's nonsense.
You can sell everything that is compiled with a legal copy of a
commercial compiler. That's implied in the license.
(Borland has never received and will never receive any money from me
except for my own copy of TASM and I surely won't get into jail by
selling programs assembled with this. ;-)
>If they choose a
>GNU Compiler they don't need special licening.
At least the compiler should be released under the _L_GPL.
For me the "real" GPL looks more strict than the license of a
commercial compiler: It requires you to release the source with your
programs.
Vinzent.
--
While most peoples' opinions change, the conviction of their
correctness never does.
salvador
> If I'm not mistaken, it's because they developed it on a different box
> (platform), and then brought it over. Although it was probably also so
> people could write plug-ins for it.
>
> But don't let these folks fool you. IMNSHO, Watcom (still) produces better
> code than GCC.
Take a look at http://www.geocities.com/set-soft/compila.html
You'll get a big surprise.
Damian Yerrick
> Jens Luedicke <je...@irs-net.com> wrote:
>
> >Commercial compilers require a special licence, which allows the
> >software firms to sell their software legally.
>
> Sorry, but that's nonsense.
>
> You can sell everything that is compiled with a legal copy of a
> commercial compiler. That's implied in the license.
I got a legal copy of CodeWarrior from Metrowerks, and its EULA
said don't develop commercial software with this. You may develop
free[beer]ware or shareware, but no payware. That's the difference
between CodeWarrior Discovery and CodeWarrior Pro.
> >If they choose a
> >GNU Compiler they don't need special licening.
>
> At least the compiler should be released under the _L_GPL.
The libs (libc, the [in]famous -lstdcx[x], etc.) _are_ LGPL'd.
A GPL'd compiler simply means that you have to distribute
or link to source code *if you distribute the compiler*.
> For me the "real" GPL looks more strict than the license of a
> commercial compiler: It requires you to release the source
> with your programs.
Which is why some of us hate Cygwin.
--
Damian Yerrick http://yerricde.tripod.com/
View full .sig: http://www.rose-hulman.edu/~yerricde/sig.html
and now you must pay...
Vinzent Hoefler
>> Sorry, but that's nonsense.
>>
>> You can sell everything that is compiled with a legal copy of a
>> commercial compiler. That's implied in the license.
>
>I got a legal copy of CodeWarrior from Metrowerks, and its EULA
>said don't develop commercial software with this.
So they say:
Don't.
Not:
You have to pay us for every copy you sell.
Or:
You need a special license to compile your programs.
>You may develop
>free[beer]ware or shareware, but no payware. That's the difference
>between CodeWarrior Discovery and CodeWarrior Pro.
"Discovery". Mmh, yes. Sounds like "Student's Edition", "Introductory
Edition", "Learning Edition" or watchamacallit.
That's a different thing and _those_ are special licenses.
I meant a full commercial license.
And that's not a _special_, that's the _usual_ license (for a
commercial compiler).
Mmh, the usual way is just a little bit more expensive, like $499 or
so and not $49 with a book 'Learn COBOL in 21 Days'. :-)
>> >If they choose a
>> >GNU Compiler they don't need special licening.
>>
>> At least the compiler should be released under the _L_GPL.
>
>The libs (libc, the [in]famous -lstdcx[x], etc.) _are_ LGPL'd.
>A GPL'd compiler simply means that you have to distribute
>or link to source code *if you distribute the compiler*.
Mmh, ok. I once heard, everything compiled with GCC can only be
distributed under the GPL. It's a long time ago (before Quake ;-) and
it seems to be wrong.
>> For me the "real" GPL looks more strict than the license of a
>> commercial compiler: It requires you to release the source
>> with your programs.
>
>Which is why some of us hate Cygwin.
No problem for me. No Windoze - No Cygwin. ;-)
[...]
>and now you must pay...
What for? DJGPP? NASM? OpenDOS? No Way! :-)
Vinzent.
--
Real programmers don't comment their code. It was hard to write, it
should be hard to understand.
leon
> >> For me the "real" GPL looks more strict than the license of a
> >> commercial compiler: It requires you to release the source
> >> with your programs.
> >
> >Which is why some of us hate Cygwin.
>
am sorry - i am rather new to this "thread" - but the general question
from me would be:
if you use GNU (ie gcc compiler) - for example like djgpp or mingw32 -
then do you have to make source code available - or is there any monetary
issues - ie paying for use?
If so - how does that stack up against _not_ compiling the final product
with those compilers but still _developing_ code (eg debugging, and even
earlier stage - coding of you project). Then what if one simply says - ok
now my product is working - what if one then goes and buys commercial
version and compiles the final product that was developed with other
tools - would one still have to pay to djgpp/mingw32/cygwin (for using
those in development stage)?
Jens Luedicke
>>Commercial compilers require a special licence, which allows the
>>software firms to sell their software legally.
> Sorry, but that's nonsense.
Ok ;-)
> For me the "real" GPL looks more strict than the license of a
> commercial compiler: It requires you to release the source with your
> programs.
This is real freedom. Even if Microsoft would release their programs
with source, this wouldn't be the end for Microsoft. I think that the
majority of the Microsoft-Users have no idea about programming and
how to work with the sources.
Eli Zaretskii
On Thu, 30 Dec 1999, leon wrote:
> if you use GNU (ie gcc compiler) - for example like djgpp or mingw32 -
> then do you have to make source code available - or is there any monetary
> issues - ie paying for use?
NO and NO! See section 19.1 of the DJGPP FAQ for the details.
That section exists so that you won't need to be bothered by
confusion usually associated with these issued, and with GPL in
general.
Vinzent Hoefler
>This is real freedom. Even if Microsoft would release their programs
>with source, this wouldn't be the end for Microsoft.
Are you sure? Some people never ate something again after they have
seen how it was made.
Something like this could apply to Windoze, too. ;-)
>I think that the
>majority of the Microsoft-Users have no idea about programming and
>how to work with the sources.
Fact: "Is it something to eat?"
Vinzent.
--
A new user looking at the M$-Windows-CD that came with
it's new computer system: "Hey, if Win98 is already
on the hard-disk, why is it still on this CD-ROM, too?"
-- Just in case: The question is from real life.
Jens Luedicke
> Are you sure? Some people never ate something again after they have
> seen how it was made.
It could happen that someone looks into the sources. For brave users
they should release the sources only as a 10-hour download.
If the source-code of M$-Software looks the same like the
HTML-code that is produced by FrontPage, I'm sure nobody would ever
use M$-Products again. ;-)))
Damian Yerrick
"Jens Luedicke" <je...@irs-net.com> wrote:
>
> > For me the "real" GPL looks more strict than the license of a
> > commercial compiler: It requires you to release the source with your
> > programs.
> majority of the Microsoft-Users have no idea about programming and
> how to work with the sources.
But there's always that very significant minority who would
be interested in source code, if only to fix all the fscking
instability in Wind0ze. Then there's the Wine crew, who
is working on a free Windows clone for X-based systems,
as opposed to the Cygwin team, who is porting XFree86
to Windows + DirectX.
--
Damian Yerrick http://yerricde.tripod.com/
View full .sig: http://www.rose-hulman.edu/~yerricde/sig.html
Damian Yerrick
>
> If the source-code of M$-Software looks the same like the
> HTML-code that is produced by FrontPage, I'm sure nobody
> would ever use M$-Products again. ;-)))
Used to use FrontPage. Then I discovered Emacs.
Now I get real p155ed when someone updates content,
using a DYSIWYG HTML editor, in a page I designed.
Stephen Howe
to Watcom but I do not know if that is so.
Stephen Howe
Stephen Howe
>>You'll get a big surprise.
I have looked at that. They are using 10.0a, hardly the newest version of
Watcom C/C++. It would be better to do a comparison using 10.6 or 11.0b. I
would be interested to know what switches they used.
Stephen Howe
Stephen Howe
It varies Andrew. It would better to check the types of optimisation each
compiler does.
Stephen Howe
Charles Sandmann
the development:
1) Cross development. They wanted fast stable boxes (Unix) to do development
on with minimal effort to migrate.
2) Possibility to ship the compiler.
3) Source availabiltiy and the libc sources - including DJ's commercial
policy and willingness to provide lightning fast response to questions.
4) Verbal assurances the development team would make DJGPP work for them.
The commercial quake was built with V2.0 beta 3 - not the final release -
using unixy sbrk, prototype near pointers, and some ugly memory management
code to make sure the arena never moved.
Once their code was stable with beta 3 - they released with it and didn't
want to upgrade - it would have required changes to the memory management
code. I remember discussing this with one of their partner developers
adding drivers or porting about 6 months after the release. A minor fix.
Quake did drive some DJGPP development. Near pointers is the most obvious.
Near pointers don't work under NT - which was a huge disappointment to iD
and generated some conference calls to Microsoft. The result of those
calls was that this was a protection feature of NT and was not going to
be fixed. If NT had been a bigger market at the time - I was going to
provide the dynamic fixup runtime linker (the basis of the DXE code) in
the stub to make the base of memory at 0000000 be an option which would
have allowed near pointers to work under NT. This would have delayed
release about a month or so - and so it didn't happen.
Win95 has a huge buggy hack at the time - in beta - and the biggest
grief was getting Quake to run reliably under the W95 DPMI provider.
CWSDPR0 is a Quake development special - they wanted ring 0 access for the
pentium instruction timing opcodes when hand crafting the final assembler
performance.
Kalum Somaratna aka Grendel
>
> It varies Andrew. It would better to check the types of optimisation each
> compiler does.
Actually Stephen, IMHO what appears to be fast code from a
human point of view may fail miserably when it is actually run and
put to the test.
So one way would be to run a small computationally intensive
bechmark program (does anyone have any ideas?) compiled under
WatcomC++ 11(or whatever is the latest version) and DJGPP/GCC
2.952 with full optimizations and see which performs better. And
maybe we can publish the results on this forum for everyone to see.
Whether real/protected mode switches ought to be taken into
account will also have to be considered.
Actually IMHO a test of how fast the mode switching routines are
would really indicate how good a protected mode environment
really is specially for a real mode OS like DOS(the quality of the
compiler also plays a part true enough).
Kalum
Eneko Lacunza
Hello Andrew!
In miļ¼³coles 29 de Diciembre de 1999 at 13:01, Andrew Jones wrote to All:
> But don't let these folks fool you. IMNSHO, Watcom (still) produces
> better code than GCC. DJGPP seems very convoluted to me (typical of
> programs which originate on UNIX), where Watcom is very clean and
> easy. Although DJGPP does have much better support in every area you
> could imagine, and if you don't like something, you've got the sources
> to change it.
I totally disagree. Until a month ago or so, I had GCC 2.7.2 and Watcom
10.6 (yes, you now WC11 is slower). In that situation, GCC was a bit faster
just with 486 optimizations (yes, Watcom was optimizing for pentium). For
example, my Raytracing tunel runs at 40 fps compiled with Watcom, and with
GCC 2.7.2 at 43 fps.
Then I downloaded GCC 2.95 . It has pentium optimizations (and more).
Result: 53 fps. 30% gain over shitty Watcom.
This is a bit of tests, and something more general should be used to
test both compiler's output. But for real-time graphics programming GCC (and
thus DJGPP) is much faster than Watcom currently.
For your info: both compilers are compiling the same .C (even the VESA
library, except for some DPMI functions that are already implemented in
DJGPP and are not used in the main loop) and the test machine was a p166.
Regards,
Eneko Lacunza
Enlar/GENESiS
... Plug'n'Pray fucks, GUS rulez!
en...@hidespam.iname.com
http://www.euskalnet.net/enlar
http://www.biosys.net/genesis_demogroup
salvador
I have an article from BYTE, they compared 10.0a and 11.0 and both delivers the
almost the same performance.
And they used the best switches they could found. In fact BYTE coded the
benchmarks with Watcom in mind as the DOS compiler because they used the
benchmarks to compare computers.
Stephen Howe
salvador wrote in message <387098AB...@inti.gov.ar>...
>> I have looked at that. They are using 10.0a, hardly the newest version of
>> Watcom C/C++. It would be better to do a comparison using 10.6 or 11.0b.
I
>> would be interested to know what switches they used.
>
>I have an article from BYTE, they compared 10.0a and 11.0 and both delivers
the
>almost the same performance.
>And they used the best switches they could found. In fact BYTE coded the
>benchmarks with Watcom in mind as the DOS compiler because they used the
>benchmarks to compare computers.
I would like to see that article. Do you have a URL? The original 11.0 was
quite buggy whereas 11.0b is very stable. I tend to think that code
generation has not significantly improved over these versions except in some
areas specific to C++.
Thanks
Stephen Howe
salvador
> salvador wrote in message <387098AB...@inti.gov.ar>...
>
> >> I have looked at that. They are using 10.0a, hardly the newest version of
> >> Watcom C/C++. It would be better to do a comparison using 10.6 or 11.0b.
> I
> >> would be interested to know what switches they used.
> >
> >I have an article from BYTE, they compared 10.0a and 11.0 and both delivers
> the
> >almost the same performance.
> >And they used the best switches they could found. In fact BYTE coded the
> >benchmarks with Watcom in mind as the DOS compiler because they used the
> >benchmarks to compare computers.
>
> I would like to see that article. Do you have a URL?
Nope, lamentably is on paper.
Stephen Howe
Kalum Somaratna aka Grendel wrote in message
<1999123123...@lakdiva.slt.lk>...
On 31 Dec 99, at 0:01, Stephen Howe wrote:
>>>> It varies Andrew. It would better to check the types of optimisation
each
>>>> compiler does.
>>Actually Stephen, IMHO what appears to be fast code from a
>>human point of view may fail miserably when it is actually run and
>>put to the test.
>>So one way would be to run a small computationally intensive
>>bechmark program (does anyone have any ideas?) compiled under
>>WatcomC++ 11(or whatever is the latest version) and DJGPP/GCC
>>2.952 with full optimizations and see which performs better. And
>>maybe we can publish the results on this forum for everyone to see.
Your right. But I would be looking separately at
(i) integer optimisation
(ii) fp optimisation
(iii) space and time saving optimisations
(iv) loop optimisations
(v) stack lifetime optimisations
(vi) tail optimisations
etc.
You will find that it wins on some tests and does badly on others. I am
aware of it strengths and its weaknesses from having used it for 13 years.
My ideal C & C++ compiler and tools would be a combination from all the PC
compilers that is on the market.
Speaking honestly, there are a number of areas where the compiler &
libraries could be improved. For instance, the 32-bit maths libraries are
built assuming that your executables (32-bit DOS, Win32, OS/2 etc) could be
running on a 386+287 combination which implies fwait opcodes. Well how many
people are running on that combination? Not many, I bet. For everyone
running 486 or better, these can be removed. So that means numerical maths
tests could be faster on Pentiums if the libraries wer built differently.
>>
Whether real/protected mode switches ought to be taken into
account will also have to be considered.
Actually IMHO a test of how fast the mode switching routines are
would really indicate how good a protected mode environment
really is specially for a real mode OS like DOS(the quality of the
compiler also plays a part true enough).
>>
At this point are you talking about 32-bit DOS? If so, would you not mostly
be measuring the DOS extenders performance (Tenberry, Causeway, PMODE/W,
DOS32 etc) rather than the compiled code? That would be tricky to factor
out. DOS4GW 2.01 _is_ faster than DOS4GW 1.97 (this is the version that
comes with Watcom), I have measured it.
Stephen Howe
Eli Zaretskii
On Tue, 4 Jan 2000, Stephen Howe wrote:
> Your right. But I would be looking separately at
>
> (i) integer optimisation
> (ii) fp optimisation
> (iii) space and time saving optimisations
> (iv) loop optimisations
> (v) stack lifetime optimisations
> (vi) tail optimisations
> etc.
AFAIK, this is already done on the page where Salvador pointed you.
> Speaking honestly, there are a number of areas where the compiler &
> libraries could be improved. For instance, the 32-bit maths libraries are
> built assuming that your executables (32-bit DOS, Win32, OS/2 etc) could be
> running on a 386+287 combination which implies fwait opcodes. Well how many
> people are running on that combination? Not many, I bet. For everyone
> running 486 or better, these can be removed.
What library, specifically, are you talking about? The DJGPP library
has only 11 FWAIT instructions in 8 of its math functions; the next
version of the library (to be released very soon) reduces this to 3
FWAIT instructions in 3 functions. I don't see any problem here.
The compiler might emit FWAIT while compiling FP code, but I'd expect
latest versions of GCC to omit them when the command-line switches
tell it to use Pentium as the target.
So it seems that this is a non-issue.
> Actually IMHO a test of how fast the mode switching routines are
> would really indicate how good a protected mode environment
> really is specially for a real mode OS like DOS(the quality of the
> compiler also plays a part true enough).
> >>
>
> At this point are you talking about 32-bit DOS? If so, would you not mostly
> be measuring the DOS extenders performance
Not quite true. Calling real-mode services has different overheads,
depending what environments and waht methods are used to call
real-mode code from a protected-mode program. Part of this overhead
is in the library (copying data to conventional memory, preparing the
real-mode call structures, etc.).
Kalum Somaratna aka Grendel
>
> Kalum Somaratna aka Grendel wrote in message
<snip>.
>
> >>So one way would be to run a small computationally intensive
> >>bechmark program (does anyone have any ideas?) compiled under
> >>WatcomC++ 11(or whatever is the latest version) and DJGPP/GCC
> >>2.952 with full optimizations and see which performs better. And
> >>maybe we can publish the results on this forum for everyone to see.
>
> Your right. But I would be looking separately at
>
> (i) integer optimisation
> (ii) fp optimisation
> (iii) space and time saving optimisations
> (iv) loop optimisations
> (v) stack lifetime optimisations
> (vi) tail optimisations
> etc.
>
> You will find that it wins on some tests and does badly on others. I
> am aware of it strengths and its weaknesses from having used it for 13
> years. My ideal C & C++ compiler and tools would be a combination from
> all the PC compilers that is on the market.
I indeed wish that there was such a compiler, Sigh.
I too like Watcom (it was my first compiler for developing 32bit
extended dos apps) and IMHO the code produced by Watcom
version 10.x was better than GCC 2.81.
However I haven't checked about the 2.952 versions of GCC and
there optimisations.
If you have or know of any testing/benchmark program please
consider posting it. I'm sure many of the members of this group
would be interested in the results from compiling the programs with
full optimisations with watcom and djgpp.
>
> Speaking honestly, there are a number of areas where the compiler &
> libraries could be improved. For instance, the 32-bit maths libraries
> are built assuming that your executables (32-bit DOS, Win32, OS/2 etc)
> could be running on a 386+287 combination which implies fwait opcodes.
> Well how many people are running on that combination? Not many, I bet.
I might be wrong but I don't think there would be any on this
newsgroup using a 386+287 for serious work in 2000. My 386 is
been put to good use as a doorstopper ;-)
> For everyone running 486 or better, these can be removed. So that
> means numerical maths tests could be faster on Pentiums if the
> libraries wer built differently.
It is indeed suprising how much software (which cannot practically
be run on a 386) for example that trash windoze, are compiled
using only 386 specific instructions. IMHO they really shoud ditch
386 and consider optimizing for at least the 486 and using 486
specific intructions (the ideal would be pentium specific
instructions). The good thing about free software like linux is that
you can recompile the kernel for whatever processor you want.
> At this point are you talking about 32-bit DOS? If so, would you not
> mostly be measuring the DOS extenders performance (Tenberry, Causeway,
> PMODE/W, DOS32 etc) rather than the compiled code? That would be
> tricky to factor out. DOS4GW 2.01 _is_ faster than DOS4GW 1.97 (this
> is the version that comes with Watcom), I have measured it.
Could you please tell me where you got DOS4GW 2.01. I myself
have been on the look out for a newer version than 1.97.
Take Care,
Kalum
Eli Zaretskii
On Wed, 5 Jan 2000, Kalum Somaratna aka Grendel wrote:
> I too like Watcom (it was my first compiler for developing 32bit
> extended dos apps) and IMHO the code produced by Watcom
> version 10.x was better than GCC 2.81.
AFAIK, Watcom 10.x was roughly identical to GCC 2.8.1.
> However I haven't checked about the 2.952 versions of GCC and
> there optimisations.
GCC 2.9x produces faster code than Watcom does. It's all on SET's
compiler comparison page, just read there.
> I might be wrong but I don't think there would be any on this
> newsgroup using a 386+287 for serious work in 2000.
You would be wrong. Search this news group's archives, and you will
see.
> It is indeed suprising how much software (which cannot practically
> be run on a 386) for example that trash windoze, are compiled
> using only 386 specific instructions. IMHO they really shoud ditch
> 386 and consider optimizing for at least the 486 and using 486
> specific intructions (the ideal would be pentium specific
> instructions).
You aren't talking about DJGPP, are you? Because DJGPP library and
utilities are compiled with -m486 switch. The only reason we don't
compile with -mpentium is because we still didn't switch to GCC 2.9x
for building the library, and versions of GCC before 2.9x didn't
support Pentium-specific optimizations.
Damian Yerrick
> On Wed, 5 Jan 2000, Kalum Somaratna aka Grendel wrote:
> > I might be wrong but I don't think there would be any on this
> > newsgroup using a 386+287 for serious work in 2000.
386 PCs? No. Their BIOSes probably have the century bug.
> You would be wrong.
Especially in embedded systems.
> The only reason we don't compile with -mpentium is because
> we still didn't switch to GCC 2.9x for building the library, and
> versions of GCC before 2.9x didn't support Pentium-specific
> optimizations.
Then I guess I'll have to recompile everything from sources myself
once the next DJGPP version is released, as one of my systems is
486SX-based.
Stephen Howe
Eli Zaretskii wrote in message ...
>
>What library, specifically, are you talking about? The DJGPP library
>has only 11 FWAIT instructions in 8 of its math functions; the next
>version of the library (to be released very soon) reduces this to 3
>FWAIT instructions in 3 functions. I don't see any problem here.
Watcom's, sorry I should have made that clear.
>Not quite true. Calling real-mode services has different overheads,
>depending what environments and waht methods are used to call
>real-mode code from a protected-mode program. Part of this overhead
>is in the library (copying data to conventional memory, preparing the
>real-mode call structures, etc.).
Ok, you are talking about the setup of parameters for a call of DPMI
301h/302h etc. Hrrrmmm, hardly seems much of a test as I would expect the
majority of the time would be in the real mode function or interrupt. Or is
this a measure of the efficiency of setting up parameters before a DPMI
call?
Still, that can be done.
Stephen Howe
Stephen Howe
Kalum Somaratna aka Grendel wrote in message
<94711...@out.newmail.net>...
>>>
If you have or know of any testing/benchmark program please
consider posting it. I'm sure many of the members of this group
would be interested in the results from compiling the programs with
full optimisations with watcom and djgpp.
>>>
I will come back to this later.
>>Could you please tell me where you got DOS4GW 2.01. I myself
>>have been on the look out for a newer version than 1.97.
From Tenberry. See
http://www.tenberry.com/dos4g/watcom/index.htm
and release notes
http://www.tenberry.com/dos4g/watcom/rn4gw.htm
2.01 fixes some _very_ obscure bugs in 1.97. It is slightly faster on some
benchmarked tests. You can also get a manual (I have) which I find answers
some questions on what DOS4GW does and raises questions on others. It is
useful but I have reservations.
I do not rate DOS4GW anymore because I think Tenberry have given up
development of it. I would go for Causeway. Part of the reason for this is
that I filed two simple bugs on DOS4GW 1.97 (and 2.01) at the beginning of
1999 with Tenberry and it is now 11 months later. The two bugs were
(i) If you have a PATH that is longer than 256 characters, DOS4GW will fail
to load giving some type of load error message. Your application never gets
started. People who applied SP4 to NT4.0 picked this up.
(ii) If you have an enviroment where you have more than approx 3.5K of env
variables, DOS4GW fails to load giving out a message like
"R6009: Enviroment too big" which is a Microsoft error message.
(iii) I also raised a third bug with Tenberry where in a pure DOS
environment (not Windows nor any other DPMI server running) with DOS4GW is
its own DPMI host, the timer interrupt int 8H (IRQ 0) should be reflected
first in protected mode according to the DPMI 0.9 standard. I proved it is
not.
From the fact that Tenberry have not fixed these for 11 months, I rate
Causeway because I know that Micheal Devore is _very_ responsive to his
customers.
Hope this helps
Stephen Howe
Kalum Somaratna aka Grendel
>
> "Eli Zaretskii" <el...@is.elta.co.il> wrote:
<snip>
>
> > The only reason we don't compile with -mpentium is because
> > we still didn't switch to GCC 2.9x for building the library, and
> > versions of GCC before 2.9x didn't support Pentium-specific
> > optimizations.
>
> Then I guess I'll have to recompile everything from sources myself
> once the next DJGPP version is released, as one of my systems is
> 486SX-based.
>
I think Eli meant that DJGPP would be compiled using the -m586
switch wich would not generate pentium specific code. It would be
still generating 386 instructions specially timed for the pentium (the
-march=i586 would generate pentium specific insns). So AFAIK the
code generated with the -m586 switch should run without
generating invalid opcodes on your 486 but it might be a bit slower
than compiling with the -m486 option.
But the starange thing is that on my old 486DX2 I found that code
compiled with pentium speciific optitmisations -m586 is actually
faster than code from the m486 switch.
Regards,
Grendel
Eli Zaretskii
On Thu, 6 Jan 2000, Stephen Howe wrote:
> >Not quite true. Calling real-mode services has different overheads,
> >depending what environments and waht methods are used to call
> >real-mode code from a protected-mode program. Part of this overhead
> >is in the library (copying data to conventional memory, preparing the
> >real-mode call structures, etc.).
>
> Ok, you are talking about the setup of parameters for a call of DPMI
> 301h/302h etc. Hrrrmmm, hardly seems much of a test as I would expect the
> majority of the time would be in the real mode function or interrupt.
If the majority of the time would be in the real-mode function, we
wouldn't be talking about the overhead of the mode switch, would we?
In reality, there *is* some overhead involved (the DJGPP FAQ spends
some time discussing the related issues in section 14.4). How
significant it is, depends not only on the quality of the library
code, but also on the run-time environment parameters, such as what
ring does the program and/or the DPMI host run, etc.
Eli Zaretskii
On Thu, 6 Jan 2000, Damian Yerrick wrote:
> > The only reason we don't compile with -mpentium is because
> > we still didn't switch to GCC 2.9x for building the library, and
> > versions of GCC before 2.9x didn't support Pentium-specific
> > optimizations.
>
> Then I guess I'll have to recompile everything from sources myself
> once the next DJGPP version is released, as one of my systems is
> 486SX-based.
I don't think so. First, the next version (v2.03) is still compiled
with -m486. Second, even when we do switch to -mpentium, it should
run on 486SX with no problems, and the slowdown due to Pentium
optimizations should be minimal.
Richard Slobod
"Damian Yerrick" <sn...@pineight.8m.comMUNIST-PIGS-AOL> wrote:
> "Eli Zaretskii" <el...@is.elta.co.il> wrote:
> > > I might be wrong but I don't think there would be any on this
> > > newsgroup using a 386+287 for serious work in 2000.
>
> 386 PCs? No. Their BIOSes probably have the century bug.
Possibly, yes. Probably? Not necesarily. Many older computers have
BIOSes that handle dates past 1999 just fine (_most_ of them in my
experience, but I admit that that's not a large enough sample to be
statistically valid).
Also, note that the age of the machine doesn't really relate to the
chances of it being Y2K compliant. There's only been a real impetus to
make sure that everything's Y2K compliant within the last several years.
Anything older than that, regardless of exact age, has a roughly equal
chance of having Y2K problems, whether it's a 386, 486, or even an older
Pentium. (In fact, the one machine I've run into whose BIOS was
completely incapable of handling a year 2000 date _was_ an older
Pentium. The various other old machines -- just about all of them older
than the Pentium -- at worst failed rollover but were fine once manually
set.)
For that matter, having a Y2K-incompliant BIOS doesn't even remotely
render the system unusable. There are various solutions for getting the
OS' date set correctly even if the BIOS can't provide it properly.
(Mind you, I agree with Kalum Somaratna's above statement; chances are
that no one here is using something as ancient as a 386 for serious work
simply for performance reasons.)
Sent via Deja.com http://www.deja.com/
Before you buy.
Robert S Whitlock
>
> systems.
>
> I have no real example, but I know from my own experience that
> military
> and medical equipment often uses "old" processors because they
> perform
> in a reliable way (since all bugs are known).
>
> Can someone confirm this?
I have a 286 that I use once every couple months, and its clock battery
once wore out and started giving wrong times, so I needed to replace it.
So, I replaced it, and then set the correct time on the computer at
startup. Well, I don't know what was up with the battery, but apparently
it gave out extra voltage or something during the first part of its
lifetime, and it tripped over the year 2000. It worked just fine. But
then again, I don't use it for anything practically except for
command.com and disk copies. But eventually, it settled down and the
clock is now ticking correctly. Strange, eh?
--Robert Whitlock
http://www.geocities.com/CapeCanaveral/Hangar/9520/
ICQ 60123256