Mail Archives: djgpp/1999/10/07/09:52:46
Shawn Hargreaves (SHargreaves AT acclaimstudios DOT co DOT uk) wrote:
: 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.
I understand all this, but I thought it was nice if you could access all
memory available. But if gnu cc doesn't support far pointers, and it is,
as was suggested to me, just a flitch in the early intel processors, does
this mean that dos c compilers are about the only ones that implement far
pointers which they invented themselves (i.e. it is not part of the ansi-c
standard)?
: 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).
How exactly do I get the same protection? By paging out all the memory
belonging to other processes? How many platforms (and which) do support
segmented memory models? I understand from your '100% ugly to port' statement
that this aren't many.
: If you absolutely need direct C access to shared memory, you can do
There won't be shared memory. At least not in general.
: 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...
Well, I obviously don't know enough about other platforms and os's. Someone
that can help me?
: 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...
According to the general consensus in this newsgroup, they probably will find
it ugly. But because I don't want to let go of my protection schemes, I'm very
interested in how I could implement protection using the paging mechanisms so
I won't need far pointers at all, like the rest of the world, it seems.
David
- Raw text -