Problem with arrays

NTDEV
21

Assuming the physical memory is all taken - it may not be - the obvious
thing to do is to keep some physical slots in reserve for general trusted
kernel use: a kernel physical memory pool. Also, if you have to use physical
memory anyway, what’s the difference of having that memory tagged as stack
or as heap ? So, if I overflow my stack, for example, pick a page out of the
heap - that is, the nonpaged pool - and map it in as stack. Or have a
separate kernel pool for requests of that nature. Going one step further, if
arrays are pointers, how about generating a pointer on the stack and
allocating the space on the heap, OO style ? This kind of code could be
generated by the compiler and the functionality could be activated by a
compiler switch.

There are many ways to skin this cat.

Alberto.

-----Original Message-----
From: David J. Craig [mailto:xxxxx@yoshimuni.com]
Sent: Wednesday, May 22, 2002 4:02 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

M$ did a lot of things that cause device driver developers problems. They
also made it difficult for file systems developers. The 12KB stack limit is
not that much of a problem. That is why you have access to all the memory
pools (paged & nonpaged). If you are servicing an interrupt and running at
IRQL > DISPATCH_LEVEL and the code tries to extend the stack beyond the 12KB
allocated, where can the OS get memory to add to the stack? All pages are
currently committed and they might all be dirty requiring the memory manager
to interface with the virtual memory system (or visa-versa). No context
switch can occur and the only thing the OS can do is to blue screen the
system to keep damage to a minimum.

The fact is that stack swapping cannot be done ‘at the right level’ because
you can’t get from some places to the ‘right level’. I don’t mean that you
can’t design an OS to handle this, but it sure isn’t NT. Maybe IBM VM can
do it for the OSes that run beneath it. Also add multiple CPUs to the
equation and it gets more fun. I think a larger stack would be nice, but
the infinite stack available in user land doesn’t seem possible under some
circumstances.

----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Wednesday, May 22, 2002 2:47 PM
Subject: [ntdev] RE: Problem with arrays

> A physical memory allocator can run at the lowest level and not have to
know
> about paging issues. So, we can write a slab allocator, for example, Linux
> did it. In this case, however, it’s probably not even needed because the
> stack doesn’t need to be physically contiguous anyway. If resources aren’t
> available, resources aren’t available, and we do whatever we normally do
> when resources aren’t available. Modifying page tables may require
locking,
> yes, but that’s part of life: shared resources must be protected, and
> synchronization constructs, at least in theory, should belong to the
> resources being synchronized and not to anything else. Moving the contents
> of the stack can be done inside the kernel - we’re assuming that running
out
> of stack is not that frequent an event, so, we may be justified in
spending
> some resources in order to get it right, even if I stop everything on its
> tracks and do a hard systemwide cli before I move the data, I’ll probably
> still be justified even in performance terms.
>
> The assumption under Linux reentrancy is basically the same in any OS:
code
> that must run atomically will. The only difference is the means utilized
to
> achieve the ends. But I’m not too sure what you mean by “recursive stack
> utilization”, can you expand ?
>
> And I don’t see why stack swapping done at the right level will break
> anything. As a matter of fact, the Pentium architecture does it when
calling
> between privilege levels, if nothing else I can see myself trying to fool
> the architecture to swap stacks for me.
>
> Alberto.
>
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Wednesday, May 22, 2002 2:27 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
>
> It is a question of OS philosophy. Unfortunately, your analysis is a
“hand
> wave” over the low-level details. (1) Allocate a “slab” of physical
memory.
> This is going to require some form of serialization. It also assumes a
> “slab” is available. What do you do when one is not available? Where
does
> it come from? Do you start page reclamation as part of this? (2)
Modifying
> the page tables again would require some form of serialization. (3) Moving
> the contents of stack. That is thread local, so the only serialization
> would be something like a raise to APC_LEVEL.
>
> And how do you decide to deal with recursive stack utilization. Linux
> doesn’t have the same problem because, being UNIX based, there are
> assumptions about OS reentrancy that differ.
>
> It is also difficult to do spot-comparisons such as this, as tempting as
it
> is to do so. What are the knock-on effects of changing this behavior? I
> know (for example) that there were changes in the way stack is managed in
> Windows XP and it broke some third party products that played games (like
> swapping the stack). Of course, Linux has a far smaller application base
> and thus we hear of fewer incompatibility issues - both because there are
> fewer, and because the volume of the complaints is smaller.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class October 7, 2002!
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Wednesday, May 22, 2002 2:02 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
> It’s a question of OS philosophy, no ? Expanding the stack requires (1)
> allocating a slab of physical memory, (2) mapping it to a page table
> somewhere, and (3) setting up a stack segment with that slab. This ends
the
> memory management issues, and all three functions are pretty low level
that
> can be easily handled without any additional locking complication. Not a
big
> deal, eh ? Definitely not rocket science, at least not if one includes the
> functionality within the guts of the system. And for a great way of
managing
> memory, look at the Linux slab allocator.
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Wednesday, May 22, 2002 1:43 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
>
> The kernel stack size is limited because it is using real physical memory
> and it isused under operating conditions where it is not possible to
extend
> it.
>
>
>
> Suppose, for example, the MM is writing data back out to the paging file
(in
> a nested call, no doubt) and that causes a stack overflow error. We jump
> back into the memory manager to grow the stack. This assumes a LOT about
> the locking model (which is already hideously complicated), the operations
> of other things on the system, the amount of available physical memory,
etc.
>
>
>
> The file systems (for example) have special case code for handling this
> issue - they actually post to the stack overflow worker thread.
>
>
>
> The choice was intentional - very few things at this level of the OS were
> unintentional. There are numerous trade-offs that must be made when
> developing an operating system and it shows hubris to sit here and
criticize
> design decisions made in 1989 and 1990. Sure the world has changed, and
the
> OS has changed quite a bit as well. But in 1990, could you have predicted
> the way the world is today?
>
>
>
> Of course, you can always make suggestions to the base team about what
> changes you’d like to see them make and why. Doesn’t mean they will make
> them - but there are enough people here with hooks into that team that at
> least your suggestion has a chance of being heard.
>
>
>
> Regards,
>
>
>
> Tony
>
>
>
> Tony Mason
>
> Consulting Partner
>
> OSR Open Systems Resources, Inc.
>
> http: http://www.osr.com
>
>
>
> Hope to see you at the next OSR file systems class October 7, 2002!
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Wednesday, May 22, 2002 1:04 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
>
>
> If this was done intentionally, it’s a pretty poor way of achieving
improved
> safety. Heck, this is kernel dev and not Java beans, how do they know I’m
> running on their stack, and not on my own ? Besides, give me a
decent-sized
> stack, please ! Or at least put the stack in its own segment so that a
stack
> overflow triggers an exception and the OS can expand the stack on the fly
to
> fit my need. And how can one make such a runtime decision from a compile
> time analysis ? I run things with BoundsChecker, which detects this kind
of
> issue at runtime, I find it a better idea. Furthermore, if what they want
is
> to detect a stack overuse condition at compile time, why don’t they just
> issue an error message in the compile ? I can think of better ways of
> frigging an error than to link one’s code with an unexisting library
> function.
>
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Graham, Simon [mailto:xxxxx@stratus.com]
> Sent: Wednesday, May 22, 2002 11:55 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
> More importantly - there is NO implementation of __chkstk for k-mode
> drivers; this is why the link fails when you start using huge local
> variables. Personally, I think it’s good to build drivers with this turned
> on since it lets you know when you start using huge amounts of stack -
> always an issue for drivers!
>
>
>
> /simgr
>
> -----Original Message-----
> From: Arup Banerjee [mailto:xxxxx@quark.co.in]
> Sent: Wednesday, May 22, 2002 11:04 AM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
> Arup, do
> > you happen to
> > know which library has that entry point ?
> >
>
> Address Publics by Value Rva+Base Lib:Object
> 0001:00003b10__chkstk 00404b10 f LIBC:chkstk.obj
>
>
> > Alberto.
> >
> >
> > -----Original Message-----
> > From: Arup Banerjee [mailto:xxxxx@quark.co.in
> mailto:xxxxx]
> > Sent: Wednesday, May 22, 2002 9:54 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Problem with arrays
> >
> >
> > kernel stack is 12KB if no GUI-related calls, 64KB for a GUI
> > thread. By
> > default, the compiler inserts a call to the __chkstk() function in the
> > prologue code for each function to compares the amount of
> > stack space a
> > function requires with the amount of stack space available.
> >
> > In NT atleast this is not explicit but probe is made if
> > requested allocation
> > is above 4k from the current stack pointer. In fact if u use
> > the compiler
> > option /Gs with threshold this check is made if local stack allocation
> > exceeds the specified threshold…
> >
> > Ur array declaration is somehow crossing the default
> > threshold which is not
> > detected when u’ve declared it as a pointer instead . In
> > order to supress
> > the__chkstk call use an imaginary high threshold value like
> > /Gs9999999999999999999. This would supress the compiler from calling
> > “__chkstk”.
> >
> > --Arup
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@ieee.org [mailto:xxxxx@ieee.org
> mailto:xxxxx]
> > > Sent: Wednesday, May 22, 2002 6:39 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Problem with arrays
> > >
> > >
> > >
> > > Guys,
> > >
> > > In the OS course I just gave, we bumped into a problem with a
> > > student’s driver: anytime I used an array of quadwords (to hold 64-
> > > bit timestamps) in the driver, the linker would complain that
> > > it could
> > > not resolve the symbol “__chkstk”. This happens both with the
> > > Win2K and the XP DDKs. Change it from an array to a pointer, and
> > > the problem disappears. Did any of you ever bump into this kind of
> > > problem ?
> > >
> > >
> > > Alberto.
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@quark.co.in
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@compuware.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > The contents of this e-mail are intended for the named
> > addressee only. It
> > contains information that may be confidential. Unless you are
> > the named
> > addressee or an authorized designee, you may not copy or use
> > it, or disclose
> > it to anyone else. If you received it in error please notify
> > us immediately
> > and then destroy it.
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@quark.co.in
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@osr.com
> To unsubscribe send a blank email to %%email.unsub%%
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@yoshimuni.com
> To unsubscribe send a blank email to %%email.unsub%%

