Come to think of it - is the asm stuff 16 Bit only? Can it be 'ported' to 32 Bit? Or are we going 'float-only' in the future? The question is: can we release ourselves from the asm code completely? Florian P.S. Sorry if these are all FAQs or if this has been discussed before, but maybe recent developments shed a new light on this, so I won't dig up the archives for now...
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Florian Kolbe Sent: Monday, March 10, 2003 2:54 AM To: fractdev@mailman.xmission.com Subject: [Fractdev] Compiling for DOS - give up memory models?
I'd rather start a new thread on this. I still have this major problem that I hesitate to change the code as long as: - I can't compile for DOS (16 Bit) - There's no central CVS (see other thread on this)
As for the DOS part, the question is whether we should continue to support the different memory models for DOS. If so, we should try and find a freely available DOS compiler to handle this. If not, then we won't be as much in trouble, and we could look at djgpp/ggc for Windoze as Jonathan suggested.
If someone is interested, here is a list I found on the usenet ('99): (Post was: http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&selm=9g1l3.2 280%24Vb4.1468 5%40tundra.ops.attcanada.net&rnum=6)
Freely available C compilers for DOS:
These are the major downloadable C compilers that I know of for DOS. NOTE that "freely available" does not necessarily mean FREE. Some of the tools require payment for continued use.
Also note, that I do not have extensive experience with these (except for the last one :-)... Some I have used a bit, while others I have barely looked at. My comments are from my observations in those cases where I have used the tools, from feedback from my users, and general comments I have seen posted on the net. None of this should be taken as gospel, and this should not be considered my endorsement of these tools.
Additions/Corrections to this list are welcome.
DJGPP GCC/GPP GNU 32 bit C/C++ compiler - This is the biggest and most complete free DOS C/C++ implementation - Supports ANSI C and C++ - 32 bit only, requires 386+ and DOS extender - Reported to be difficult for use by Novices - Available for a wide variety of development platforms - Very large user community, well liked by experienced users - Lots of add-on's, libraries, tools are available - Source code is freely available (very large/complex) - Lots of/Good documentation, although hard for novice find/sort through - Restricted by GNU "copyleft" - http://www.delorie.com
LCC portable C compiler - Supports ANSI C - Available for a wide variety of development platforms - Well documented via published book, little free docs - Source code is freely available - Not really oriented toward a novice user - "freeware" - copyright but free for personal use - http://www.cs.princeton.edu/software/lcc - http://www.cs.virginia.edu/~lcc-win32
PACIFIC C - Supports ANSI C - 16 bit, runs on 8088+ - Includes nice DOS IDE (like Turbo-C) + command line tools - Well documented via large PDF file (350+ pages) - Commercial versions available for several embedded processors - "freeware" - copyright but free for general use - http://www.hitech.com.au
PCC Personal C Compiler - Supports K&R C only - 16 bit, runs on 8088+ - Command line interface only - Does not appear to be under current developemt / support - Well documented (approx 100 page text file) - Shareware - payment required for continued use - I don't have an "official" URL, but you can download PCC*.ZIP from many sites. (try SIMTEL - oak.oakland.edu)
MIRACLE C - Supports K&R C with minor ANSI extensions - 16 bit, compiled code runs under DOS - Compiler/IDE requires windows, 386+ - Somewhat documented (approx 30 pages + windows help file) - Compiler source code is available with registration - Shareware - payment required for continued use - http://www.ncf.ca/~bg283
CC386 - I don't know a whole lot about this one, it appears to be a PC adaptation of Matt Brandts CC68k compiler with improvements - Supports K&R C - 32 bit, requires 386+ - Source code is freely available - "freeware", possibly public domain? - http://www.tripod.com/~ladsoft
SMALL-C - Minimal K&R C subset, not very suitable for serious work - 16 bit, runs on 8088+, generates fairly poor code - Well documented via published book, little free docs - Versions for 8080(CP/M), 8086(DOS), and a few other processors - Source code is freely available, fairly simple and easy to modify - Exact status varies, original sources by Ron Cain contain no copyright notices, and are accompanied by a statement that it is "free to anyone wishing to use it". Later versions by J.Hendrix contain copyright notices and shareware registration forms - No official URL, but available on many sites (try SIMTEL - oak.oakland.edu) - may be something on www.drdobbs.com as Small-C was first published there.
MICRO-C - I am the author, so I am obviously somewhat biased on this one - Subset ANSI with extensions (large subset) - Includes a DOS IDE + command line tools - Well documented (approx 400 pages text files) - Comprehensive PC library (~300 functions), including TSR, Windowing Serial Comms, Graphics -lots more. Library source with registration - Generates tiny executables ("Hello World" = ~500bytes) - Large collection of example programs with registration (over 100) - Commercial versions available for many embedded processors - "freeware" - optional registration (not required for continued use) - www.dunfield.com
-----Original Message----- From: fractdev-admin@mailman.xmission.com [mailto:fractdev-admin@mailman.xmission.com]On Behalf Of Jonathan Osuch Sent: Monday, March 10, 2003 2:27 AM To: fractdev@mailman.xmission.com Subject: Re: [Fractdev] Idea 'libfractint'
On Saturday 08 March 2003 05:39 am, Florian Kolbe wrote:
The only major change was to remove XFRACT in favor of DOS. It's much easier to keep the DOS specific parts in #ifdef DOS-Brackets, than #ifndef XFRACT, because XFRACT does not necessarily mean all the other derivatives. I introcuded _HAVE_ALLEGRO, _HAVE_X11 and such in order optionally compile the different drivers.
The original reason for adding the Allegro code to Rich's experimental code was to make it easier to port back to DOS/WIN since Allegro has a port to that environment. I ran into the same need to use a DOS define.
I'm currently looking into using autoconfig/automake so that we will be able to run a configure script prior to compiling. It is probably worth the effort to get this well on its way before doing extensive work porting to other environments.
I now downloaded Turbo C 2.01 from http://community.borland.com/museum/, so I can try to compile the DOS part (though not yet moved to d_dos.c). Can this compiler handle it? I don't know where to get another one (though I am even willing to buy one, just someone let me know which one I should get).
Actually, I would recommend gcc (or is it called djgpp?). It should be possible to use essentially the same utilities under the various environments we are interested in.
One of the reasons I chose nasm for porting the assembly language was that it is available for DOS/WIN. The initial port is painful because the syntax is different from the Intel syntax (oper src,dst instead of oper dst,src).
Jonathan
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev
_______________________________________________ Fractdev mailing list Fractdev@mailman.xmission.com http://mailman.xmission.com/cgi-bin/mailman/listinfo/fractdev