On Tue, 2005-06-14 at 15:45 -0400, Michael Jennings wrote:
I don't know how I missed this one, sorry. I just performed a fresh
checkout and everything seems fine. I had tested it earlier with a cvs
up too though. I did 'try' and make a patch for the ./configure message
that might be an improvement but I didn't really know what I was doing.
I just glued some stuff together and guessed. I know there have been
issues with the autoFUCK stuff (as you so eloquently put it in the flame
fest) so just toss it if it's screwy.
> On Wednesday, 18 May 2005, at 01:10:13 (-0600),
> Tres Melton wrote:
>
> > The second patch I actually recommend that you do not apply. It
...
> > if(!((rm^0x100)|(gm^0x100)|(bm^0x100)))
Is there already a check for all 3 modifiers == 256 (as above) in
another function or are you just going to let it shade to the same color
(lots of CPU cycles but does nothing)?
> Both patches have been applied. I used a macro to maintain
> readability.
Nice and clean there.
> > If you would like, I would be willing to maintain the shading
> > routines. I don't know cvs well enough to commit anything but you
> > can bounce anything that gets submitted off of me and I'll double
> > check them; I feel pretty comfortable in that code now. I tried to
...
> As I do not have a P4 box or an x86_64 box, please test the latest CVS
> stuff to make sure nothing was merged incorrectly. Also, if you'd
> like to maintain the shading stuff, please do. :)
Everything's golden here. I read the devel list almost daily but if I
miss something you can send it to me directly (or tell someone else to)
and I'd be happy to deal with any of the shading code maintainence.
> > If you tell me where Eterm reads the background from e and sets its
> > initial geometry I'd also like to fix the problem of the pop-up
> > scrollbar taking up room when it is not active at startup. (I sent
> > you pics of the problem awhile back.)
>
> The initial window creation and sizing is done in windows.c in
> Create_Windows()
Thank, you. I'll look into the scrollbar issue when I get a chance.
> On Monday, 06 June 2005, at 11:28:28 (-0400),
> John Ellson wrote:
...
> > Tres indicated that adding "-mpreferred-stack-boundary=16" might
> > still be beneficial on x86_64, but that it might consume extra space
> > at run time. I'm not in a position to make that call, but if you
> > agree its a good idea I can probably make the configure.in change.
>
> Has anyone done any testing on this in terms of additional RSS being
> needed?
RSS? Resident Stack Size? No. How would I do that? From what I've
read though, it is almost always desirable to have the cache lines and
the stack base aligned. Do you know what the line size is on a Pentium
II/III/IV L1 cache? On x86-64 it is an invalid op to push anything
besides a 64 bit value (32 bit systems can push 8/16/32 bit values) so
the most that is lost there is a single element (aligned to 128 bits).
Where I'm still not clear, and not for a lack of research, is on the
possibility of forcing stack alignment on one file's functions and not
the entire programs. The -mpreferred-stack-boundary=?? wasn't added to
CFLAGS so right now we should be the same place we were. I'll look into
this when I finish the stuff in the next paragraph.
I've started porting the code to SSE & SSE2 for x86 and adding some
profiling code with some interesting results but I'm not in any hurry
here. Pre-populating the cache helped a lot and I'm playing with
temporal writes now. :) If I do submit something it will be cleaned up
and hopefully a single file for each arch (x86 supporting the best
option of MMX, SSE, & SSE2) and will have profiling numbers to justify
the patches. Possibly a single file for both archs. This is the first
code I ever did for SIMD and it was kinda fun. :-}
If you reply could you please start another thread as I forget to go
more than a week back in time all too often.
> Thanks,
> Michael
Thank you,
--
Tres
--- configure.in 2005-06-14 13:39:00.000000000 -0600
+++ configure.in.mine 2005-07-17 21:22:24.000000000 -0600
@@ -518,13 +518,19 @@
i*86)
grep mmx /proc/cpuinfo >/dev/null 2>&1 && HAVE_MMX="yes"
;;
+ x86_64)
+ HAVE_MMX_MESG="MMX unavailable on x86-64"
+ ;;
+ * )
+ HAVE_MMX_MESG="MMX not detected"
+ ;;
esac
])
if test "x$HAVE_MMX" = "xyes"; then
AC_MSG_RESULT([yes (32-bit)])
AC_DEFINE(HAVE_MMX, , [Define for 32-bit MMX support.])
else
- AC_MSG_RESULT([no (no MMX detected)])
+ AC_MSG_RESULT([no ($HAVE_MMX_MESG)])
fi
AM_CONDITIONAL(HAVE_MMX, test "x$HAVE_MMX" = "xyes")