—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.</mailto:xxxxx></mailto:xxxxx></http:>

22

It’s horrid BECAUSE of the 12K limit on stack size - like or not that is the
limit and therefore k-mode coders need to be careful with their use of
stack.

As Mark (and I!) said, chkstk being unresolved is just a handy way of
knowing that you did something questionable - I prefer his usual descriptive
wording though :wink:

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, May 22, 2002 2:52 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

I don’t see why. What I do see is that 12K stack is not enough, and THAT is
what I find unsafe: it invites hacks to circumvent that utterly artificial
restriction. And someone correct me, didn’t the old Microsoft display
drivers expand text into bitmap on the stack prior to rendering
ExtTextOut-supplied text via bitblt ? You may need way more than 12K to host
such a bitmap.

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, May 22, 2002 2:41 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

Allocating a 4k array on a kernel stack is a horrid idea. IMHO the chkstk
failure is a condom around an unsafe practice: don’t do this.

-----Original Message-----
From: Arup Banerjee [mailto:xxxxx@quark.co.in]
Sent: Wednesday, May 22, 2002 9:54 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

kernel stack is 12KB if no GUI-related calls, 64KB for a GUI
thread. By default, the compiler inserts a call to the
__chkstk() function in the prologue code for each function to
compares the amount of stack space a function requires with
the amount of stack space available.

In NT atleast this is not explicit but probe is made if
requested allocation is above 4k from the current stack
pointer. In fact if u use the compiler option /Gs with
threshold this check is made if local stack allocation
exceeds the specified threshold…

Ur array declaration is somehow crossing the default
threshold which is not detected when u’ve declared it as a
pointer instead . In order to supress the __chkstk call use
an imaginary high threshold value like
/Gs9999999999999999999. This would supress the compiler from
calling “__chkstk”.

–Arup

> -----Original Message-----
> From: xxxxx@ieee.org [mailto:xxxxx@ieee.org]
> Sent: Wednesday, May 22, 2002 6:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] Problem with arrays
>
>
>
> Guys,
>
> In the OS course I just gave, we bumped into a problem with a
> student’s driver: anytime I used an array of quadwords (to hold 64-
> bit timestamps) in the driver, the linker would complain that
> it could
> not resolve the symbol “__chkstk”. This happens both with the
> Win2K and the XP DDKs. Change it from an array to a pointer, and
> the problem disappears. Did any of you ever bump into this kind of
> problem ?
>
>
> Alberto.
>
> —
> You are currently subscribed to ntdev as: xxxxx@quark.co.in To
> unsubscribe send a blank email to %%email.unsub%%
>

You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to %%email.unsub%%

23

It’s a feature that makes that one architecture easier to use and more
flexible, and a good OS should take advantage of it. I personally like
segments, if NT took advantage of it the superiority of a segmented
architecture would clearly show.

Alberto.

-----Original Message-----
From: Tony Mason [mailto:xxxxx@osr.com]
Sent: Wednesday, May 22, 2002 3:12 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with arrays

Does this not then assume a specific hardware architecture, notably a
segmented one? If so, I can easily see why they didn’t engineer it that
way. While I’m not sure about the i860, the MIPS does not have a segmented
memory model. Nor, unless I’m missing something in my dust-covered alpha
and PPC reference manuals, do they. The IA64 does have compatibility stuff,
but that doesn’t apply to the 64-bit kernel world… I must admit, I’m not
so sure about AMD64.

A criticism of NT based upon the fact that they did not use a feature
present in the THIRD (of seven officially supported) CPU families seems week
at best.

Even so, physical memory still must be tracked/maintained, which involves
some sort of tracking data structure which in turn requires serialization,
which in turn adds the issues of reentrancy and deadlock.

Tony

Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com

Hope to see you at the next OSR file systems class October 7, 2002!

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, May 22, 2002 2:57 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with arrays

That’s why I keep saying stack SEGMENT. I believe in segments, and I believe
in the stack occupying an address space that’s disjoint from one’s data
segment. Growing the stack should be something that only involves physical
memory and the stack segment, without any impact on the data segment or on
its address space.

Alberto.

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

24

Let me put it this way: if I need more than 12K of stack I will have it, and
I’ll grab whatever I need from wherever I can. And I still want to see the
OS that cannot be defeated by a determined kernel dev.

Leaving chkstk() unresolved is a dirty, messy way of enforcing an artificial
restriction. It adds nothing to the safety or quality of the environment, it
enforces an arbitrary limit that may not have anything to do with reality,
and it invites hacking of all sorts.

If you guys like it, fine with me, but I don’t !

Alberto.

-----Original Message-----
From: Graham, Simon [mailto:xxxxx@stratus.com]
Sent: Wednesday, May 22, 2002 5:32 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

It’s horrid BECAUSE of the 12K limit on stack size - like or not that is the
limit and therefore k-mode coders need to be careful with their use of
stack.

As Mark (and I!) said, chkstk being unresolved is just a handy way of
knowing that you did something questionable - I prefer his usual descriptive
wording though :wink:

