Mail Archives: djgpp/1999/10/06/16:43:43
dfokkema AT cs DOT vu DOT nl writes:
> IMHO, everything that is possible on a platform, should be somehow
> possible in C.
That doesn't make any sense to me: C is a high level language, and
as such it is necessarily at least one step above the hardware you
are running it on, and so unable to use very last feature of that
hardware. For example you can't access the Intel IO ports directly
from C: you have to use library functions or inline asm when you
want to write to a hardware port. You can't set or clear the
interrupt flag, either. There are many useful Intel instructions
(rep; movs for block copying data, cyclically rotating a bit pattern,
testing the parity of an integer, doing binary coded decimal
arithmetic) that have no direct parallel in C, so you have to either
do the same thing in a more long winded way using the options that
C does provide, or call a library function that implements these
operations directly in asm.
> Why wouldn't you support it just because you think a flat memory
> model is better?
I wouldn't support it because I think there are other, better ways to
do things (quite apart from anything else, code that was written for
a segmented memory model is 100% ugly to port to any other hardware,
wheras if you are writing an OS, you can get all the same protection
benefits from paging systems which work a similar way on all hardware).
I would guess that the gcc developers have similar reasons for not
implementing it, although obviously I can't speak for them.
> My os is supposed to use a segmented memory model. Every process has
> its own ldt with a code segment, a data segment and a video buffer
> and probably more. Interfacing with the os is done by passing messages
> to drivers etc. which are processes on their own. No process can
> possibly reach data that doesn't belong to it. That is the story.
If one process can load and use the LDT for another, you already don't
have true memory security, since they could abuse that to write over
someone else's data. And the more your code uses farptr operations,
the more chance that a stray pointer will actually wipe something it
wasn't supposed to.
If you absolutely need direct C access to shared memory, you can do
that with the fat DS hack (easy but no memory protection), or you could
do 'proper' shared memory by remapping the appropriate pages into
a local space. Or use inline asm functions to do the farptr stuff:
this really doesn't seem like such a crucial thing to need direct
compiler support, since interfacing between multiple process address
spaces is a very specific situation where you will want tight control
over the transfers in any case. For instance the Linux kernel seems
to handle the user to kernel space conversions very elegantly just with
simple copy_to_user() and copy_from_user() functions.
If you look at how other OS's work, and how other hardware than Intel
organises things, the general consensus seems to be that segmented
memory is a fairly useless way to manage an address space, and the page
tables are a much more common way to do things...
> So what is this gcc group that maybe should be told about considering
> far pointers?
See "info gcc contributing" for contact information. But (wild guess
coming up), I would be amazed if any of the gcc people are interested
in farptr support. At best they will probably tell you to implement
it yourself if you want it, but most likely they will feel that it
is ugly, not needed for most work, and is too specific to one type of
processor, so they wouldn't want to clutter up the compiler with
such things. But, by all means ask them and see...
Shawn Hargreaves.
- Raw text -