ietf
[Top] [All Lists]

Subject: Re: Microsoft, please protect your stacks (was Re: [ih] ...

2001-08-06 12:20:04
Few, if any graphics programs compile code and branch to it now: while
Rob Pike did this trick on the Blit, and we did it early in X's existance,
we did not continue this trick in X11.  And the code which does most rendering
is usually not in the user's address space.

I'd be surprised if Microsoft did either, these days.

It turns out on modern machines, we've recently experimentally determined that
in fact the limit is not instructions, but buss cycles.  Ergo, a couple
years ago Keith Packard rewrote the horrific X code for rendering, which
had been implementing Duff's algorithm in horrible macros, compiled
N times to generate efficient code (but still not generated code) with
small, compact code which pulls the raster operations tests into the inner
loop, thereby saving .5 megabytes of code space (and having simple, easy
to deal with code again).  The new compact code generally has better cache
behavior, and works as well or better than the old unrolled loops.

So I don't think this is an issue for almost anyone.  I could be wrong
in the Microsoft case, of course: some people do wierd things there.
                                    - Jim



Message: 1
Date: Fri, 3 Aug 2001 19:19:09 -0700 (PDT)
From: "James P. Salsman" <bovik(_at_)best(_dot_)com>
To: dpreed(_at_)reed(_dot_)com
Subject: Re: Microsoft, please protect your stacks (was Re: [ih] ... stack?)
Cc: ietf(_at_)ietf(_dot_)org, internet-history(_at_)postel(_dot_)org

David,

Thank you for your message which I guess started from the
internet-history list, not the ietf discussion list.

... Lots of programs compile code into a temporary buffer and then execute
it.  The most interesting ones that I know of are in graphics support,
where various bitblt's and other highly parameterized, highly loopy code
process a lot of data.

So, locking the stack against execution would slow graphics applications?
Maybe someone should let Intel know, since they are having a hard time
convincing consumers that 2 GHz > 1 GHz.  It is pathetic how audio
applications have been ignored.  Swaying my opinion would require a
different example.

Putting the temporary buffer on the stack is *good*
design, not bad - using a static buffer requires unnecesary locking, and
allocating with malloc() means handling the possibility of an "out of
memory" in a sensitive part of the system....

On the contrary, there is nothing wrong with a seperate code stack in its
own segment.

Cheers,
James

Jim Gettys
Technology and Corporate Development
Compaq Computer Corporation
jg(_at_)pa(_dot_)dec(_dot_)com



<Prev in Thread] Current Thread [Next in Thread>
  • Subject: Re: Microsoft, please protect your stacks (was Re: [ih] ..., Jim Gettys <=