/simgr

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Wednesday, May 22, 2002 2:52 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

I don’t see why. What I do see is that 12K stack is not enough, and THAT is
what I find unsafe: it invites hacks to circumvent that utterly artificial
restriction. And someone correct me, didn’t the old Microsoft display
drivers expand text into bitmap on the stack prior to rendering
ExtTextOut-supplied text via bitblt ? You may need way more than 12K to host
such a bitmap.

Alberto.

-----Original Message-----
From: Roddy, Mark [mailto:xxxxx@stratus.com]
Sent: Wednesday, May 22, 2002 2:41 PM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

Allocating a 4k array on a kernel stack is a horrid idea. IMHO the chkstk
failure is a condom around an unsafe practice: don’t do this.

-----Original Message-----
From: Arup Banerjee [mailto:xxxxx@quark.co.in]
Sent: Wednesday, May 22, 2002 9:54 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

kernel stack is 12KB if no GUI-related calls, 64KB for a GUI
thread. By default, the compiler inserts a call to the
__chkstk() function in the prologue code for each function to
compares the amount of stack space a function requires with
the amount of stack space available.

In NT atleast this is not explicit but probe is made if
requested allocation is above 4k from the current stack
pointer. In fact if u use the compiler option /Gs with
threshold this check is made if local stack allocation
exceeds the specified threshold…

Ur array declaration is somehow crossing the default
threshold which is not detected when u’ve declared it as a
pointer instead . In order to supress the __chkstk call use
an imaginary high threshold value like
/Gs9999999999999999999. This would supress the compiler from
calling “__chkstk”.

–Arup

> -----Original Message-----
> From: xxxxx@ieee.org [mailto:xxxxx@ieee.org]
> Sent: Wednesday, May 22, 2002 6:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] Problem with arrays
>
>
>
> Guys,
>
> In the OS course I just gave, we bumped into a problem with a
> student’s driver: anytime I used an array of quadwords (to hold 64-
> bit timestamps) in the driver, the linker would complain that
> it could
> not resolve the symbol “__chkstk”. This happens both with the
> Win2K and the XP DDKs. Change it from an array to a pointer, and
> the problem disappears. Did any of you ever bump into this kind of
> problem ?
>
>
> Alberto.
>
> —
> You are currently subscribed to ntdev as: xxxxx@quark.co.in To
> unsubscribe send a blank email to %%email.unsub%%
>

You are currently subscribed to ntdev as:
xxxxx@stratus.com To unsubscribe send a blank email to
%%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to %%email.unsub%%

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

25

I don’t believe it would clearly show on an IA64 machine, or did you not
catch the reference? Or are you purposing a complete rewrite of the entire
memory manager, et al, for each new platform?

–
Bill McKenzie

“Moreira, Alberto” wrote in message
news:xxxxx@ntdev…
>
> It’s a feature that makes that one architecture easier to use and more
> flexible, and a good OS should take advantage of it. I personally like
> segments, if NT took advantage of it the superiority of a segmented
> architecture would clearly show.
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Tony Mason [mailto:xxxxx@osr.com]
> Sent: Wednesday, May 22, 2002 3:12 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Problem with arrays
>
>
> Does this not then assume a specific hardware architecture, notably a
> segmented one? If so, I can easily see why they didn’t engineer it that
> way. While I’m not sure about the i860, the MIPS does not have a
segmented
> memory model. Nor, unless I’m missing something in my dust-covered alpha
> and PPC reference manuals, do they. The IA64 does have compatibility
stuff,
> but that doesn’t apply to the 64-bit kernel world… I must admit, I’m
not
> so sure about AMD64.
>
> A criticism of NT based upon the fact that they did not use a feature
> present in the THIRD (of seven officially supported) CPU families seems
week
> at best.
>
> Even so, physical memory still must be tracked/maintained, which involves
> some sort of tracking data structure which in turn requires serialization,
> which in turn adds the issues of reentrancy and deadlock.
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
> Hope to see you at the next OSR file systems class October 7, 2002!
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Wednesday, May 22, 2002 2:57 PM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Problem with arrays
>
> That’s why I keep saying stack SEGMENT. I believe in segments, and I
believe
> in the stack occupying an address space that’s disjoint from one’s data
> segment. Growing the stack should be something that only involves physical
> memory and the stack segment, without any impact on the data segment or on
> its address space.
>
> Alberto.
>
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
>

26

>I don’t see why. What I do see is that 12K stack is not enough, and THAT is

what I find unsafe: it invites hacks to circumvent that utterly artificial
restriction. And someone correct me, didn’t the old Microsoft display
drivers expand text into bitmap on the stack prior to rendering
ExtTextOut-supplied text via bitblt ? You may need way more than 12K to host
such a bitmap.

It seems like the stack problem is actually a compiler implementation
issue. If the function prolog code set the stack pointer to the base of the
frame (it does this now) but left the base pointer pointing just above the
pushed parameters (it also does this now), and referenced local variables
as offsets from the stack instead of offsets from the base register (it
doesn’t do this now), then function prolog code (like in _chkstk) could
make the stack be a linked list of chunks. This slightly complicates things
for the compiler and debugger as the offset to local variables is no longer
the same value under all conditions (like when your pushing new parameters
on the stack), but it is a known compile time value. It also makes alloca
tricky to implement.

Basically on entering a function that uses of “too much” stack (or a
function the programmer informs the compiler via a pragma that it has stack
heavy callees), the stack could be set to point into a new chunk (for
storage of locals and someplace to push parameters for called functions)
and the base pointer could be left pointing into just below the parameters.
The return address would also need to point to a little handler that
unhooked the new stack chunk. A dedicated pool of stack chunks could be
preallocated, with some structure that avoided deadlock. The OS could
allocate more stack extension chunks when things are back to passive level.
The extra stack space is also NOT forever allocated. Performance of
entering/leaving to a stack hungry function would be slower, so avoiding
doing so in an inner loop would be appropriate. An important thing to keep
in mind is page tables would NOT have to be touched, as the preallocated
stack chunks would already be mapped to kernel space addresses.

I believe this would work on any processor that used a stack pointer and a
base pointer to access function activate frames. It offhand seems like you
could change the compiler, and new code would get the dynamic stacks and
old code would still be happy (the exception unwinder would need to free
intermediate chunks).

Some computer languages actually have stacks that are not stacks at all.
For example, in Smalltalk, it’s valid for references to local variables to
keep referencing those variables AFTER the routine returns, and the
run-time arranges for those referenced “stack” frames to not be deleted
until ALL references are gone (it’s a garbage collected language). This
also has the nice feature of eliminating the whole class of errors caused
by accessing a reference to a long gone stack frame (can you say memory
corruption).

Thinking of the “stack” as always being a contiguous linear array of bytes
is a pretty limited view.

  • Jan
27

If I remember correctly, 12K is the limit on kernel stacks for Non-Window
owning threads. For window owning threads the size of the stack appears to
be 64K. I looked at this a while ago…the brain grows fuzzy with age.

–Mark

–
Mark Cariddi
Open Systems Resources, Inc.
www.osr.com

