Mail Archives: djgpp/1996/11/05/08:36:02
[the following quotes have been edited for continuity]
> "John M. Aldrich" <fighteer AT cs DOT com> 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).<snip>
> > 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.
=================================================
- Raw text -