From: Phil Galbiati Newsgroups: comp.os.msdos.djgpp Subject: Re: HELP : Low level LIBC routines Date: Mon, 04 Nov 1996 23:59:14 -0800 Organization: Tektronix Lines: 94 Message-ID: <327EF3D2.411E@Tek.com> References: <55h4gj$a7e AT herald DOT concentric DOT net> <327C8B9C DOT 7285 AT cs DOT com> <55i90u$q2o AT herald DOT concentric DOT net> NNTP-Posting-Host: philipga.cse.tek.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Odo AT cris DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp [the following quotes have been edited for continuity] > "John M. Aldrich" wrote: > > > Ok; you're probably going to get mad at me for this, but... > > DON'T DO IT. :) The only possible reason I could see for > > rewriting the stdio functions would be because you are > > building your own C compiler. If you think there is a > > _bug_ in these functions, or see something you think could > > be improved, you should submit that information to the DJGPP > > development team for review and possible inclusion into the > > next version(s). > > All this file i/o stuff is also complicated by the fact that > > DJGPP runs under DPMI. You'll notice references to > > _go32_info_block.size_of_transfer_buffer and other things. > > These are mechanisms for interfacing with the actual DOS > > calls that retrieve the keyboard input. This is a VERY good reason to LOOK at the libc functions -- they provide example DPMI code for which it is safe to assume that it works correctly. Bryon Quackenbush wrote: > > Actually, your right, Although I'm not sure which yet... but > it's not just the STDIO lib, it's the entire set of ANSI C libs. > The overall purpose of which is to work toward determining just > how much of the DJGPP libraries would need to be > re-written/modified to add support for 16 bit processors, as well > as also get a little bit better understanding of low level code > operation. As far as submitting my ideas for future versions, > the feedback I recieved when I suggested something like is > earlier was that there would be no marketable reason for adding > it to DJGPP. I think you may have under-estimated the size of the sub-32 bit market. If you read comp.arch.embedded or comp.robotics.misc, you will find that the potential market for 8- and 16-bit c compilers is enormous. Just count the number of microcontrollers and microprocessors which you own -- there's one in your TV, one in your VCR, one in your stereo receiver, one in your CD player, one in your tape deck, one in your Nintendo, one in your microwave, one in your DMM, a half dozen at least in your car, and another half dozen or so in your PC. Of the 20 I've listed, no more than two are 32-bit processors -- the bulk of the rest being either 8bit microcontrollers, or custom ASICs with an off-the-shelf 8bit uC masked in. I'm not sure what the leading 16-bit microcontrollers are, but in the 8-bit market it seems to be a toss-up between the 8051 family and the 68HC11. Many (if not most) of the commercially available compilers for these controllers are jam-packed full of bugs, yet they still sell for $1000 US or more PER *PROGRAMMER*, and most of the technical support is marginal at best (there are some noteable exceptions, however). If you were to extend gcc to generate 8051 code, your name would be praised by countless embedded system designers for time eternal. Whether this is feasible is another question. I believe that there was a version of gcc which generated HC11 code, and there may have been a 6805 version as well, but I don't believe that FSF currently supports either of these (but I could be mistaken). Either one of these might be a good starting point. > Since the libraries seem to be split pretty well into low level / > high level routines, I'm thinking that the libs would not have to > be fully re-written, just some of the low level code, as well as > the DPMI stuff. I guess that most people here would say that > would constitute literally a total re-write, but the other > alternative is starting from scratch with nothing. Our project > would like to be able to include a compiler with our OS > (FreeDOS), but we need to compiler if possible, to be able to > function on hardware lower 386's, since that is one of our > project requirments, and why FreeDOS was created in the first > place. If you would be satisfied with a shareware compiler, you might take a look at Pacific C (http://www.hitech.com.au/pacific.html). I don't know whether it will run on a 286, but it might (I don't have anything that old to test it on). I believe that it is free for non-commercial use, but they probably don't distribute the source. Hope this helps --Phil Galbiati ================================================= Any opinions expressed here reflect the ignorance of the author, NOT Tektronix. =================================================