“Graham, Simon” wrote in message
news:xxxxx@ntdev…
>
> It’s horrid BECAUSE of the 12K limit on stack size - like or not that is
the
> limit and therefore k-mode coders need to be careful with their use of
> stack.
>
> As Mark (and I!) said, chkstk being unresolved is just a handy way of
> knowing that you did something questionable - I prefer his usual
descriptive
> wording though :wink:
>
> /simgr
>
> -----Original Message-----
> From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> Sent: Wednesday, May 22, 2002 2:52 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
>
> I don’t see why. What I do see is that 12K stack is not enough, and THAT
is
> what I find unsafe: it invites hacks to circumvent that utterly artificial
> restriction. And someone correct me, didn’t the old Microsoft display
> drivers expand text into bitmap on the stack prior to rendering
> ExtTextOut-supplied text via bitblt ? You may need way more than 12K to
host
> such a bitmap.
>
> Alberto.
>
>
> -----Original Message-----
> From: Roddy, Mark [mailto:xxxxx@stratus.com]
> Sent: Wednesday, May 22, 2002 2:41 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: Problem with arrays
>
>
> Allocating a 4k array on a kernel stack is a horrid idea. IMHO the chkstk
> failure is a condom around an unsafe practice: don’t do this.
>
> > -----Original Message-----
> > From: Arup Banerjee [mailto:xxxxx@quark.co.in]
> > Sent: Wednesday, May 22, 2002 9:54 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Problem with arrays
> >
> >
> > kernel stack is 12KB if no GUI-related calls, 64KB for a GUI
> > thread. By default, the compiler inserts a call to the
> > __chkstk() function in the prologue code for each function to
> > compares the amount of stack space a function requires with
> > the amount of stack space available.
> >
> > In NT atleast this is not explicit but probe is made if
> > requested allocation is above 4k from the current stack
> > pointer. In fact if u use the compiler option /Gs with
> > threshold this check is made if local stack allocation
> > exceeds the specified threshold…
> >
> > Ur array declaration is somehow crossing the default
> > threshold which is not detected when u’ve declared it as a
> > pointer instead . In order to supress the__chkstk call use
> > an imaginary high threshold value like
> > /Gs9999999999999999999. This would supress the compiler from
> > calling “__chkstk”.
> >
> > --Arup
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@ieee.org [mailto:xxxxx@ieee.org]
> > > Sent: Wednesday, May 22, 2002 6:39 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Problem with arrays
> > >
> > >
> > >
> > > Guys,
> > >
> > > In the OS course I just gave, we bumped into a problem with a
> > > student’s driver: anytime I used an array of quadwords (to hold 64-
> > > bit timestamps) in the driver, the linker would complain that
> > > it could
> > > not resolve the symbol “__chkstk”. This happens both with the
> > > Win2K and the XP DDKs. Change it from an array to a pointer, and
> > > the problem disappears. Did any of you ever bump into this kind of
> > > problem ?
> > >
> > >
> > > Alberto.
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@quark.co.in To
> > > unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > %%email.unsub%%
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@compuware.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>
>
> The contents of this e-mail are intended for the named addressee only. It
> contains information that may be confidential. Unless you are the named
> addressee or an authorized designee, you may not copy or use it, or
disclose
> it to anyone else. If you received it in error please notify us
immediately
> and then destroy it.
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@stratus.com
> To unsubscribe send a blank email to %%email.unsub%%
>
>

28

I propose an attitude of taking advantage of the underlying
hardware. In the case of the Pentium, the machine is so
overwhelmingly pervasive that I see no point in neglecting its good
features for the sake of compatibility with less sophisticated
systems.

Alberto.

On 23 May 2002, at 1:50, Bill McKenzie wrote:

I don’t believe it would clearly show on an IA64 machine, or did you not
catch the reference? Or are you purposing a complete rewrite of the entire
memory manager, et al, for each new platform?

–
Bill McKenzie

“Moreira, Alberto” wrote in message
> news:xxxxx@ntdev…
> >
> > It’s a feature that makes that one architecture easier to use and more
> > flexible, and a good OS should take advantage of it. I personally like
> > segments, if NT took advantage of it the superiority of a segmented
> > architecture would clearly show.
> >
> > Alberto.
> >
> >
> >
> > -----Original Message-----
> > From: Tony Mason [mailto:xxxxx@osr.com]
> > Sent: Wednesday, May 22, 2002 3:12 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Problem with arrays
> >
> >
> > Does this not then assume a specific hardware architecture, notably a
> > segmented one? If so, I can easily see why they didn’t engineer it that
> > way. While I’m not sure about the i860, the MIPS does not have a
> segmented
> > memory model. Nor, unless I’m missing something in my dust-covered alpha
> > and PPC reference manuals, do they. The IA64 does have compatibility
> stuff,
> > but that doesn’t apply to the 64-bit kernel world… I must admit, I’m
> not
> > so sure about AMD64.
> >
> > A criticism of NT based upon the fact that they did not use a feature
> > present in the THIRD (of seven officially supported) CPU families seems
> week
> > at best.
> >
> > Even so, physical memory still must be tracked/maintained, which involves
> > some sort of tracking data structure which in turn requires serialization,
> > which in turn adds the issues of reentrancy and deadlock.
> >
> > Tony
> >
> > Tony Mason
> > Consulting Partner
> > OSR Open Systems Resources, Inc.
> > http://www.osr.com
> >
> > Hope to see you at the next OSR file systems class October 7, 2002!
> >
> > -----Original Message-----
> > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> > Sent: Wednesday, May 22, 2002 2:57 PM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Problem with arrays
> >
> > That’s why I keep saying stack SEGMENT. I believe in segments, and I
> believe
> > in the stack occupying an address space that’s disjoint from one’s data
> > segment. Growing the stack should be something that only involves physical
> > memory and the stack segment, without any impact on the data segment or on
> > its address space.
> >
> > Alberto.
> >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@compuware.com
> > To unsubscribe send a blank email to %%email.unsub%%
> >
> >
> >
> > The contents of this e-mail are intended for the named addressee only. It
> > contains information that may be confidential. Unless you are the named
> > addressee or an authorized designee, you may not copy or use it, or
> disclose
> > it to anyone else. If you received it in error please notify us
> immediately
> > and then destroy it.
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@ieee.org
> To unsubscribe send a blank email to %%email.unsub%%
>

29

I’ve followed this discussion for a while now and, until now, have not added
my US$ 0.02 worth. Regardless of our DESIRES or OPINIONS in this matter, I
think we must remain focused on one thing: Microsoft, and not we of this
list, controls the way NT/2K/XP handle kernel memory/stack management.
Given that, all the pining and wishing in the world will not change the way
things are done. Therefore, in my humble opinion, we need to focus on how
to make the supplied and sanctioned mechanisms work effectively and
efficiently to accomplish our goals and objectives. I have my personal
opinion on segmented vs. semi-flat memory architectures, but they are
irrelevant to the reality. Dave Cutler brought a wealth of OS design
experience to MS from DEC and then assembled a very talented staff of highly
experienced OS developers. There were far more design considerations
involved than we will ever know, so it is quite arrogant of anyone on this
list to condemn the choices made.

That’s all I’m going to say on this subject.
Have fun,
Greg

30

You’re one step away from the preferred implementation of Lisplike languages
such as Scheme. In that implementation there’s no such thing as a contiguous
stack, and context nesting is implemented through a list of environment
frames. Makes up for a clean implementation: all memory comes from the heap,
even if you call it “stack”. The stack is a list of frames, so, you only run
out of stack if you run out of heap - but then, the issue is the same, what
do you do when you need paged pool space and there ain’t none available ? In
older machines I worked with, such as the IBM/360, a procedure’s stack frame
was a contiguous chunk of memory, but the “stack” was rather a list of such
frames, chained if I remember correctly through R13.

I agree with you that this could be handled by the compiler, with the help
of a meaningful runtime library. Like I said before, one way of doing it is,
when the programmer specifies an array on the stack, allocate the pointer on
the stack but get the actual array space from the heap. That would alleviate
the shortcomings of a mickey-mouse stack, to a fair degree.

Alberto.

