Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <5.1.0.14.2.20010531132733.03877550@ks.teknowledge.com>
X-Sender: rrschulz AT pop3 DOT cris DOT com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 May 2001 14:08:21 -0700
To: cygwin AT cygwin DOT com
From: Randall R Schulz <rrschulz AT cris DOT com>
Subject: Re: Addressing Layout in 1.3.x
In-Reply-To: <20010531150106.O23914@redhat.com>
References: <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010531090143 DOT 0263bf78 AT ks DOT teknowledge DOT com>
 <5 DOT 1 DOT 0 DOT 14 DOT 2 DOT 20010531090143 DOT 0263bf78 AT ks DOT teknowledge DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Chris,

Let me try asking it this way...

Preliminaries:

According to "Inside Microsoft(tm) Windows(r) 2000 3rd ed." when Windows 
2000 is operating in the 2GB max mode (there's a boot-time 3GB option that 
alters these values), user mode application code, globals, per-thread 
stacks and DLLs load at virtual addresses from 0x00000000 to 0x7fffffff. 
The kernel and executive, the hardware abstraction layer (HAL) and the boot 
drivers use virtual addresses from 0x80000000 to 0xC0000000; process page 
tables go from 0xC0000000 to 0xC0800000 and the system cache and the paged 
and nonpaged pools extend the rest of the way, to 0xffffffff.

A corollary of the kind of "bit-convenient" (and at least partially VM 
hardware-dictated) virtual address allocation used by Windows (and lots of 
other operating systems) is that if I know I'm manipulating, say, pointers 
to process page table entries, than I can use the two most significant bits 
of those pointers for my own purposes as long as I set them both to 1 
before dereferencing them to actually access the page table entry. 
(Ignoring any access restrictions that may be placed on those virtual 
addresses, of course).

An interpreter like XSB uses tag bits to make the values it manipulates 
self-identifying as to their data types. Because some of the data types it 
manipulates in this way are actually machine-level pointers, it has to 
restore the proper, fixed values for those bits before dereferencing the 
resulting / equivalent pointer.


Now, my question(s):

a) Does Cygwin impose additional structure to address allocation within the 
application / global / thread stack / DLL area, and if so b) might those 
assignments / alignments have changed in the 1.1.x -> 1.3.x transition?


Does that clarify my question?

Randall Schulz
Mountain View, CA USA


At 12:01 2001-05-31, you wrote:
>On Thu, May 31, 2001 at 09:22:56AM -0700, Randall R Schulz wrote:
> >Hi,
> >
> >[ This question can presumably only be answered by people who know the
> >internals of the code that goes into cygwin1.dll, and I hope I'm not out of
> >line for asking here rather than trying to figure it out from the source,
> >both current and historic... ]
> >
> >
> >One of the applications ported to Cygwin is the XSB Prolog interpreter
> >(<http://xsb.sf.net/> / <http://sf.net/projects/xsb/>). The interpreter
> >uses a "tagged" scheme (like the old generation of lisp machines had in
> >hardware) to make instances of its interpreter's data types
> >self-identifying. Since there are no real tag bits available in today's
> >general-purpose processors, the XSB implementation puts its tags in
> >carefully chosen bits from ordinary words (32 bit iintegers on an x86 
> machine).
> >
> >"Carefully chosen" means bits whose values are dictated and fixed by the
> >addressing layout of the processor and operating system (and / or any
> >execution environment layered over the OS) on which XSB runs.
> >
> >In practice, this means bits whose value does not change regardless of how,
> >when or where the application loads into VM and regardless of how much
> >memory the application allocates during execution. Hence those bits can be
> >replaced with the interpreter's tag bits until it becomes necessary to
> >dereference that value (when the tag indicates the value is a pointer of
> >some sort). At that point, the known correct values of the usurped bits are
> >replaced with their proper values and the the deference occurs.
> >
> >Naturally, that means that the XSB implementation is sensitive to changes
> >in the addressing assignments of the environment that's hosting it. For XSB
> >running under Cygwin, this presumably (potentially, for all I know)
> >includes both Windows and Cygwin.
> >
> >
> >So, after that lengthy introduction, my question is: Did the addressing
> >layout change in Cygwin 1.3.x vis. a vis. 1.1.x?
> >
> >
> >Thanks for reading all the preliminaries to get to the question.
>
>I read the whole thing but I still have no idea what you mean bu
>addressing layout, so I don't really know how to answer this.  Certainly,
>things change all of the time.  There are new globals added, the size
>of the DLL changes, the location of globals within the DLL changes.
>There is no way to avoid this.
>
>cgf
>
>--
>Want to unsubscribe from this list?
>Check out: http://cygwin.com/ml/#unsubscribe-simple


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple