Re: TUX patches for Alpha

[Phillip Ezolt <ezolt perf zko dec com>]

Mingo,

> > 		a) Changed the i386 compile flags to alpha specific
> > 	           compile flags. (You might want to do it in a more
> >                  portable way.)
>
> yep, this change needs to be more portable.

I believe that I've seen other projects have something like the following:

# Uncomment for Alpha
# CFLAGS = -mcpu=ev56
# Uncomment for Intel
# CFLAGS = -mcpu=i686
CFLAGS =

> wonderful :-) This means that the core TUX code was 100% 64-bit clean out
> of box? If so then i'm proud =B-)

;-)

> log files and tux2w3c have some 32-bitness and endianness assumptions, but
> otherwise they should be fine.

We've begun to dig into this.  Is there any reason that you do all the
pointer aritmetic instead just inserting everything into a struct?

If the reason is performance, what's the penalty for using the
easier to read way (struct)?

> we'd prefer to have a single portable logfile format, so the current x86
> format should be the baseline. Can you see any problems with this
> approach?

This seems like the right approach.  We'll probably have to use something
like "u32" instead of "unsigned long"....  "long" means something different
on alpha and intel. ;-)


> the demo modules (and tux.c's module loading mechanizm) should work in
> theory, there are no known 64-bitness issues there.

demo1 works fine... Had some problems with the others, altough it could
be user error.

--Phil & Bill

Compaq:  High Performance Server Division/Benchmark Performance Engineering
---------------- Alpha, The Fastest Processor on Earth --------------------
Phillip.Ezolt@compaq.com        |C|O|M|P|A|Q|        ezolt@perf.zko.dec.com
------------------- See the results at www.spec.org -----------------------


> > 		a) Changed the i386 compile flags to alpha specific
> > 	           compile flags. (You might want to do it in a more
> >                  portable way.)
>
> yep, this change needs to be more portable.
>
> > 		b) Added Test & Set bit functions for Alpha.
>
> this change is looking good.
>
> > We have TUX serving static pages.
>
> wonderful :-) This means that the core TUX code was 100% 64-bit clean out
> of box? If so then i'm proud =B-)
>
> > (There still seems to be some issues with log files, and a few of the
> > demo.so files, but we are looking into that. )
>
> log files and tux2w3c have some 32-bitness and endianness assumptions, but
> otherwise they should be fine.
>
> we'd prefer to have a single portable logfile format, so the current x86
> format should be the baseline. Can you see any problems with this
> approach?
>
> the demo modules (and tux.c's module loading mechanizm) should work in
> theory, there are no known 64-bitness issues there.
>
> 	Ingo
>
>
>