-----Original Message-----
From: Jan Bottorff [mailto:xxxxx@pmatrix.com]
Sent: Thursday, May 23, 2002 2:58 AM
To: NT Developers Interest List
Subject: [ntdev] RE: Problem with arrays

I don’t see why. What I do see is that 12K stack is not enough, and THAT is
what I find unsafe: it invites hacks to circumvent that utterly artificial
restriction. And someone correct me, didn’t the old Microsoft display
drivers expand text into bitmap on the stack prior to rendering
ExtTextOut-supplied text via bitblt ? You may need way more than 12K to
host
such a bitmap.

It seems like the stack problem is actually a compiler implementation
issue. If the function prolog code set the stack pointer to the base of the
frame (it does this now) but left the base pointer pointing just above the
pushed parameters (it also does this now), and referenced local variables
as offsets from the stack instead of offsets from the base register (it
doesn’t do this now), then function prolog code (like in _chkstk) could
make the stack be a linked list of chunks. This slightly complicates things
for the compiler and debugger as the offset to local variables is no longer
the same value under all conditions (like when your pushing new parameters
on the stack), but it is a known compile time value. It also makes alloca
tricky to implement.

Basically on entering a function that uses of “too much” stack (or a
function the programmer informs the compiler via a pragma that it has stack
heavy callees), the stack could be set to point into a new chunk (for
storage of locals and someplace to push parameters for called functions)
and the base pointer could be left pointing into just below the parameters.
The return address would also need to point to a little handler that
unhooked the new stack chunk. A dedicated pool of stack chunks could be
preallocated, with some structure that avoided deadlock. The OS could
allocate more stack extension chunks when things are back to passive level.
The extra stack space is also NOT forever allocated. Performance of
entering/leaving to a stack hungry function would be slower, so avoiding
doing so in an inner loop would be appropriate. An important thing to keep
in mind is page tables would NOT have to be touched, as the preallocated
stack chunks would already be mapped to kernel space addresses.

I believe this would work on any processor that used a stack pointer and a
base pointer to access function activate frames. It offhand seems like you
could change the compiler, and new code would get the dynamic stacks and
old code would still be happy (the exception unwinder would need to free
intermediate chunks).

Some computer languages actually have stacks that are not stacks at all.
For example, in Smalltalk, it’s valid for references to local variables to
keep referencing those variables AFTER the routine returns, and the
run-time arranges for those referenced “stack” frames to not be deleted
until ALL references are gone (it’s a garbage collected language). This
also has the nice feature of eliminating the whole class of errors caused
by accessing a reference to a long gone stack frame (can you say memory
corruption).

Thinking of the “stack” as always being a contiguous linear array of bytes
is a pretty limited view.

  • Jan

You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

31

You see IA64 as *less* sophisticated than the pentium architecture? I
personally think the predicated instructions, register renaming engine,
instruction level parallelism of a degree not seen before, data speculation,
and the like, make it somewhat more sophisticated than the processors we are
all likely running on today with technology circa 1980.

Whether it will fly or not, and thus whether MS shoud bother with it, is a
good question, but sophisticated? I think the HP boys have sufficiently
out-classed their Intel counterparts with this one, (yes this is an HP
design, not Intel’s, Intel bought it).

–
Bill McKenzie

wrote in message news:xxxxx@ntdev…
>
> I propose an attitude of taking advantage of the underlying
> hardware. In the case of the Pentium, the machine is so
> overwhelmingly pervasive that I see no point in neglecting its good
> features for the sake of compatibility with less sophisticated
> systems.
>
> Alberto.
>
>
> On 23 May 2002, at 1:50, Bill McKenzie wrote:
>
> > I don’t believe it would clearly show on an IA64 machine, or did you not
> > catch the reference? Or are you purposing a complete rewrite of the
entire
> > memory manager, et al, for each new platform?
> >
> > –
> > Bill McKenzie
> >
> >
> >
> > “Moreira, Alberto” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > It’s a feature that makes that one architecture easier to use and more
> > > flexible, and a good OS should take advantage of it. I personally like
> > > segments, if NT took advantage of it the superiority of a segmented
> > > architecture would clearly show.
> > >
> > > Alberto.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Tony Mason [mailto:xxxxx@osr.com]
> > > Sent: Wednesday, May 22, 2002 3:12 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: Problem with arrays
> > >
> > >
> > > Does this not then assume a specific hardware architecture, notably a
> > > segmented one? If so, I can easily see why they didn’t engineer it
that
> > > way. While I’m not sure about the i860, the MIPS does not have a
> > segmented
> > > memory model. Nor, unless I’m missing something in my dust-covered
alpha
> > > and PPC reference manuals, do they. The IA64 does have compatibility
> > stuff,
> > > but that doesn’t apply to the 64-bit kernel world… I must admit,
I’m
> > not
> > > so sure about AMD64.
> > >
> > > A criticism of NT based upon the fact that they did not use a feature
> > > present in the THIRD (of seven officially supported) CPU families
seems
> > week
> > > at best.
> > >
> > > Even so, physical memory still must be tracked/maintained, which
involves
> > > some sort of tracking data structure which in turn requires
serialization,
> > > which in turn adds the issues of reentrancy and deadlock.
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > > Hope to see you at the next OSR file systems class October 7, 2002!
> > >
> > > -----Original Message-----
> > > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> > > Sent: Wednesday, May 22, 2002 2:57 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: Problem with arrays
> > >
> > > That’s why I keep saying stack SEGMENT. I believe in segments, and I
> > believe
> > > in the stack occupying an address space that’s disjoint from one’s
data
> > > segment. Growing the stack should be something that only involves
physical
> > > memory and the stack segment, without any impact on the data segment
or on
> > > its address space.
> > >
> > > Alberto.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
xxxxx@compuware.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee only.
It
> > > contains information that may be confidential. Unless you are the
named
> > > addressee or an authorized designee, you may not copy or use it, or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>

32

Have you noticed that whenever one proposes that an OS handle something in a
more sophisticated way the usual argument against it is, “no, let’s not do
it for compatibility sake, because only a Pentium has that hardware” ? Can’t
take full advantage of static nesting, Algol style, because only a Pentium
has a hardware stack. Can’t take advantage of big-time segmentation because
only a Pentium has segmentation. Can’t take full advantage of protection
because only a Pentium has protection. Can’t take advantage of repeat
instructions because only the Pentium has them. Can’t take advantage of
write-to-memory instructions because only the Pentium has them. Can’t take
advantage of…

Oh, heck, I could go on. The argument seems to be, let’s stick forever to C
and a flat model, because only a Pentium has hardware to do anything more
than that. And G-O-L-L-Y, see how fast I can run SpecBench in a flat model
turbocharged RISC ?

But what’s the point if I can’t even have floating point operations in my
kernel-side OpenGL ICD ?

On one plane, the IA64 has all the modern pipeline bells and whistles, but
it is, still, a pretty straightforward flat model. And even then, the OOO
pipeline of a modern Pentium system is pretty sophisticated too, and you
only have to go to comp.arch to see people pooh-pooing the IA64. But the
Pentium is a segmented architecture with a heavy emphasis in big-time
protection, and all that is just not available in other architectures:
segments, rings of protection, hardware-managed stack transitions, none of
that exists in an IA64. So, the OS designer has to revert to a flat model
because there’s nothing better available elsewhere, one has to revert to a
two-tier user/kernel model because there’s nothing better available
elsewhere, and so on. For example, I would have taken advantage of the
Pentium architecture to implement the kernel in Ring 0, I/O in Ring 1,
Shells at Ring 2 and Apps at Ring 3, I would have kept the stack as a
separate segment, I would have lobbied Intel heavily to give me more segment
registers, I would have implemented my run-time objects in my OO languages
as segments, and I would have implemented message passing as a fundamental
OS mechanism, where a message is implemented as an object, that is, as a
segment. I would also have lobbied Intel heavily to add hardware queues to
the architecture and to separate I/O processing from the CPU, a bit like we
used to have at Sperry and CDC eons ago, or in the IBM 7044/7094, or even in
the IBM/360 Multiplexer and Selector channels of old. As for parallelism,
predication, I believe in massive parallelism: I’d rather use my gates to
implement gobs of on-chip simple processors rather than to optimize one
processor for ILP. So, my reation to the IA64 is, thanks but my heart is
elsewhere. The machine I want to see is a CM2 in a chip, if you see what I
mean: say, 256 processors connected as an 8-dimensional hypercube, that
would beat an IA64 hands down.

