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

[Jim Gettys]

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.com>
> To: dpreed at reed.com
> Subject: Re: Microsoft, please protect your stacks (was Re: [ih] ... stack?)
> Cc: ietf at ietf.org, internet-history at postel.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.dec.com