On Monday, 25 April 2005, at 19:06:16 (-0600), Tres Melton wrote: > This appears to work because it is an off by one error (one pixel = > 4 bytes). It will fail to adjust the top left pixel of the image > map and will go one pixel past the end of the image array at the > bottom right. This is a horrible patch and needs to be reverted > immediately. It should have no effect on my machine (an AMD64) > because it is little endian but it does. It also inverts the order > (to little endian) thus defeating the big endian concept.
You're right. I'll revert it shortly. > It is properly detecting AMD64 as little endian. What it is doing is > including /usr/include/libast/sysdefs.h and getting hosed in there. If > you look at a piece of sysdefs.h you will find: > > #ifndef WORDS_BIGENDIAN > # define WORDS_BIGENDIAN 0 > #endif > > but in the Eterm code it does things like #ifdef WORDS_BIGENDIAN. Well > WORDS_BIGENDIAN gets defined to a false value but we don't check for > that. We assume that if it is defined then it is true. This is the > heart of the problem. My question is this: Should we remove the code > chunk above from libast/sysdefs.h or should we alter the code in Eterm > to read something like: > > #if WORDS_BIGENDIAN > ---do something > #endif The correct solution, which I've just committed, is the latter. I changed the #ifdef's to #if's and put in a fallback in case someone is using an older LibAST. > Either solution will work but we must be consistent. What decision > will cause the least amount of aggravation? Does something in > libast require that macro to be defined? Yes, it's written to use #if WORDS_BIGENDIAN. > Sure, I can send a patch for that but I would like to straighten out > the endian-ness knot first as the two seem to be somewhat entangled. > If you prefer I will send a patch now but It will most likely have > to change once the endian-ness gets straightened out. Let me know > what you want MeJ. Please create any patches you send against current CVS. > Another issue that needs to get resolved in the ./configure script > is that it enables MMX on my AMD64. That's fine, I have MMX, but > the code in mmx_cmod.S is not compatible with a 64 bit chip. The > proper thing to do at the moment is to disable MMX on AMD64. Eterm > won't compile without doing that via "./configure --disable-mmx". > That should be automatic. There is also a HAVE_MMX macro that > enables/disables certain things. I propose adding a HAVE_MMX_64 > macro for using the MMX extensions on AMD64 (and EM64T). I agree. Do you have any suggestions for detecting x86_64 as opposed to i386? > I'm working on other things for Eterm right now including an MMX > port to AMD64. I have been in touch with, Willem-Jan Monsuwe > <[EMAIL PROTECTED]>, the original author of the code and it sounds > like he did it just for fun when MMX first came out and is no longer > interested in it. I sent a preliminary mmx_64_cmod.S file and hope > he looks it over. If I don't hear back from him or he doesn't want > to get involved I'll try and finish the port myself. It has been a > while since I've coded in Asm so it might take some time for me to > complete the port. No hurry, though I'm sure the folks on Opteron systems would love MMX support. :) > I have a few other patches that I would like to submit once we > untangle the knot that this endian-ness has caused so could someone > please tell me the best way to handle it: remove the #define from > libast or rewrite the Eterm code? I've received the patches you've sent so far. I'm going to get through them as quickly as I can, but my Real Job(tm) is keeping me pretty busy too, so please be patient. :) But keep the patches coming! Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <[EMAIL PROTECTED]> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "As your attorney, it is my duty to inform you that it is not important that you understand what I'm doing or why you're paying me so much money. What's important is that you continue to do so." -- Hunter S. Thompson's Attorney ------------------------------------------------------- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
