> 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.
Posting the operation to other thread is a good solution, why not?
At least pointers to local variables are preserved.
Max
> 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),
It does with FPO.
then function prolog code (like in _chkstk) could
make the stack be a linked list of chunks.
According to GNU sources, Cray machines really have no usual stack and use this way instead of stack.
on the stack), but it is a known compile time value. It also makes alloca
tricky to implement.
In NT kernel, alloca is really a devastating idea.
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.
In fact, nearly this occurs while posting a stack-hungry request to the worker thread.
Max
Didn’t say IA64 looked anything like PARISC.
http://www.hpl.hp.com/news/2001/apr-jun/itanium.html
If you look at the history, the early PlayDoh architecture was completely
HP’s baby, and Intel bought it, both conceptually, and with cold hard cash.
–
Bill McKenzie
“sajeev sas” wrote in message news:xxxxx@ntdev…
>
> 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
>
>
“Bill McKenzie” wrote in message news:xxxxx@ntdev…
>
> 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.
Having just seen (i.e., today) a dual P4 with hyperthreading (AKA Jackson technology),
that pretends its 4 CPUs,
I suspect that you were not using anything so sophisticated in 1980. Its just
the same brain-dead instruction set.
-DH
>
> 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%%
> > >
> >
> >
> >
> >
>
>
>
>
I suspect if you talked to Intel, they’d say they didn’t put these features in the
IA64 because the OS doesn’t use them in the x86, so they are unnecessary…
-DH
“Moreira, Alberto” wrote in message news:xxxxx@ntdev…
>
> 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.
>
>
>
Well, I don’t doubt the chip speeds are faster, or that two cores are better
than one. But, as the early P4s were slower than slower clocked P3s running
the same software, not sure of the technological evolution here. But, I do
realize that to keep bleeding an essentially 80’s architecture you have to
make some hard decisions to improve scalability.
I would sure like to try out one of those hyper-threaded chips though 
–
Bill McKenzie
“Dave Harvey” wrote in message
news:xxxxx@ntdev…
>
>
> “Bill McKenzie” wrote in message
news:xxxxx@ntdev…
> >
> > 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.
> Having just seen (i.e., today) a dual P4 with hyperthreading (AKA Jackson
technology),
> that pretends its 4 CPUs,
> I suspect that you were not using anything so sophisticated in 1980. Its
just
> the same brain-dead instruction set.
> -DH
>
> >
> > 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%%
> > > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>
On Thu, 23 May 2002, Maxim S. Shatskih wrote:
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.
Linux supports more platforms (FreeBSD is pretty much x86-only), Linux
supports multiple processors significantly better.
–
Peter xxxxx@inkvine.fluff.org
http://www.inkvine.fluff.org/~peter/
logic kicks ass:
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.
> Linux supports more platforms (FreeBSD is pretty much x86-only),
Linux
supports multiple processors significantly better.
Linux’s SMP support with a giant kernel spinlock is abysmal, is
FreeBSD even worse in this respect?
Max
At 10.20 25/05/2002, you wrote:
> Linux supports more platforms (FreeBSD is pretty much x86-only), Linux
> supports multiple processors significantly better.
Linux’s SMP support with a giant kernel spinlock is abysmal,
AFAIK, they plan to fix it (or maybe I’m thinking about the giant spinlock
that serializes asynch I/O?) for the 2.5 release
The variable is supposed to be local, no ? And pointers should not
exist, they’re messy and unreliable.
Alberto.
On 23 May 2002, at 21:29, Maxim S. Shatskih wrote:
> 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
> segmentI 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
You are currently subscribed to ntdev as: xxxxx@ieee.org
To unsubscribe send a blank email to %%email.unsub%%
On Sat, 25 May 2002, Maxim S. Shatskih wrote:
Linux’s SMP support with a giant kernel spinlock is abysmal, is
FreeBSD even worse in this respect?
That was true in the Linux 2.0 and 2.2 days. There still exists a lock
around certain parts of the kernel in 2.4, but it’s considerably more
fine-grained than it used to be (such that it scales reasonably with
processors).
It’s still very much true of FreeBSD; there is work being done to fix it,
but at the moment, FreeBSD is still at best mediocre on multiple
processors.
–
Peter xxxxx@inkvine.fluff.org
http://www.inkvine.fluff.org/~peter/
logic kicks ass:
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.
> The variable is supposed to be local, no ?
No. Consider this:
void f(int*, int*);
int Global;
void f1(void)
{
int Local;
f(&Global, &Local);
}
Now consider how this code must be compiled for segmented architecture
for near memory model in a DLL module, when f1() is called by the EXE.
Far pointers are just plain evil. Very good that Win16 is dead, it was
one of the worst things in Win16. MakeProcInstance is one more
atrocious thing.
Max
In his case, f runs on the same stack segment as f1. I will go
further and say that no DLL should have its own stack unless it is a
case like a driver, where the DLL instates its own stack and then
flips back to the original before returning control.
The evil is not “far” pointers. The evil is the distinction. If all pointers
are “far” - segment plus offset - there’s no issue. The key point
being, in a decent architecture all points should be equal, and I
don’t see why not only have far pointers. The very small savings
from using near pointers are pretty irrelevant, specially with the
large memory sizes available in today’s machines. Remember, C
was designed with very small machines in mind, we’re well past
that point.
Alberto.
On 25 May 2002, at 23:28, Maxim S. Shatskih wrote:
> The variable is supposed to be local, no ?
No. Consider this:
void f(int*, int*);
int Global;
void f1(void)
{
int Local;
f(&Global, &Local);
}Now consider how this code must be compiled for segmented architecture
for near memory model in a DLL module, when f1() is called by the EXE.Far pointers are just plain evil. Very good that Win16 is dead, it was
one of the worst things in Win16. MakeProcInstance is one more
atrocious thing.Max
You are currently subscribed to ntdev as: xxxxx@ieee.org
To unsubscribe send a blank email to %%email.unsub%%
> The evil is not “far” pointers. The evil is the distinction. If all
pointers
are “far” - segment plus offset - there’s no issue.
Yes, this helps, that’s why many Win16 coders used large model only.
Nevertheless, far pointers require segment register loads which are
slow.
Max
Segment register loads aren’t that slow, and are faster than many
things that routinely happen in our programs: for example, segment
loads are far faster than mispredicted branches. Segment loads are
also much faster than data movement: it’s much cheaper to pass a
segment selector around than to copy data from buffer to buffer. It’s
cheaper to handle discontiguous physical memory as a segment
than as an MDL. The only issue I have with the architecture is that
we only have four effective segment registers.
Alberto.
On 26 May 2002, at 19:36, Maxim S. Shatskih wrote:
> The evil is not “far” pointers. The evil is the distinction. If all
pointers
> are “far” - segment plus offset - there’s no issue.Yes, this helps, that’s why many Win16 coders used large model only.
Nevertheless, far pointers require segment register loads which are
slow.Max
You are currently subscribed to ntdev as: xxxxx@ieee.org
To unsubscribe send a blank email to %%email.unsub%%
Vewy scawy … heh heh heh …
“they” being a consortium of geeks with tape on their glasses, overdosed on
Twinkies and Mountain Dew, attempting to arrive at a consensus as to how to
best to do the next hack.
–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
“KJK::Hyperion” wrote in message news:xxxxx@ntdev…
>
> At 10.20 25/05/2002, you wrote:
> > > Linux supports more platforms (FreeBSD is pretty much x86-only), Linux
> > > supports multiple processors significantly better.
> >Linux’s SMP support with a giant kernel spinlock is abysmal,
>
> AFAIK, they plan to fix it (or maybe I’m thinking about the giant spinlock
> that serializes asynch I/O?) for the 2.5 release
>
>
>
And that would be different from (insert your choice of high tech
establishments here) exactly how :-?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
Sent: Tuesday, May 28, 2002 11:14 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Problem with arraysVewy scawy … heh heh heh …
“they” being a consortium of geeks with tape on their
glasses, overdosed on Twinkies and Mountain Dew, attempting
to arrive at a consensus as to how to best to do the next hack.–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net“KJK::Hyperion” wrote in message news:xxxxx@ntdev…
> >
> > At 10.20 25/05/2002, you wrote:
> > > > Linux supports more platforms (FreeBSD is pretty much
> x86-only),
> > > > Linux supports multiple processors significantly better.
> > >Linux’s SMP support with a giant kernel spinlock is abysmal,
> >
> > AFAIK, they plan to fix it (or maybe I’m thinking about the giant
> > spinlock that serializes asynch I/O?) for the 2.5 release
> >
> >
> >
>
>
>
> —
> You are currently subscribed to ntdev as:
> xxxxx@hollistech.com To unsubscribe send a blank email to
> %%email.unsub%%
>
Well true … but in an “ordered” environment you have a pointy haired
manager controlling the geeks …
–
Gary G. Little
xxxxx@broadstor.com
xxxxx@inland.net
“Mark Roddy” wrote in message news:xxxxx@ntdev…
>
> And that would be different from (insert your choice of high tech
> establishments here) exactly how :-?
>
> > -----Original Message-----
> > From: xxxxx@lists.osr.com
> > [mailto:xxxxx@lists.osr.com] On Behalf Of Gary G. Little
> > Sent: Tuesday, May 28, 2002 11:14 AM
> > To: NT Developers Interest List
> > Subject: [ntdev] Re: Problem with arrays
> >
> >
> > Vewy scawy … heh heh heh …
> >
> > “they” being a consortium of geeks with tape on their
> > glasses, overdosed on Twinkies and Mountain Dew, attempting
> > to arrive at a consensus as to how to best to do the next hack.
> >
> > –
> > Gary G. Little
> > xxxxx@broadstor.com
> > xxxxx@inland.net
> >
> > “KJK::Hyperion” wrote in message news:xxxxx@ntdev…
> > >
> > > At 10.20 25/05/2002, you wrote:
> > > > > Linux supports more platforms (FreeBSD is pretty much
> > x86-only),
> > > > > Linux supports multiple processors significantly better.
> > > >Linux’s SMP support with a giant kernel spinlock is abysmal,
> > >
> > > AFAIK, they plan to fix it (or maybe I’m thinking about the giant
> > > spinlock that serializes asynch I/O?) for the 2.5 release
> > >
> > >
> > >
> >
> >
> >
> > —
> > You are currently subscribed to ntdev as:
> > xxxxx@hollistech.com To unsubscribe send a blank email to
> > %%email.unsub%%
> >
>
>
>