**** BEGIN LOGGING AT Fri Feb 10 10:59:56 2006
Feb 10 12:21:43 <CIA-8> 03repvik * r259 10/releases/slugos-3.6-beta/openembedded/conf/distro/slugos.conf: slugos.conf: Change preferred kernel version, to get rid of warning message when building
Feb 10 14:06:02 <CIA-8> 03repvik * r260 10/releases/slugos-3.5-beta/: remove unreleased slugos-3.5-beta dir
Feb 10 16:09:14 <VoodooZ_Log> General programming question: how do I get a pointer to a malloc'ed block of memory to act like a 2 dimensional array my code (ie. array_ptr[y][x])? Would simple casting work or do I have to build it manually with seperatte malloc calls???
Feb 10 16:31:51 <kaenat> I'm trying to build ixp400 ixp400-net using nslu2 Makefile. I'm getting 'os/linux/include/platforms/ixp400/ixp425/IxOsalOsIxp425Sys.h:164: error: `IXP4XX_EXP_BUS_CS2_BASE_PHYS' undeclared here (not in a function)' http://pastebin.com/548467
Feb 10 16:34:20 <[g2]> kaenat hey
Feb 10 16:34:30 <kaenat> hi [g2] 
Feb 10 16:34:40 <[g2]> lucky guy you've got a 465 :)
Feb 10 16:34:55 <kaenat> yup
Feb 10 16:35:24 <[g2]> You're missing a define right :)
Feb 10 16:35:38 <kaenat> It appears so, yes :)
Feb 10 16:35:53 <kaenat> Any idea what it should be defined as?
Feb 10 16:36:11 <[g2]> The expansion bus changed from 16 to 32 bits between the 42x and 46x (maybe 45x too)
Feb 10 16:36:29 <kaenat> The 45x is the same family as 46x
Feb 10 16:39:09 <[g2]> I would guess you either haven't configured your kernel or your kernel source is pointing to the wrong place
Feb 10 16:41:21 <[g2]> or you didn't configure a 465 MACH
Feb 10 16:41:23 <kaenat> Ok. Perhaps the nslu2 kernel Makefile changed the config on me and I didn't notice it
Feb 10 16:42:16 <[g2]> any chance we coud get a dev board ?
Feb 10 16:42:30 <[g2]> or Inet access to one ?
Feb 10 16:42:31 <[g2]> :)
Feb 10 16:45:49 <kaenat> I only have the one board and I can't guarantee the state that that board will be in since I'm using it for development. sorry.
Feb 10 16:46:09 <[g2]> heh
Feb 10 16:46:15 <[g2]> I was 90% joking
Feb 10 16:46:32 <kaenat> I know :) but hoping heh
Feb 10 16:46:41 <VoodooZ_Log> hehehe I was starting to salivate too.
Feb 10 16:47:03 <[g2]> I'm sure he doesn't use the board at least 12 hours a day
Feb 10 16:47:17 <[g2]> and could leave us locked out when running tests
Feb 10 16:47:25 * [g2] digresses
Feb 10 16:47:30 <kaenat> [g2]: heh :)
Feb 10 16:48:42 <[g2]> can you say if it's a custom board or reference platform ?
Feb 10 16:49:23 <VoodooZ_Log> how fast! :)
Feb 10 16:50:22 <kaenat> It's Intel's reference board IXDP465 533Mhz (but can be bumped up to 667MHz I think)
Feb 10 16:50:42 <VoodooZ_Log> sweet!!
Feb 10 16:51:21 * VoodooZ_Log wonders how much more power hungry a 667Mhz 465 would be over his lowly slug...
Feb 10 16:52:22 <kaenat> It has a 20 pin ATX power connector with a 180 watt PS.
Feb 10 16:52:57 <VoodooZ_Log> ouch! 
Feb 10 16:53:13 <VoodooZ_Log> not exactly robot material then...
Feb 10 16:53:28 <kaenat> No. :)
Feb 10 16:53:42 <VoodooZ_Log> My next bot will need something fast but very power efficient.
Feb 10 16:53:57 <VoodooZ_Log> What would be the best intel chip for that? A pentium M?
Feb 10 16:54:06 <VoodooZ_Log> But I don't need a full portable.
Feb 10 16:54:59 <kaenat> don't know
Feb 10 16:55:07 <VoodooZ_Log> [g2], , is it possible to have C code treat a malloc'ed block of RAM as a 2 dimensional array?
Feb 10 16:56:17 <VoodooZ_Log> so my code could use ptr[y][x] for example.
Feb 10 16:57:38 <VoodooZ_Log> I've been using: int ** array; for now but i need to malloc once for collumn and x times per row. effectively manually building an array.
Feb 10 16:58:15 <VoodooZ> anyways, lunch time. 
Feb 10 17:00:03 <[g2]> VoodooZ I think 2 dimensional array are ordered by column but i'd have to check
Feb 10 17:00:33 <[g2]> kaenat I'm guesing you need the memory
Feb 10 17:00:40 <[g2]> or the network time stuff
Feb 10 17:08:37 <CIA-8> 03azummo * 10kernel/2.6.16/ (94-loft-setup.patch series): Ported loft support.
Feb 10 18:01:53 <VoodooZ> [g2], do you think just casting would do it or is it impossible?
Feb 10 18:02:36 <beewoolie-afk> VoodooZ: hey man
Feb 10 18:03:01 <VoodooZ> hey!
Feb 10 18:03:07 <VoodooZ> WHat's new?
Feb 10 18:03:20 <beewoolie-afk> tuns
Feb 10 18:03:28 <beewoolie-afk> I've been busy with JTAG code.
Feb 10 18:03:30 <VoodooZ> Thanks again for the apex help. It works great.
Feb 10 18:03:35 <beewoolie-afk> Excellent.
Feb 10 18:03:42 <VoodooZ> for the openjtag project you mean?
Feb 10 18:03:47 <beewoolie-afk> Yeah.
Feb 10 18:03:51 <VoodooZ> good stuff.
Feb 10 18:03:59 <beewoolie-afk> I've been working to rectify the data management problems.
Feb 10 18:04:20 <VoodooZ> must not be straightforward from what I know.
Feb 10 18:04:26 <beewoolie-afk> The code  I've seen tends to either code the drivers for each target
Feb 10 18:04:29 <beewoolie-afk> I don't want that.
Feb 10 18:04:37 <VoodooZ> yeah. 
Feb 10 18:04:55 <VoodooZ> not that I know anything about JTAG of course.
Feb 10 18:04:58 <beewoolie-afk> Yeah.  so I've developed a way to collect the information and allow targets to be described by a single file.
Feb 10 18:05:17 <VoodooZ> nice. Sounds like the perfect way to handle it.
Feb 10 18:05:36 <VoodooZ> abstraction is our friend. :)
Feb 10 18:07:47 <VoodooZ> you are a C guru: is it possible to have a malloc'ed block of RAM handled like a 2 dimensional array (ie: referenced as array[y][x]) ?
Feb 10 18:11:31 <beewoolie-afk> Yeah.
Feb 10 18:11:38 <VoodooZ> really? how?
Feb 10 18:11:44 <beewoolie-afk> As long as the type is correct.
Feb 10 18:11:46 <VoodooZ> I use to create an array manully.
Feb 10 18:12:01 <beewoolie-afk> The pointer type has to tell the compiler how long the row is.
Feb 10 18:12:05 <VoodooZ> I'm working on modifying a web cam driver.
Feb 10 18:12:10 <beewoolie-afk> There isn't really a need to do that, but you *can*.
Feb 10 18:12:24 <VoodooZ> and I want to make the array dimension runtime configureable.
Feb 10 18:12:37 <VoodooZ> (on module insertion)
Feb 10 18:12:53 <beewoolie-afk> typedef int image[640][480];
Feb 10 18:12:56 <VoodooZ> And I don't want to have to convert the existing code.
Feb 10 18:13:18 <VoodooZ> yeah but that wouldn't work at runtime.
Feb 10 18:13:25 <beewoolie-afk> image* rg = malloc...
Feb 10 18:13:28 <beewoolie-afk> Why not?
Feb 10 18:13:44 <beewoolie-afk> If you don't know the dimensions, then you have to do the math.
Feb 10 18:13:50 <VoodooZ> But you specified a static size??!
Feb 10 18:13:58 <beewoolie-afk> There isn't a performance penalty, so it doesn't really matter.
Feb 10 18:14:26 <beewoolie-afk> Either you tell the compiler at compile-time how long the rows are, or you compute it at runtime.
Feb 10 18:14:46 <beewoolie-afk> Perhaps if you were more specific about the problem.
Feb 10 18:15:03 <VoodooZ> well, it's definitely a runtime thing but I don't want to build an array manually. (with a bunch of malloc calls)
Feb 10 18:15:10 <VoodooZ> yeah. It's hard to explain.
Feb 10 18:15:25 <beewoolie-afk> You can malloc in one block.
Feb 10 18:15:31 <VoodooZ> ok.
Feb 10 18:15:32 <beewoolie-afk> int width; int height;
Feb 10 18:15:41 <beewoolie-afk> height = get_my_height ();
Feb 10 18:15:46 <beewoolie-afk> width = get_my_width ();
Feb 10 18:15:50 <VoodooZ> And I want my code to use that block as an array[][]
Feb 10 18:15:59 <beewoolie-afk> char* rgb = malloc (height*width);
Feb 10 18:16:15 <beewoolie-afk> Why do you care about the form?
Feb 10 18:16:46 <VoodooZ> ok. but would that let you access it via normal array references. ie: x = rgb[i][k]?
Feb 10 18:17:08 <beewoolie-afk> Why do you want to do that?
Feb 10 18:17:14 <beewoolie-afk> It's the same as...
Feb 10 18:17:15 <VoodooZ> Because I don't want to have to change the existing code to use pointer ref.
Feb 10 18:17:26 <beewoolie-afk> x = rgb[i*width + k];
Feb 10 18:17:46 <beewoolie-afk> So, the code has a fixed width?
Feb 10 18:17:57 <VoodooZ> believe me, I tried both and there was a big performance penalty.
Feb 10 18:18:04 <VoodooZ> no. both dynamic.
Feb 10 18:18:11 <beewoolie-afk> Shouldn't be.
Feb 10 18:18:18 <VoodooZ> specified with kernel module options.
Feb 10 18:18:19 <beewoolie-afk> There's something else wrong if that's the case.
Feb 10 18:18:30 <beewoolie-afk> You need to look at the machine code to determine why
Feb 10 18:18:49 <VoodooZ> well, for a bunch of nester loop for a 320x240 image it make  a huge difference when using pointers.
Feb 10 18:18:52 <beewoolie-afk> It's very hard to optimize properly since the x86 has so few registers.
Feb 10 18:19:05 <VoodooZ> That's on the slug though
Feb 10 18:19:17 <beewoolie-afk> Ah.  So, then it isn't registers.
Feb 10 18:19:25 <beewoolie-afk> Can you show me the code?
Feb 10 18:19:28 <beewoolie-afk> Pastebin?
Feb 10 18:19:33 <VoodooZ> never used it.
Feb 10 18:19:46 <beewoolie-afk> http://pastebin.ca/
Feb 10 18:20:00 <VoodooZ> Let me try to get organized first as the code is pretty big.
Feb 10 18:20:14 <beewoolie-afk> Just a snippet of the loop.
Feb 10 18:20:21 <beewoolie-afk> Or, you can point me to the source.
Feb 10 18:20:37 <VoodooZ> well, that particular example was from my CV lib which is a different case.
Feb 10 18:20:47 <VoodooZ> ....
Feb 10 18:21:30 <beewoolie-afk> There is nothing magic about using the [][] notation.
Feb 10 18:21:45 <beewoolie-afk> The ARM CPU is particularly efficient at indexed addressing.
Feb 10 18:21:48 <VoodooZ> true
Feb 10 18:22:04 <VoodooZ> I just have to find a good example...
Feb 10 18:22:16 <beewoolie-afk> So, it is possble that with enough registers, you get better performance with the [i*width + k] than with doing the math on the pointers themselves.
Feb 10 18:22:49 <VoodooZ> Actually, that's how I got around it. I built an array manually.
Feb 10 18:23:03 <beewoolie-afk> I don't know what you mean by 'manually'.
Feb 10 18:23:21 <VoodooZ> that's the hard part. I have to show you....
Feb 10 18:23:30 <kaenat> [g2]: A grep for IXP4XX_EXP_BUS_CS2_BASE_PHYS seems to show that it isn't defined anywhere: http://pastebin.com/548644
Feb 10 18:24:35 <beewoolie-afk> VoodooZ: you know where I am.
Feb 10 18:25:03 <VoodooZ> here it is: http://pastebin.ca/41024
Feb 10 18:25:19 <VoodooZ> That's how I currently handle my images in my cv lib.
Feb 10 18:25:25 <beewoolie-afk> Says it expired.
Feb 10 18:25:57 <VoodooZ> here it is: http://pastebin.ca/41028
Feb 10 18:26:32 <VoodooZ> does it work?
Feb 10 18:26:44 <VoodooZ> It's the first time I use it.
Feb 10 18:26:54 <VoodooZ> Funny as it's a Canadian site too. :)
Feb 10 18:27:37 <VoodooZ> beewoolie-afk, so in this example I "build" a 2 dimension array "manually" using a pointer to pointers...
Feb 10 18:27:40 <beewoolie-afk> yeah
Feb 10 18:27:43 <beewoolie-afk> Let me look at it.
Feb 10 18:27:44 <VoodooZ> I'd like to do it using a single malloc.
Feb 10 18:27:46 <VoodooZ> ok
Feb 10 18:28:02 <NAiL> woo :D
Feb 10 18:28:40 <beewoolie-afk> You can *always* use a single malloc, it just depends on how clever you want to be.
Feb 10 18:29:02 <NAiL> http://www.nslu2-linux.org/wiki/DS101/Kernel26Bootlog <-- My DS101 recognizes the HDD :-D
Feb 10 18:29:13 <beewoolie-afk> NAiL: Nice work.
Feb 10 18:29:23 <NAiL> no, dwery's nice work
Feb 10 18:29:24 <NAiL> :)
Feb 10 18:29:27 <beewoolie-afk> VoodooZ: So, you are using an array of pointers.  Is this important?
Feb 10 18:29:43 <VoodooZ> beewoolie-afk, ok. how clever? I'm ok with being clever once at init so I can simply use [][] later.
Feb 10 18:29:51 <VoodooZ> important?
Feb 10 18:30:09 <beewoolie-afk> I think you're missing the point.
Feb 10 18:30:12 <VoodooZ> yes, especially for vision 
Feb 10 18:30:17 <VoodooZ> probably! :)
Feb 10 18:30:20 <beewoolie-afk> It isn't the [][] operator that is significant.
Feb 10 18:30:25 <beewoolie-afk> It's the data structure.
Feb 10 18:30:31 <VoodooZ> yes.
Feb 10 18:30:52 <VoodooZ> I do understand that [][] and pointers are the same.
Feb 10 18:30:55 <beewoolie-afk> So, if that data structure is important, then there is an easy way to allocate the data in one go.
Feb 10 18:31:04 <beewoolie-afk> Actually, that isn't so.
Feb 10 18:31:19 <beewoolie-afk> You are using an array of pointers.
Feb 10 18:31:36 <beewoolie-afk> You *could* also define the array as being two dimensional and have the same notation.
Feb 10 18:31:48 <VoodooZ> as a makeshift array because some code from a vision book I got did it that way.
Feb 10 18:31:51 <beewoolie-afk> The operator doesn't uniquely describe the structure.
Feb 10 18:31:58 <beewoolie-afk> fine.
Feb 10 18:32:05 <beewoolie-afk> I'm not arguing the merit.
Feb 10 18:32:12 <beewoolie-afk> Only that it's important to know what the code means.
Feb 10 18:32:52 <VoodooZ> I don't know. that's why I'm confused. I only thought it was faster and convenient
Feb 10 18:33:05 <beewoolie-afk> So, all you have to do is allocate the bits in one go.  I'd do it this way.
Feb 10 18:33:58 <beewoolie-afk> void* pv = malloc (sizeof (struct image) + sizeof (void*)*nr + sizeof(PEL)*nr*nc);
Feb 10 18:34:38 <VoodooZ> ok. 
Feb 10 18:34:58 <VoodooZ> and would I be able to access it as pv[y][x]?
Feb 10 18:35:06 <beewoolie-afk> then, I'd change the data pointer to be immediate, unsigned char* data[].
Feb 10 18:35:14 <beewoolie-afk> Hang on.  :-)
Feb 10 18:35:19 <VoodooZ> ok.
Feb 10 18:35:29 <beewoolie-afk> You then fill the array with pointers to the bits that follow.
Feb 10 18:35:37 <beewoolie-afk> Just the way you do now.
Feb 10 18:35:51 <beewoolie-afk> Now, I could write all of the code for you....or I could let you experiment on your own.
Feb 10 18:36:17 * VoodooZ is trying to make his head stop spinning! :)
Feb 10 18:36:22 <beewoolie-afk> BTW, this is why some folks hate C.  You can do crazy things like this which are very efficient, and very easy to get wrong.
Feb 10 18:36:37 <beewoolie-afk> We are doing a little magic here.
Feb 10 18:36:41 <VoodooZ> well, in this case efficiency was key.
Feb 10 18:37:00 * VoodooZ thinks beewoolie-afk is a great magician!
Feb 10 18:37:11 <beewoolie-afk> We are taking advantage of a C construct where we define a data type, that has no size.
Feb 10 18:37:16 <beewoolie-afk> unsigned char* data[];
Feb 10 18:37:18 <VoodooZ> after all you did make Apex appear out of a hat!
Feb 10 18:37:25 <beewoolie-afk> It's an array of unknown length.
Feb 10 18:37:27 <beewoolie-afk> :-)
Feb 10 18:37:30 <VoodooZ> ok.
Feb 10 18:37:47 <beewoolie-afk> When we allocate memory for the structure, we make room for this array.
Feb 10 18:37:55 <beewoolie-afk> Then, we allocate more space for the bits to follow that.
Feb 10 18:38:15 <beewoolie-afk> The first pointer in the array will be...
Feb 10 18:39:01 <beewoolie-afk> image->data[0] = (unsigned char*) (((void*)(image + 1))*nr);
Feb 10 18:39:47 <beewoolie-afk> Here is a bit of C magic.  The image + 1 adds one struct image to the image pointer.
Feb 10 18:39:58 <beewoolie-afk> It makes it point to the byte that follows the structure.
Feb 10 18:40:11 <VoodooZ> So it's mostly the same method that I currently had. I still need to setup the pointers.
Feb 10 18:40:15 <beewoolie-afk> Then we cast to a generic pointer since that's the type of the array elements.
Feb 10 18:40:30 <beewoolie-afk> You cannot get around that if you want to use pointers.
Feb 10 18:40:39 <beewoolie-afk> There is no magic way to fill an array of pointers.
Feb 10 18:40:57 <beewoolie-afk> But, it does have one allocation which will improve performance.
Feb 10 18:41:27 <beewoolie-afk> BTW, never use the register keyword.
Feb 10 18:41:34 <VoodooZ> well, I don't care about the array of pointers much. It's just the only way I found to allow me to use the simpler [][] notation throughout my code.
Feb 10 18:41:41 <VoodooZ> really? oops.
Feb 10 18:41:46 <beewoolie-afk> it doesn't do anything and the compiler is way better than we are at making those decisions.
Feb 10 18:41:55 <beewoolie-afk> NO.
Feb 10 18:41:56 <VoodooZ> I did noticed quite a difference in some nested loops
Feb 10 18:41:59 <beewoolie-afk> This isn't about the notation.
Feb 10 18:42:24 <beewoolie-afk> The pointers may make things faster, but I bet I can write a loop that is faster without it.
Feb 10 18:42:42 <VoodooZ> sorry, It seems I'm not getting it. so perhaps I'll read the log later to get it in my head.
Feb 10 18:42:49 <beewoolie-afk> If you remove loop invariants, you can do the same thing without the brackets.
Feb 10 18:42:57 <beewoolie-afk> :-)
Feb 10 18:43:06 <beewoolie-afk> It really helps to read the machine code.
Feb 10 18:43:17 <beewoolie-afk> There is no other way to understand what is going on, unfortunately.
Feb 10 18:43:25 <VoodooZ> yeah. I've been putting off dealing with ARM code.
Feb 10 18:43:30 <beewoolie-afk> There is no such thing as a uniformly reliable optimization.
Feb 10 18:43:50 <beewoolie-afk> There was a good book on this called the Zen of Optimization.
Feb 10 18:43:57 <VoodooZ> well, in my lowly case I did some empirical testing on all cases and took the fastest.
Feb 10 18:44:06 <beewoolie-afk> I think it was mostly re-released as the Zen of Graphics Programming.
Feb 10 18:44:17 <beewoolie-afk> But you can do better if you know why.
Feb 10 18:44:19 <VoodooZ> I was reading the intel appnote on C optimization for ARM and I learned a lot. 
Feb 10 18:44:50 <beewoolie-afk> What does this inner loop look like?
Feb 10 18:45:16 <VoodooZ> Like unrolling my nested loops and removing redundant memory accesses with the use of a small bit cache. (which I use "register" on! :) )
Feb 10 18:45:46 <beewoolie-afk> Did you find that with and without the register keyword the performance was different?
Feb 10 18:46:01 <VoodooZ> well, it's basically a routine that rotates thru all pixels of an image on row at a time. and does some other stuff.
Feb 10 18:46:10 <VoodooZ> yes, in some cases.
Feb 10 18:46:23 <VoodooZ> but not as much as the placement of things.
Feb 10 18:46:25 <beewoolie-afk> The problem with the [i*nc + j] is that it does a multiply every time.
Feb 10 18:46:28 <beewoolie-afk> Very expensive.
Feb 10 18:46:30 <VoodooZ> yes!
Feb 10 18:46:38 <VoodooZ> That's the first thing I figured out.
Feb 10 18:46:43 <beewoolie-afk> You can get the improved performance by using a real pointer.
Feb 10 18:46:52 <VoodooZ> and thus why I started using the above array of * method.
Feb 10 18:47:02 <beewoolie-afk> But you have to setup that array.
Feb 10 18:47:14 <beewoolie-afk> Think of the array setup as a type of pre-computation.
Feb 10 18:47:16 <VoodooZ> It made a huge difference for a 320x240 image on my slug.
Feb 10 18:47:27 <beewoolie-afk> If you go through the array only once, there is no benefit to that method.
Feb 10 18:47:39 <VoodooZ> i see.
Feb 10 18:47:45 <beewoolie-afk> You are better off computing the pointer outside of the inner-most loop.
Feb 10 18:47:53 <VoodooZ> In this case, I do go through that array lots of times.
Feb 10 18:48:01 <VoodooZ> yep.
Feb 10 18:48:14 <beewoolie-afk> In that case, you are better off leaving the precomputed pointers in place.
Feb 10 18:48:24 <VoodooZ> that's what I did at first. Moved as much stuff outside the inner loop.
Feb 10 18:48:25 <beewoolie-afk> There are some other issues to consider.
Feb 10 18:48:45 <beewoolie-afk> When you use data to save time, you are also polluting the cache.
Feb 10 18:49:17 <VoodooZ> tradeoff.
Feb 10 18:49:20 <beewoolie-afk> I've seen cases where it is cheaper to compute at runtime than it is to use a table lookup.  It depends on the size of the cache and the size of the dataset. 
Feb 10 18:49:30 <VoodooZ> i see.
Feb 10 18:49:34 <beewoolie-afk> IN other words, no optimization is universal.
Feb 10 18:49:43 * VoodooZ nods
Feb 10 18:50:14 <VoodooZ> perhaps I'll reread your above comments to see how i can use them instead of my method.
Feb 10 18:50:17 <beewoolie-afk> Multiplies on the ARM aren't that slow.And, if you are going through the array in the same way every time, you can eliminate them altogether.
Feb 10 18:50:24 <VoodooZ> Thanks for taking the time.
Feb 10 18:50:41 <beewoolie-afk> Sure.  I've written an image viewer that has to deal with these sorts of issues.
Feb 10 18:50:58 <VoodooZ> well, for some opertaion like morphological operators (dilation & erosion) it's more involved. 
Feb 10 18:51:04 <beewoolie-afk> I never use precomputed pointers because I cannot afford the memory and there are easy ways to avoid it.
Feb 10 18:51:19 <VoodooZ> The routine has the scan the whole image and pass a small kernel over each location (3x3 or more)
Feb 10 18:51:34 <beewoolie-afk> If you need to refer to the previous row and stuff like that, you *may* be able to get rid of the pointers, too and make it faster.
Feb 10 18:52:13 <VoodooZ> if you have links to such examples that coudl be useful.
Feb 10 18:52:34 <beewoolie-afk> rgb[i-1] is the same as (rgb - nc)
Feb 10 18:52:43 <beewoolie-afk> Read, read, read.
Feb 10 18:52:44 <VoodooZ> I learn much faster by looking at actual code it seems.
Feb 10 18:52:49 <beewoolie-afk> I don't have anything specific.
Feb 10 18:53:09 <beewoolie-afk> It took about ten or 15 years of writing C before I stopped learning things.
Feb 10 18:53:15 <VoodooZ> yeah. unfortunately I happen to have too many hobbies. Oh and a girlfriend! :)
Feb 10 18:53:26 <NAiL> VoodooZ: Is she a robot? :-P
Feb 10 18:53:27 <beewoolie-afk> They're terrible for the hacking.
Feb 10 18:53:30 <VoodooZ> ouch. I still have a few years then.
Feb 10 18:53:41 <VoodooZ> hahahaha. No. that's another issue.
Feb 10 18:53:45 <NAiL> hehe
Feb 10 18:53:55 <beewoolie-afk> The last thing I learned, I still remember, it was a hack I read in some GNU code.
Feb 10 18:54:13 <VoodooZ> I've been playing like 3-4 hockey games a week lately which is damn good for the fitness but hard on my hobby time.
Feb 10 18:54:14 <beewoolie-afk> #define foo  do { something (); } while (0)
Feb 10 18:54:24 <VoodooZ> nice.
Feb 10 18:54:24 <beewoolie-afk> :-)
Feb 10 18:54:45 <beewoolie-afk> It used to be the only way to perform a block in a MACRO and know that it will always work.
Feb 10 18:54:53 <beewoolie-afk> There is a new syntax which is better.
Feb 10 18:55:07 <VoodooZ> a constantly evolving beast it is!
Feb 10 18:55:53 <beewoolie-afk> The references to the pointer array *could* be hurting you if you could do the same thing by simple math.
Feb 10 18:56:46 <VoodooZ> yeah but in the image processing case it seemed to be better.
Feb 10 18:57:24 <beewoolie-afk> There is a good part in the Zen Optimization book about the author and a pal talking about image processing.
Feb 10 18:57:30 <VoodooZ> doing vision on a small processor like the slug is not the best obviously so I had to squeeze as much as possible.
Feb 10 18:57:41 <beewoolie-afk> The pal brags that he can do a pel operation in 9 clock cycles.
Feb 10 18:57:49 * VoodooZ adds another book to his wishlist.
Feb 10 18:58:00 <beewoolie-afk> The author goes mad trying to figure out how he does it.
Feb 10 18:58:10 <beewoolie-afk> The old CGA standard is really screwy.
Feb 10 18:58:27 <VoodooZ> thank god I never had to deal with that.
Feb 10 18:58:31 <beewoolie-afk> He worked at it for a while and came up with a way to squeeze two more cycles from it.
Feb 10 18:58:48 <VoodooZ> impressive.
Feb 10 18:58:50 <beewoolie-afk> His point was that knowing that it is possible got him half way there.
Feb 10 18:59:15 <beewoolie-afk> His original code was much slower than what John Miles, the pal, did.
Feb 10 18:59:40 <beewoolie-afk> The authors name...is...Abrash.  Michael Abrash.
Feb 10 18:59:42 <VoodooZ> Miles? that rings a bell somehow
Feb 10 19:00:03 <beewoolie-afk> jJohn Miles wrote a sound system for PCs that was used in a lot of games.
Feb 10 19:00:03 <VoodooZ> could be a totally different guy though.
Feb 10 19:00:17 <beewoolie-afk> He's probably in his late forties by now.
Feb 10 19:00:21 <VoodooZ> cool! it is the same guy then! Miles positional audio!
Feb 10 19:00:35 <VoodooZ> Most new games have that software audio option.
Feb 10 19:00:45 <beewoolie-afk> Maybe he's still at it.
Feb 10 19:01:02 <VoodooZ> good to know a guru coded it. 
Feb 10 19:01:14 <beewoolie-afk> Yeah.  He's a good guy.
Feb 10 19:01:21 <VoodooZ> especially in the world of PC games where you can never get enough.
Feb 10 19:05:19 <NAiL> heh
Feb 10 19:05:25 <NAiL> Miles.. I still remember that
Feb 10 19:05:33 <NAiL> Brillant lad that ;)
Feb 10 19:09:18 <VoodooZ> here's the driver example I was refering too: http:pastebin.ca/41032
Feb 10 19:09:54 <VoodooZ> I'm trying to make the ibuf array adjustable at runtime.
Feb 10 19:10:21 <VoodooZ> the commented code in ibot_alloc() is my poor attempt.
Feb 10 19:11:00 <kaenat> [g2]: I got past my error with s@IXP4XX_EXP_BUS_CS2_BASE_PHYS@IXP4XX_EXP_BUS_BASE_PHYS@ in kernel/patches/ixp-osal/ixp4xx-header.patch
Feb 10 19:11:17 <kaenat> I can't believe that it actually works for nslu2
Feb 10 19:11:24 <kaenat> the way it is.
Feb 10 19:14:52 <[g2]> kaenat I don't think your asm/* was setup
Feb 10 19:15:44 <kaenat> [g2]: but I grep reveals that IXP4XX_EXP_BUS_CS2_BASE_PHYS doesn't exist anywhere in the kernel source tree --- for any arch
Feb 10 19:16:30 <kaenat> I doubt that that #define gets created on the fly
Feb 10 19:17:31 <[g2]> i think the ARCH=arm sets up the ARM info
Feb 10 19:17:44 <[g2]> and the defines are in the arm/asm tree
Feb 10 19:18:02 <kaenat> Yes. Could you do a grep for me and tell me where you find that #define.
Feb 10 19:18:15 <[g2]> it just told you where they were
Feb 10 19:20:13 <kaenat> All ARCH=arm does is setup some symlinks. A grep will search all arches not just the one you defined via the make invokation. Please do "grep -r IXP4XX_EXP_BUS_CS2_BASE_PHYS ." from the linux source tree for me.
Feb 10 19:21:26 <kaenat> If i had the wrong arch setup, then the grep should find this in the correct arch
Feb 10 19:23:01 <[g2]> look in include/asm/arch/platform.h
Feb 10 19:24:00 <[g2-lap]> include/asm/arch/platform.h:#define     IXP4XX_EXP_BUS_CSX_REGION_SIZE  (0x01000000)
Feb 10 19:24:00 <[g2-lap]> include/asm/arch/platform.h:#define IXP4XX_EXP_BUS_CS0_BASE_PHYS        (IXP4XX_EXP_BUS_BASE_PHYS + 0x00000000)
Feb 10 19:24:00 <[g2-lap]> include/asm/arch/platform.h:#define IXP4XX_EXP_BUS_CS1_BASE_PHYS        (IXP4XX_EXP_BUS_BASE_PHYS + 0x01000000)
Feb 10 19:24:00 <[g2-lap]> include/asm/arch/platform.h:#define IXP4XX_EXP_BUS_CS2_BASE_PHYS        (IXP4XX_EXP_BUS_BASE_PHYS + 0x02000000)
Feb 10 19:24:03 <[g2-lap]> i
Feb 10 19:24:23 <kaenat> [g2]: what is your current arch symlink pointing to?
Feb 10 19:24:58 <[g2]> I've got an arch directory
Feb 10 19:25:18 <kaenat> It's not a symlink?
Feb 10 19:25:24 <[g2]> nope
Feb 10 19:25:41 <[g2]> in the main kernel tree
Feb 10 19:26:15 <[g2-lap]> pwd
Feb 10 19:26:15 <[g2-lap]> /home/gs/dev/kernel/linux-2.6.15
Feb 10 19:26:15 <[g2-lap]> gs@gs:~/dev/kernel/linux-2.6.15$ file arch
Feb 10 19:26:15 <[g2-lap]> arch: directory
Feb 10 19:26:22 <kaenat> huh. That's weird. On mine, include/asm -> include/asm-arm and include/asm/arch -> include/asm/arch-ixp4xx
Feb 10 19:26:43 <[g2]> right that's in include
Feb 10 19:27:05 <kaenat> sorry, that's what I was refering to before.
Feb 10 19:27:18 <kaenat> what's your include/asm/arch symlinked to.
Feb 10 19:27:22 <[g2]> in include asm is a symlink to asm-arm
Feb 10 19:27:37 <[g2]> which was my point earlier
Feb 10 19:27:55 <kaenat> how about include/asm/arch though
Feb 10 19:28:03 <[g2]> I think that gets setup my the ARCH=arm when the config is done or the main build starts
Feb 10 19:28:30 <kaenat> Is include/asm/arch a symlink on your system?
Feb 10 19:28:30 <[g2]> arch-ixp4xx
Feb 10 19:28:39 <kaenat> ok, that's what I have.
Feb 10 19:29:01 <[g2]> what cross compiler etc... are you using ?
Feb 10 19:29:08 <[g2]> I've got to run
Feb 10 19:29:12 <[g2]> bbl
Feb 10 19:29:21 <kaenat> I'm using linux-2.6.16-rc2
Feb 10 19:29:27 <kaenat> ok. later.
Feb 10 19:31:35 <kaenat> Ok. I looked at a 2.6.15.2 source tree and it looks like thing got changed somewhere between then and 2.6.16-rc2.
Feb 10 19:33:00 <kaenat> include/asm-arm/arch-ixp4xx/platform.h is different and IXP4XX_EXP_BUS_CS*_BASE_PHYS no longer exists on 2.6.16-rc2
Feb 10 19:34:10 <dwery-away> kaenat: yes
Feb 10 19:34:29 <dwery-away> the latest nslu2 cvs repo fixes that 
Feb 10 19:35:00 <kaenat> must have just been fixed, cause I only did a cvs co this morning.
Feb 10 19:35:39 <dwery-away> probably
Feb 10 19:35:55 <dwery-away> i think I updated it a few hours ago :)
Feb 10 19:36:04 <kaenat> ok. thanks :)
Feb 10 19:40:48 <kaenat> dwery-away: What was changed to fix this? The kernel/patches/ixp-osal/ixp4xx-header.patch I just got from cvs is still using IXP4XX_EXP_BUS_CS2_BASE_PHYS
Feb 10 19:41:16 <dwery-away> uh, sorry. I thouth you were having a problem in another part of the kernel
Feb 10 19:41:23 <dwery-away> that bug still has to be fixed.
Feb 10 19:41:37 <kaenat> Oh.
Feb 10 19:41:53 <dwery-away> I think you can just grab the old defines
Feb 10 19:47:25 <kaenat> dwery-away: I think that by looking at the new platform.h, that the patch file should use IXP4XX_EXP_BUS_BASE(2)
Feb 10 19:48:06 <dwery-away> that's very probable
Feb 10 19:49:52 <kaenat> Is there a bugzilla db or the likes where I can put this info?
Feb 10 20:03:21 <dwery-away> don't think so, please write to the -dev mailing list
Feb 10 20:07:52 <kaenat> dwery-away: ok. will do. Here's a patch anyways: http://pastebin.com/548824
Feb 10 20:40:18 <[g2]> kaenat I've been running a trac server for a few days
Feb 10 20:40:27 <[g2]> I'll be putting it up on my site soon
Feb 10 20:40:35 <[g2]> then ppl can open tickets
Feb 10 20:40:43 <[g2]> it's just like madwifi.org
Feb 10 21:41:58 <kaenat> [g2]: Ok. I'm refining the patch file atm :)
Feb 10 21:45:58 <VoodooZ_Log> have a good weekend everybody!
Feb 10 21:46:07 <beewoolie-afk> VoodooZ_Log: later
Feb 10 21:46:31 <VoodooZ_Log> thanks for your help. I found my bug in the process.
Feb 10 22:30:05 <Shareman> evening'
Feb 10 22:31:35 <Shareman> we tried today to debootstrap debian on debianslug (as on howto but failing) ... someone with experience?
Feb 10 22:33:17 <Shareman> debootstrap (0.3.3, dist=sid) passes (no error), but in the chroot program apt-get is missing (also others) and /etc/network is missing too ... what's wrong?`
Feb 10 22:34:14 <NAiL> did you read the howto? It says how to create etc/network stuff
Feb 10 22:34:15 <Shareman> manually extracting package "apt.....deb" shows that apt-get was (would have been) inside
Feb 10 22:36:30 <Shareman> Hi Øyvind, yes - read it and did it first exactly this way ... trying other things too
Feb 10 22:45:16 <Shareman> NAiL: currently i'm trying to get files --download-only to execute each bootstrap stage separately ...
Feb 10 22:46:08 <Shareman> the thing is: debootstrap lists "Retrieving / Validating: apt" ...
Feb 10 22:46:55 <Shareman> but at minimum contents of this deb are not in the target directory (so apt-get is missing even with find)
Feb 10 23:31:54 <Shareman> strange - right now it works
Feb 11 03:00:18 <CIA-8> 03orepvik * 10kernel/2.6.16/ (7 files): Initial checkin of DS101 patches
Feb 11 10:14:29 <CIA-8> 03rwhitby * 10kernel/patches/ixp-osal/ixp4xx-header.patch: Added patch from kaenat.
Feb 11 10:30:32 <rwhitby> kaenat: ping
Feb 11 10:30:42 <CIA-8> 03rwhitby * 10kernel/patches/ixp-osal/ixp4xx-header.patch: Included version.h
Feb 11 10:44:50 <rwhitby> Hmm - IXP4XX_EXP_BUS_BASE is not static - it depends on ixp4xx_exp_bus_size (new in 2.6.16) which is configurable from ixp4xx_sys_init() startup code to either 16MB or 32MB.
Feb 11 10:45:07 <rwhitby> (this is in asm-arm/arch-ixp4xx/platform.h)
Feb 11 10:46:28 <rwhitby> Looks like it is always SZ_16M for ixp42x
Feb 11 10:46:45 <rwhitby> So we will need to hard-code that in the ixp module patches.
Feb 11 10:53:03 <CIA-8> 03rwhitby * 10kernel/patches/ixp-osal/ixp4xx-header.patch: Fixed the non-static definition.
**** ENDING LOGGING AT Sat Feb 11 10:59:56 2006