Message-ID: From: Shawn Hargreaves To: djgpp AT delorie DOT com Subject: Re: far pointers again Date: Wed, 6 Oct 1999 16:29:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Reply-To: djgpp AT delorie DOT com 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.