On Sun, Feb 24, 2002 at 10:01:15PM -0500, Gregor N. Purdy wrote:
> Nicholas --
>
> On Fri, 2002-02-22 at 19:23, Nicholas Clark wrote:
> > Do you have the benchmarking code handy?
> > [ie I'd like to see if what I'm thinking of comes anywhere near, on a
> > quantitative test. I might not have tui
Nicholas --
On Fri, 2002-02-22 at 19:23, Nicholas Clark wrote:
> On Fri, Feb 22, 2002 at 09:00:29AM -0500, Gregor N. Purdy wrote:
>
> > I'm not surprised that find_op() is causing some distress. The "best
> > way" is subject to interpretation, of course. TMTOWTDI all over again.
> > I chose this
On Fri, Feb 22, 2002 at 09:00:29AM -0500, Gregor N. Purdy wrote:
> I'm not surprised that find_op() is causing some distress. The "best
> way" is subject to interpretation, of course. TMTOWTDI all over again.
> I chose this way because whenever I started talking about op lookup
> by name, cries w
[not had time to read your whole message, about to go out]
On Fri, Feb 22, 2002 at 09:00:29AM -0500, Gregor N. Purdy wrote:
> Of course, thats all irrelevant if it doesn't compile. There are two
> ways out, from my perspective:
>
> (1) Split core.ops into multiple oplibs, with the *really* cor
Nicholas --
Apologies in advance. I set out to make a short answer, but it
turned out long. Since find_op() is related to other work I want
to do/see done, discussion of it brings 'round those other thoughts,
too.
Liquefaction Guaranteed.
[snip]
> Hmm. I bet a coffee the problem is static int
On Fri, 22 Feb 2002, Nicholas Clark wrote:
> There's nothing particularly unusual about my x86 FreeBSD 4.5 box, except
> maybe that it's a little old.
>
> It does compile and test perfectly on the defaults (no optimisation), and
> on -O. It's just -Os that goes nasty.
>
> OK, so the machine only