But this eons away from NTDEV ! Sorry for the off-topic post.

Alberto.

-----Original Message-----
From: Bill McKenzie [mailto:xxxxx@driver.attbbs.com]
Sent: Thursday, May 23, 2002 11:21 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with arrays

You see IA64 as *less* sophisticated than the pentium architecture? I
personally think the predicated instructions, register renaming engine,
instruction level parallelism of a degree not seen before, data speculation,
and the like, make it somewhat more sophisticated than the processors we are
all likely running on today with technology circa 1980.

Whether it will fly or not, and thus whether MS shoud bother with it, is a
good question, but sophisticated? I think the HP boys have sufficiently
out-classed their Intel counterparts with this one, (yes this is an HP
design, not Intel’s, Intel bought it).

–
Bill McKenzie

wrote in message news:xxxxx@ntdev…
>
> I propose an attitude of taking advantage of the underlying
> hardware. In the case of the Pentium, the machine is so
> overwhelmingly pervasive that I see no point in neglecting its good
> features for the sake of compatibility with less sophisticated
> systems.
>
> Alberto.
>
>
> On 23 May 2002, at 1:50, Bill McKenzie wrote:
>
> > I don’t believe it would clearly show on an IA64 machine, or did you not
> > catch the reference? Or are you purposing a complete rewrite of the
entire
> > memory manager, et al, for each new platform?
> >
> > –
> > Bill McKenzie
> >
> >
> >
> > “Moreira, Alberto” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > It’s a feature that makes that one architecture easier to use and more
> > > flexible, and a good OS should take advantage of it. I personally like
> > > segments, if NT took advantage of it the superiority of a segmented
> > > architecture would clearly show.
> > >
> > > Alberto.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Tony Mason [mailto:xxxxx@osr.com]
> > > Sent: Wednesday, May 22, 2002 3:12 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: Problem with arrays
> > >
> > >
> > > Does this not then assume a specific hardware architecture, notably a
> > > segmented one? If so, I can easily see why they didn’t engineer it
that
> > > way. While I’m not sure about the i860, the MIPS does not have a
> > segmented
> > > memory model. Nor, unless I’m missing something in my dust-covered
alpha
> > > and PPC reference manuals, do they. The IA64 does have compatibility
> > stuff,
> > > but that doesn’t apply to the 64-bit kernel world… I must admit,
I’m
> > not
> > > so sure about AMD64.
> > >
> > > A criticism of NT based upon the fact that they did not use a feature
> > > present in the THIRD (of seven officially supported) CPU families
seems
> > week
> > > at best.
> > >
> > > Even so, physical memory still must be tracked/maintained, which
involves
> > > some sort of tracking data structure which in turn requires
serialization,
> > > which in turn adds the issues of reentrancy and deadlock.
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > > Hope to see you at the next OSR file systems class October 7, 2002!
> > >
> > > -----Original Message-----
> > > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> > > Sent: Wednesday, May 22, 2002 2:57 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: Problem with arrays
> > >
> > > That’s why I keep saying stack SEGMENT. I believe in segments, and I
> > believe
> > > in the stack occupying an address space that’s disjoint from one’s
data
> > > segment. Growing the stack should be something that only involves
physical
> > > memory and the stack segment, without any impact on the data segment
or on
> > > its address space.
> > >
> > > Alberto.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
xxxxx@compuware.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee only.
It
> > > contains information that may be confidential. Unless you are the
named
> > > addressee or an authorized designee, you may not copy or use it, or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>

—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

33

NT could conceivably have implemented a kernel stack size controlled by
some system parameter (a la VMS) to deal with cases where modest space
expansion is needed, but that requires a sizeable infrastructure back in
the boot path which may have seemed excessive when NT was designed. Recall
that a 16 MHz 486 or some such was used back then…far slower than we
can even recall clearly today.

Intel may have been leery of designs with extended segmenting. Remember the
iAPX 432? Elegant design, but the fancy segmentation and address bounding
cost bigtime in speed. Or remember the Vax ISA. One instruction evaluates
your
polynomial…but the complex instructions were excessively hard to speed up.

The present design merely says that in kernel mode, storage should be
static,
found in a heap, dynamically allocated, or the like, while the stack is
there
to allow fast context switches and interrupts. That is not a major
constraint
for most problems. Should segmentation techniques become popular in user
mode,
proving that performance tradeoffs need not be as bad as in the past, we can
expect such things to migrate to kernel designs. Such things have however
had
their downsides in the past.

-----Original Message-----
From: Moreira, Alberto [mailto:xxxxx@compuware.com]
Sent: Thursday, May 23, 2002 11:54 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with arrays

Have you noticed that whenever one proposes that an OS handle something in a
more sophisticated way the usual argument against it is, “no, let’s not do
it for compatibility sake, because only a Pentium has that hardware” ? Can’t
take full advantage of static nesting, Algol style, because only a Pentium
has a hardware stack. Can’t take advantage of big-time segmentation because
only a Pentium has segmentation. Can’t take full advantage of protection
because only a Pentium has protection. Can’t take advantage of repeat
instructions because only the Pentium has them. Can’t take advantage of
write-to-memory instructions because only the Pentium has them. Can’t take
advantage of…

Oh, heck, I could go on. The argument seems to be, let’s stick forever to C
and a flat model, because only a Pentium has hardware to do anything more
than that. And G-O-L-L-Y, see how fast I can run SpecBench in a flat model
turbocharged RISC ?

But what’s the point if I can’t even have floating point operations in my
kernel-side OpenGL ICD ?

On one plane, the IA64 has all the modern pipeline bells and whistles, but
it is, still, a pretty straightforward flat model. And even then, the OOO
pipeline of a modern Pentium system is pretty sophisticated too, and you
only have to go to comp.arch to see people pooh-pooing the IA64. But the
Pentium is a segmented architecture with a heavy emphasis in big-time
protection, and all that is just not available in other architectures:
segments, rings of protection, hardware-managed stack transitions, none of
that exists in an IA64. So, the OS designer has to revert to a flat model
because there’s nothing better available elsewhere, one has to revert to a
two-tier user/kernel model because there’s nothing better available
elsewhere, and so on. For example, I would have taken advantage of the
Pentium architecture to implement the kernel in Ring 0, I/O in Ring 1,
Shells at Ring 2 and Apps at Ring 3, I would have kept the stack as a
separate segment, I would have lobbied Intel heavily to give me more segment
registers, I would have implemented my run-time objects in my OO languages
as segments, and I would have implemented message passing as a fundamental
OS mechanism, where a message is implemented as an object, that is, as a
segment. I would also have lobbied Intel heavily to add hardware queues to
the architecture and to separate I/O processing from the CPU, a bit like we
used to have at Sperry and CDC eons ago, or in the IBM 7044/7094, or even in
the IBM/360 Multiplexer and Selector channels of old. As for parallelism,
predication, I believe in massive parallelism: I’d rather use my gates to
implement gobs of on-chip simple processors rather than to optimize one
processor for ILP. So, my reation to the IA64 is, thanks but my heart is
elsewhere. The machine I want to see is a CM2 in a chip, if you see what I
mean: say, 256 processors connected as an 8-dimensional hypercube, that
would beat an IA64 hands down.

