Re: Is Greenspun enough?



On Fri, 09 Dec 2005 00:02:15 -0800, Duane Rettig <duane@xxxxxxxxx>
wrote:

>
>[just a couple of points here ...]
>
>George Neuner <gneuner2/@comcast.net> writes:
>
>> [IMO, the control offered by mmap() et al. is too coarse grained.
>> Windows file mapping API is easier to use and more flexible.
>> Application level control of the process's virtual memory is one of
>> the few areas where Windows really outshines Unix/Linux.]
>
>I agree. Microsoft did this (mostly) right.
>
>What they got wrong was disallowing the PAGE_EXECUTE_WRITECOPY
>option for a CreateFileMapping. When a system has DEP (data execution
>protection) disabled, we can create a copy-on-write mapping for what
>we call a .dxl file (a heap image, essentialy) by using a PAGE_WRITECOPY
>access. But as soon as one turns on DEP for a machine with the hardware
>for it, no data pages can be executed unless some kind of EXECUTE
>permission is given to the page.

Which is why I always liked Intel's two level segment:page protection
scheme. Tying execute permission to segment rather than page allows
discrimination of different types of data.

Protected mode segment handling had performance issues vs. simple
paging, but given the obvious benefits I could never understood why
essentially _no one_ ever used it. Instead of fixing the performance
problems, Intel looked around, saw no one using segments, and made the
situation worse by deprecating their use and removing some of the
support hardware.

Now in IA64 the MMU no longer supports segmentation.


>> I think current systems cache the fix up address map and patch the
>> code on demand, one page at a time on-the-fly as needed.
>
>But of course this all assumes C/C++/ld() style binding of functions
>and calls. In a lisp code situation, it is almost never necessary
>to patch any code, or to relocate it when moving it. Proof of existence
>for this concept is Allegro CL, where the _only_ architecture ever to
>have required code-fixup after relocation was the Cray, which did not
>provide pc-relative branches (every branch was through a general register
>or to a hard address, offset only by the program base address). But on
>all other architectures, which have pc-relative branching, code vectors
>can be completely non-relocation sensitive. The data which would normally
>be relocated (which usually has to go through register/displacement
>addressing anyway) is simply contained in the function object, and since
>the function register is part of the environment as well as the global
>register, there is no problem accessing any data at all with direct
>memory references, and no indirections.

Having the hardware base register obviated the need to patch position
sensitive code. Flat mode IA32 isn't really hostile to position
independent code but it doesn't do any favors either and most
compilers just don't bother, assuming that the OS will handle
relocatation of the based code if necessary.

George
--
for email reply remove "/" from address
.