But this eons away from NTDEV ! Sorry for the off-topic post.

Alberto.

-----Original Message-----
From: Bill McKenzie [mailto:xxxxx@driver.attbbs.com]
Sent: Thursday, May 23, 2002 11:21 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with arrays

You see IA64 as *less* sophisticated than the pentium architecture? I
personally think the predicated instructions, register renaming engine,
instruction level parallelism of a degree not seen before, data speculation,
and the like, make it somewhat more sophisticated than the processors we are
all likely running on today with technology circa 1980.

Whether it will fly or not, and thus whether MS shoud bother with it, is a
good question, but sophisticated? I think the HP boys have sufficiently
out-classed their Intel counterparts with this one, (yes this is an HP
design, not Intel’s, Intel bought it).

–
Bill McKenzie

wrote in message news:xxxxx@ntdev…
>
> I propose an attitude of taking advantage of the underlying
> hardware. In the case of the Pentium, the machine is so
> overwhelmingly pervasive that I see no point in neglecting its good
> features for the sake of compatibility with less sophisticated
> systems.
>
> Alberto.
>
>
> On 23 May 2002, at 1:50, Bill McKenzie wrote:
>
> > I don’t believe it would clearly show on an IA64 machine, or did you not
> > catch the reference? Or are you purposing a complete rewrite of the
entire
> > memory manager, et al, for each new platform?
> >
> > –
> > Bill McKenzie
> >
> >
> >
> > “Moreira, Alberto” wrote in message
> > news:xxxxx@ntdev…
> > >
> > > It’s a feature that makes that one architecture easier to use and more
> > > flexible, and a good OS should take advantage of it. I personally like
> > > segments, if NT took advantage of it the superiority of a segmented
> > > architecture would clearly show.
> > >
> > > Alberto.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Tony Mason [mailto:xxxxx@osr.com]
> > > Sent: Wednesday, May 22, 2002 3:12 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: Problem with arrays
> > >
> > >
> > > Does this not then assume a specific hardware architecture, notably a
> > > segmented one? If so, I can easily see why they didn’t engineer it
that
> > > way. While I’m not sure about the i860, the MIPS does not have a
> > segmented
> > > memory model. Nor, unless I’m missing something in my dust-covered
alpha
> > > and PPC reference manuals, do they. The IA64 does have compatibility
> > stuff,
> > > but that doesn’t apply to the 64-bit kernel world… I must admit,
I’m
> > not
> > > so sure about AMD64.
> > >
> > > A criticism of NT based upon the fact that they did not use a feature
> > > present in the THIRD (of seven officially supported) CPU families
seems
> > week
> > > at best.
> > >
> > > Even so, physical memory still must be tracked/maintained, which
involves
> > > some sort of tracking data structure which in turn requires
serialization,
> > > which in turn adds the issues of reentrancy and deadlock.
> > >
> > > Tony
> > >
> > > Tony Mason
> > > Consulting Partner
> > > OSR Open Systems Resources, Inc.
> > > http://www.osr.com
> > >
> > > Hope to see you at the next OSR file systems class October 7, 2002!
> > >
> > > -----Original Message-----
> > > From: Moreira, Alberto [mailto:xxxxx@compuware.com]
> > > Sent: Wednesday, May 22, 2002 2:57 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Re: Problem with arrays
> > >
> > > That’s why I keep saying stack SEGMENT. I believe in segments, and I
> > believe
> > > in the stack occupying an address space that’s disjoint from one’s
data
> > > segment. Growing the stack should be something that only involves
physical
> > > memory and the stack segment, without any impact on the data segment
or on
> > > its address space.
> > >
> > > Alberto.
> > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
xxxxx@compuware.com
> > > To unsubscribe send a blank email to %%email.unsub%%
> > >
> > >
> > >
> > > The contents of this e-mail are intended for the named addressee only.
It
> > > contains information that may be confidential. Unless you are the
named
> > > addressee or an authorized designee, you may not copy or use it, or
> > disclose
> > > it to anyone else. If you received it in error please notify us
> > immediately
> > > and then destroy it.
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@ieee.org
> > To unsubscribe send a blank email to %%email.unsub%%
> >
>
>
>
>

—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%

The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.

—
You are currently subscribed to ntdev as: xxxxx@FirstUSA.com
To unsubscribe send a blank email to %%email.unsub%%


This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you

34

> functionality within the guts of the system. And for a great way of managing

memory, look at the Linux slab allocator.

…which is the same as NT’s lookaside lists.

Max

35

IA64 looks like, nothing but HP PARISC 2.0. Though PA
RISC 2.0 architecture defines all the new things that
IA64 boasts, it probably was not implemented by the
current PA RISC processors.

— Bill McKenzie
wrote: > You see IA64 as less sophisticated than the
> pentium architecture? I
> personally think the predicated instructions,
> register renaming engine,
> instruction level parallelism of a degree not seen
> before, data speculation,
> and the like, make it somewhat more sophisticated
> than the processors we are
> all likely running on today with technology circa
> 1980.
>
> Whether it will fly or not, and thus whether MS
> shoud bother with it, is a
> good question, but sophisticated? I think the HP
> boys have sufficiently
> out-classed their Intel counterparts with this one,
> (yes this is an HP
> design, not Intel’s, Intel bought it).
>
> –
> Bill McKenzie
>
>
>
> wrote in message
> news:xxxxx@ntdev…
> >
> > I propose an attitude of taking advantage of the
> underlying
> > hardware. In the case of the Pentium, the machine
> is so
> > overwhelmingly pervasive that I see no point in
> neglecting its good
> > features for the sake of compatibility with less
> sophisticated
> > systems.
> >
> > Alberto.
> >
> >
> > On 23 May 2002, at 1:50, Bill McKenzie wrote:
> >
> > > I don’t believe it would clearly show on an IA64
> machine, or did you not
> > > catch the reference? Or are you purposing a
> complete rewrite of the
> entire
> > > memory manager, et al, for each new platform?
> > >
> > > –
> > > Bill McKenzie
> > >
> > >
> > >
> > > “Moreira, Alberto”
> wrote in message
> > > news:xxxxx@ntdev…
> > > >
> > > > It’s a feature that makes that one
> architecture easier to use and more
> > > > flexible, and a good OS should take advantage
> of it. I personally like
> > > > segments, if NT took advantage of it the
> superiority of a segmented
> > > > architecture would clearly show.
> > > >
> > > > Alberto.
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Tony Mason [mailto:xxxxx@osr.com]
> > > > Sent: Wednesday, May 22, 2002 3:12 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] Re: Problem with arrays
> > > >
> > > >
> > > > Does this not then assume a specific hardware
> architecture, notably a
> > > > segmented one? If so, I can easily see why
> they didn’t engineer it
> that
> > > > way. While I’m not sure about the i860, the
> MIPS does not have a
> > > segmented
> > > > memory model. Nor, unless I’m missing
> something in my dust-covered
> alpha
> > > > and PPC reference manuals, do they. The IA64
> does have compatibility
> > > stuff,
> > > > but that doesn’t apply to the 64-bit kernel
> world… I must admit,
> I’m
> > > not
> > > > so sure about AMD64.
> > > >
> > > > A criticism of NT based upon the fact that
> they did not use a feature
> > > > present in the THIRD (of seven officially
> supported) CPU families
> seems
> > > week
> > > > at best.
> > > >
> > > > Even so, physical memory still must be
> tracked/maintained, which
> involves
> > > > some sort of tracking data structure which in
> turn requires
> serialization,
> > > > which in turn adds the issues of reentrancy
> and deadlock.
> > > >
> > > > Tony
> > > >
> > > > Tony Mason
> > > > Consulting Partner
> > > > OSR Open Systems Resources, Inc.
> > > > http://www.osr.com
> > > >
> > > > Hope to see you at the next OSR file systems
> class October 7, 2002!
> > > >
> > > > -----Original Message-----
> > > > From: Moreira, Alberto
> [mailto:xxxxx@compuware.com]
> > > > Sent: Wednesday, May 22, 2002 2:57 PM
> > > > To: NT Developers Interest List
> > > > Subject: [ntdev] Re: Problem with arrays
> > > >
> > > > That’s why I keep saying stack SEGMENT. I
> believe in segments, and I
> > > believe
> > > > in the stack occupying an address space that’s
> disjoint from one’s
> data
> > > > segment. Growing the stack should be something
> that only involves
> physical
> > > > memory and the stack segment, without any
> impact on the data segment
> or on
> > > > its address space.
> > > >
> > > > Alberto.
> > > >
> > > >
> > > >
> > > >
> > > > —
> > > > You are currently subscribed to ntdev as:
> xxxxx@compuware.com
> > > > To unsubscribe send a blank email to
> %%email.unsub%%
> > > >
> > > >
> > > >
> > > > The contents of this e-mail are intended for
> the named addressee only.
> It
> > > > contains information that may be confidential.
> Unless you are the
> named
> > > > addressee or an authorized designee, you may
> not copy or use it, or
> > > disclose
> > > > it to anyone else. If you received it in error
> please notify us
> > > immediately
> > > > and then destroy it.
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > —
> > > You are currently subscribed to ntdev as:
> xxxxx@ieee.org
> > > To unsubscribe send a blank email to
> %%email.unsub%%
> > >
> >
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@yahoo.com
> To unsubscribe send a blank email to
%%email.unsub%%

________________________________________________________________________
Everything you always wanted to know about cars and bikes,now
at: http://in.autos.yahoo.com/cricket/tracker.html

36

> And how do you decide to deal with recursive stack utilization. Linux

doesn’t have the same problem because, being UNIX based, there are
assumptions about OS reentrancy that differ.

Linux has even much worse problem then NT in terms of kernel stack overflow.
They use the process structure at the bottom of the stack, and current() is defined as:
( esp - ( esp % ( 2 * PAGE_SIZE ) ) )
or such.
So, in case of stack overflow, Linux will damage the process descriptor structure and die in an ugly way, not in gentle double fault
bugcheck as NT.

swapping the stack). Of course, Linux has a far smaller application base
and thus we hear of fewer incompatibility issues - both because there are
fewer, and because the volume of the complaints is smaller.

For kmode Linux code, only the source availability helps to debug it. Anyway Linux still has bugs - I saw the discussion at Jan
2001 - create an AF_UNIX socket and set SO_SNDBUF to 256KB, then send something, the OS will die. Yes, they had a panic on kmalloc()
failure. Compare this to MS who eliminated the must succeed pool in XP.

Personally, I see absolutely no need in Linux, since there is FreeBSD designed and written by much more serious people, older and
thus more debugged. In terms of apps, Linux and FreeBSD are the same.

Max

37

> That’s why I keep saying stack SEGMENT. I believe in segments

Maybe you believe in SS != DS issues too? How will a pointer to a local variable be passed in this case?
Segments are probably good for one and only one purpose - to declare a hard-coded address space region for Ring 1 or Ring 2
subsystem. UNIXen cannot use this - they use only 2 protection levels - but, for instance, modern NT could use this for win32k’s
“session space”, which is isolated from the kernel conceptually anyway (you cannot call kernel functions from kmode graphics DLLs).
Far pointers are very bad, since segment register loads are slow.

in the stack occupying an address space that’s disjoint from one’s data
segment

I can hardly imagine x86 CPU handling faults in kernel stack segment. Double fault will occur the same way as in existing NT.
Only the task gate can be used to handle Ring 0 stack faults, since double fault handler loses context and cannot do the restart.

Max

38

> resources being synchronized and not to anything else. Moving the contents

of the stack

…and patching all pointers to all local variables?
Java VM’s can do this, but not real CPUs.

The assumption under Linux reentrancy is basically the same in any OS: code
that must run atomically will. The only difference is the means utilized to
achieve the ends. But I’m not too sure what you mean by “recursive stack
utilization”, can you expand ?

Linux is even worse in terms of stack use due to using rounded ESP to address the process structure.

Max

39

Also note that MiAllocatePoolPages for a single page is a very, very fast operation. Why use the stack for it?

Max

----- Original Message -----
From: “Roddy, Mark”
To: “NT Developers Interest List”
Sent: Wednesday, May 22, 2002 10:41 PM
Subject: [ntdev] RE: Problem with arrays

> Allocating a 4k array on a kernel stack is a horrid idea. IMHO the chkstk
> failure is a condom around an unsafe practice: don’t do this.
>
> > -----Original Message-----
> > From: Arup Banerjee [mailto:xxxxx@quark.co.in]
> > Sent: Wednesday, May 22, 2002 9:54 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] RE: Problem with arrays
> >
> >
> > kernel stack is 12KB if no GUI-related calls, 64KB for a GUI
> > thread. By default, the compiler inserts a call to the
> > __chkstk() function in the prologue code for each function to
> > compares the amount of stack space a function requires with
> > the amount of stack space available.
> >
> > In NT atleast this is not explicit but probe is made if
> > requested allocation is above 4k from the current stack
> > pointer. In fact if u use the compiler option /Gs with
> > threshold this check is made if local stack allocation
> > exceeds the specified threshold…
> >
> > Ur array declaration is somehow crossing the default
> > threshold which is not detected when u’ve declared it as a
> > pointer instead . In order to supress the__chkstk call use
> > an imaginary high threshold value like
> > /Gs9999999999999999999. This would supress the compiler from
> > calling “__chkstk”.
> >
> > --Arup
> >
> >
> > > -----Original Message-----
> > > From: xxxxx@ieee.org [mailto:xxxxx@ieee.org]
> > > Sent: Wednesday, May 22, 2002 6:39 PM
> > > To: NT Developers Interest List
> > > Subject: [ntdev] Problem with arrays
> > >
> > >
> > >
> > > Guys,
> > >
> > > In the OS course I just gave, we bumped into a problem with a
> > > student’s driver: anytime I used an array of quadwords (to hold 64-
> > > bit timestamps) in the driver, the linker would complain that
> > > it could
> > > not resolve the symbol “__chkstk”. This happens both with the
> > > Win2K and the XP DDKs. Change it from an array to a pointer, and
> > > the problem disappears. Did any of you ever bump into this kind of
> > > problem ?
> > >
> > >
> > > Alberto.
> > >
> > > —
> > > You are currently subscribed to ntdev as: xxxxx@quark.co.in To
> > > unsubscribe send a blank email to %%email.unsub%%
> > >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@stratus.com To unsubscribe send a blank email to
> > %%email.unsub%%
> >
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to %%email.unsub%%
>

40

> segmented one? If so, I can easily see why they didn’t engineer it that

way. While I’m not sure about the i860, the MIPS does not have a segmented
memory model.

IIRC i860 too, I have read the spec on this chip in around 1992. Strange that Intel never used it for real machines (only for 3D
accelerator and scientific computing expansion cards), could be something like Alpha, at least the FPU was excellent.

Max