| 00:12:01 | | Quit toffe82 (Read error: 110 (Connection timed out)) |
| 00:13:54 | *** | Saving seen data "./dancer.seen" |
| 00:17:54 | stripwax | saratoga - one other thing tremor does is use very few temporary variables - i'm pretty certain that, if you take the address of a temporary variable (as we do in all those TRANSFORM macros), gcc will definitely create that variable on-stack which limits being able to optimse it away / combine registers / etc |
| 00:20:50 | | Quit Zagor ("Leaving") |
| 00:20:52 | saratoga | stripwax: is tremor actually doing any better? |
| 00:20:56 | saratoga | looking at it i don't think so |
| 00:21:07 | saratoga | it uses fewer temporary variables, but it uses them over and over |
| 00:21:19 | saratoga | for example mdct_butterfly_16 |
| 00:22:04 | | Quit MethoS- (Read error: 104 (Connection reset by peer)) |
| 00:22:11 | | Quit Omlet^away ("( www.nnscript.com :: NoNameScript 4.22 :: www.esnation.com )") |
| 00:22:14 | saratoga | i think its basically the same as what we do |
| 00:22:30 | saratoga | and the solution on ARM for Tremor was to write those butterflies in asm |
| 00:23:07 | stripwax | I mean, tremor never takes the address (via &) of any of those temporary variables. So they can all be registers. |
| 00:23:27 | stripwax | Only the real memory writes go via & |
| 00:23:58 | stripwax | Maybe I shouldn't be using XPROD31/XNPROD31 in TRANSFORM macros.. |
| 00:24:34 | saratoga | does the ffmpeg one do that? |
| 00:29:02 | stripwax | ffmpeg doesn't use any macros for multiplying (doesn't need to, as no fixed point / asm to deal with, so it just has x = a*b , etc). But CMUL in ffmpeg doesn't take pointers as args, whereas our one for some reason does. CMUL and XNPROD31 basically do the same thing. |
| 00:29:35 | saratoga | thats probably my fault for CMUL |
| 00:29:54 | stripwax | So if the results are not intended for memory, would be better to use a macro that doesn't require pointers (e.g. something like XPROD32). |
| 00:30:36 | stripwax | I'll cook up a couple simple ones and see if it improves anything |
| 00:31:04 | | Quit Bagder ("It is time to say moo") |
| 00:31:11 | CIA-6 | New commit by tomers (r24137): FS #10886 - Hebrew glyphs for 08-Rockfont.bdf ... |
| 00:32:11 | | Join webguest10 [0] (n=4b3d35fd@giant.haxx.se) |
| 00:32:44 | | Quit webguest10 (Client Quit) |
| 00:33:35 | saratoga | ugh addr7, r0, #8 then ldr r3, [r7, #4] |
| 00:33:45 | saratoga | thats the same as just doing ldrr3, [r7, #12] right? |
| 00:34:31 | saratoga | err ldrr3, [r0, #4] |
| 00:34:40 | saratoga | err ldrr3, [r0, #12] |
| 00:34:49 | saratoga | what the hell is the compiler doing |
| 00:34:51 | stripwax | :) right unless you also (need to) reuse r7? |
| 00:35:15 | saratoga | it does not |
| 00:35:20 | stripwax | if they all look like that, then yeah, that sounds really crappy |
| 00:35:43 | saratoga | i see why doing these butterflies in ASM for Tremor speed things up so much |
| 00:35:54 | saratoga | gcc seems terribly confused by them |
| 00:42:47 | saratoga | how many registers can I actually use on ARM? r0 through r12 or can I use more? |
| 00:47:27 | stripwax | I think all but pc really |
| 00:48:34 | stripwax | r0 thru r4, and r12, are all scratch. everything else you should be able to save/restore on entry/exit. r15 is the pc. Oh, and stack pointer probably best left untouched too unless you're definitely not stacking/calling/doing anything.. |
| 00:49:17 | saratoga | so thats r0 through r13? |
| 00:49:24 | | Nick kramer3d is now known as kramkram (n=kramer@unaffiliated/kramer3d) |
| 00:51:31 | stripwax | sp is actually r13. so r0 thru 12, plus r14 (also called lr) |
| 00:51:53 | | Join opensrcguy [0] (n=dod@c-67-173-90-130.hsd1.in.comcast.net) |
| 00:51:59 | stripwax | again, provided you push/pop the ones that aren't {r0-r3,r12} before using them |
| 00:52:22 | saratoga | i'd forgotten how much i hate doing asm |
| 00:52:52 | opensrcguy | What is the SVN address for the RockBox SVN? I do not want to browse it with a web browser. I am using a real SVN client |
| 00:53:17 | stripwax | svn://svn.rockbox.org check the wiki pages for UsingSVN. |
| 00:55:07 | opensrcguy | hmm... I have tried that with no success |
| 00:55:20 | stripwax | check the wiki pages... |
| 00:56:05 | opensrcguy | thanks |
| 00:56:08 | opensrcguy | I will |
| 00:56:28 | saratoga | its annoying that ldm can't stride by two words at a time |
| 00:56:48 | opensrcguy | got it |
| 00:56:55 | | Join StealthyXIIGer [0] (n=stealthy@69.216.116.162) |
| 00:56:56 | opensrcguy | svn://svn.rockbox.org/rockbox/trunk |
| 00:57:10 | stripwax | opensrcguy - depends if you want trunk or not ;-) |
| 00:57:19 | opensrcguy | oh no |
| 00:57:26 | opensrcguy | I just want to start exploring there |
| 00:57:34 | opensrcguy | I am going to get the mini2440 port |
| 00:57:49 | stripwax | saratoga - yeah, .. but when/where do we need that? |
| 00:58:14 | saratoga | for butterflies, then i could load just the real parts in one stride |
| 00:58:25 | saratoga | since they're stored interleaved |
| 00:58:37 | stripwax | can't we just load them all (real+imag) in one go? |
| 00:59:24 | saratoga | yeah but i won't have enough registers to store them all, and all the results |
| 00:59:33 | saratoga | so i won't be able to use stm to write them back out |
| 01:00 |
| 01:03:01 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 01:03:48 | | Quit bmbl ("Bye!") |
| 01:04:07 | stripwax | saratoga - which piece of code are you looking at |
| 01:04:12 | saratoga | fft4 |
| 01:04:35 | stripwax | ah right |
| 01:04:47 | saratoga | i think the best i can do is one ldm and two seperate stm |
| 01:04:54 | saratoga | which isn't bad |
| 01:05:08 | saratoga | only wastes a few cycles due to lack of registers |
| 01:06:02 | stripwax | have you seen how mdct_arm.S does butterfly_8 ? |
| 01:06:41 | opensrcguy | Does anybody know about the port to the mini2440? It has an ARM9 processor |
| 01:06:57 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 01:07:09 | opensrcguy | in crt0.asm I see there is a call to map_section but I cannot find where that function is at |
| 01:07:12 | stripwax | You have 8 inputs and 8 outputs, but it should be possible to reuse some of your input registers for the output results (and the intermediate results also) |
| 01:07:32 | saratoga | stripwax: hmm let me see how they do it |
| 01:08:16 | saratoga | oh wow thats a lot smarter then I |
| 01:12:13 | stripwax | saratoga - there's an awful lot of embedded assumptions in that butterfly_8 code (due to it being very intricately inlined with the rest of the stuff in butterfly_16) - e.g. incrementing the address args directly, and not actually doing any register stacking at start/end of butterfly_8. but the core idea should be very reusable |
| 01:12:31 | saratoga | i don't think its quite the same thing as fft4 |
| 01:12:35 | stripwax | it's not |
| 01:12:48 | saratoga | but yeah i should be able to step through in similar order |
| 01:12:55 | stripwax | exactly |
| 01:13:10 | saratoga | its really stupid that i'm doing this, a computer would be so much better |
| 01:13:24 | stripwax | hah |
| 01:13:36 | stripwax | O2 / O3 definitely didn't do any better on that code? |
| 01:14:31 | saratoga | i've got them if you want to see |
| 01:14:35 | saratoga | well i didn't try O3 |
| 01:14:48 | | Nick dys`` is now known as dys (n=andreas@krlh-5f735275.pool.mediaWays.net) |
| 01:15:00 | | Quit bertrik ("De groeten") |
| 01:15:26 | saratoga | O2 is even longer then O1, which is ridiculous |
| 01:15:31 | saratoga | i don't know how it managed to add more ops |
| 01:15:36 | stripwax | isn't O2 supposed to be 'minimize size' ? |
| 01:15:54 | stripwax | or am i misremembering / thinking about vc++ |
| 01:16:18 | saratoga | thats Os |
| 01:17:56 | | Join kramer3d [0] (n=kramer@unaffiliated/kramer3d) |
| 01:19:05 | stripwax | wonder if that would play nicely. |
| 01:20:14 | saratoga | wow this is actually really easy and i just suck |
| 01:20:29 | saratoga | i have registers left over |
| 01:20:40 | stripwax | hahaha |
| 01:21:06 | saratoga | what is the point of rsb on arm? |
| 01:21:08 | stripwax | I'm wondering if it's possible to coax gcc to do almost-as-good-a-job as that somehow with some smallish code tweaks. it would be much better to *not* have to manually hand-tune the asm |
| 01:21:20 | saratoga | isn't it the same as sub with the operands flipped? |
| 01:21:21 | stripwax | saratoga - so you can still do tricks with the second operand |
| 01:21:30 | saratoga | oh for shifting? |
| 01:21:31 | stripwax | e.g. shifts |
| 01:21:32 | stripwax | yeah |
| 01:22:00 | saratoga | gcc uses it sometimes instead of sub without touching the second argument |
| 01:22:02 | saratoga | i wonder why |
| 01:23:42 | * | stripwax shrugs |
| 01:24:01 | | Quit opensrcguy () |
| 01:24:23 | stripwax | also second operand doesn't have to be a register, but first operand does |
| 01:24:25 | stripwax | I think |
| 01:24:33 | stripwax | e.g. rsb r0, r0, #0 |
| 01:25:14 | stripwax | ok. so with some tweaks, gcc seems to spit out something almost reasonably, with some ldmias in it |
| 01:25:21 | stripwax | no stmias unfortunately |
| 01:25:21 | | Quit kramkram (Read error: 60 (Operation timed out)) |
| 01:25:51 | stripwax | I'll try profiling it and see if it makes any/much difference |
| 01:27:42 | | Join jordan` [0] (n=jordan@78.235.252.137) |
| 01:31:17 | stripwax | not profiling. i mean just test_codec thing. |
| 01:33:24 | | Quit bmbl (Client Quit) |
| 01:36:36 | | Join Space [0] (i=quassel@r190-0-133-203.dialup.adsl.anteldata.net.uy) |
| 01:41:47 | | Quit Spaceghost (Read error: 60 (Operation timed out)) |
| 01:45:02 | | Nick Space is now known as Spaceghost (i=quassel@r190-0-133-203.dialup.adsl.anteldata.net.uy) |
| 01:53:01 | | Join MethoS- [0] (n=clemens@134.102.106.250) |
| 01:59:56 | | Quit domonoky1 (Read error: 54 (Connection reset by peer)) |
| 02:00 |
| 02:08:42 | saratoga | do i have to store all registers I touch ? |
| 02:08:58 | AstroBoi | only if you need them again |
| 02:09:53 | saratoga | in a function call that is |
| 02:10:17 | saratoga | stripwax: http://pastebin.com/m34619a34 |
| 02:10:21 | stripwax | or if you are being called from regular C, which will assume that you preserve anything in the range r4-r11+r13-r15 if you modify them |
| 02:11:05 | saratoga | so I only need to do stmdbsp!, {r4, r5, r6, r7, r8, r9, r10, r11}? |
| 02:11:43 | saratoga | and I guess I should try to use r14 then if its free |
| 02:11:57 | stripwax | {r4-r11,lr} |
| 02:12:13 | saratoga | which one is lr? |
| 02:12:14 | stripwax | assuming that you won't be modifying r13 (=sp) or r15 (=pc). lr=r14 |
| 02:12:27 | stripwax | = function return address |
| 02:12:29 | saratoga | i don't touch 14 |
| 02:12:46 | stripwax | ok, no need to stack it in that case |
| 02:12:57 | saratoga | i'll rearrange my registers to touch fewer important ones |
| 02:13:21 | saratoga | what happens to r1-r3 when you call? does the caller automatically stack them if it needs them? |
| 02:13:31 | saratoga | or does the compiler purposefully not use them around function calls |
| 02:13:57 | *** | Saving seen data "./dancer.seen" |
| 02:14:54 | stripwax | the compiler uses r0 thru r3 for function arguments (the first four arguments to the function). |
| 02:15:19 | stripwax | it assumes the function won't preserve their values, so if the caller needs to reuse the values after function returns, the caller will need to store them before calling |
| 02:15:23 | saratoga | http://pastebin.com/f50a4d7b8 |
| 02:16:04 | saratoga | 34 clocks when inlined assuming no memory latency |
| 02:17:19 | saratoga | gcc used 63 clocks |
| 02:17:25 | saratoga | so a factor of 2 improvement |
| 02:17:32 | stripwax | presumably fft16 would (=could) reuse some of those fft4 results without needing to store/reload ? |
| 02:17:40 | stripwax | I'm not sure how much benefit that would yield |
| 02:17:47 | stripwax | hey that's pretty good |
| 02:18:04 | stripwax | what's the performance on target like? |
| 02:18:07 | saratoga | no idea |
| 02:18:12 | saratoga | not even sure if its correct :) |
| 02:18:55 | saratoga | if I declare this inside a .S file can it still be inlined without stacking everything? |
| 02:19:13 | saratoga | or should I make it an asm block inside a c function? |
| 02:23:57 | Unhelpful | saratoga: you can't inline into C code from an asm function... and doing so with an asm block is going to work best if you declare any scratch registers as output of the block instead of using fixed registers and clobbers. |
| 02:24:29 | saratoga | Unhelpful: so just list r1-r12 as outputs? |
| 02:25:43 | Unhelpful | saratoga: well, you have to use temp variables in the surrounding C code, and then used them as outputs in the asm block, and use them in the asm instead of using specific clobbers. ie, "add %[tmp1] ..." |
| 02:26:04 | Unhelpful | that will allow registers in the asm block to be subject to compiler register allocation |
| 02:26:05 | saratoga | why is that better then clobbering? |
| 02:26:11 | saratoga | ah ok |
| 02:26:53 | Unhelpful | for example if you repeat a block twice that produces a single output value it will have more flexibility about where to save the output from the first copy, instead of just having to avoid all of the explicit clobbers |
| 02:30:31 | saratoga | Unhelpful: http://pastebin.com/m40eb175a |
| 02:30:38 | saratoga | is that what you mean? |
| 02:32:06 | Unhelpful | ah, heh, well if you're going to use ldm you *have* to use explicit registers for whatever it touches, since ldm must be in-order... |
| 02:33:04 | saratoga | so just clobber them? |
| 02:33:08 | stripwax | yep |
| 02:33:39 | stripwax | is it possible to have asm that has no 'output' registers? |
| 02:33:48 | stripwax | the only output of this is really memory |
| 02:34:50 | saratoga | i keep getting an impossible constraint error |
| 02:34:58 | saratoga | am i doing the input correctly? |
| 02:35:00 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 02:35:21 | | Join Strife89 [0] (n=michael@adsl-154-14-235.mcn.bellsouth.net) |
| 02:36:23 | stripwax | shouldn't it be just "r" ? |
| 02:37:01 | saratoga | instead of a? |
| 02:37:24 | stripwax | yeah, I think so. what is "a" ? |
| 02:37:49 | saratoga | i don't know |
| 02:37:51 | stripwax | heh |
| 02:37:57 | saratoga | am i not allowed to ahve comments in an asm block? |
| 02:38:00 | saratoga | its erroring on those now |
| 02:38:06 | stripwax | also, shouldn't you refer to it as %[r0] or something? rather than r0. |
| 02:38:36 | Unhelpful | saratoga: i usually just use C comments... |
| 02:39:20 | stripwax | should be C comments. you also need ; ends for each asm line - looks like you're missing ; from some lines (or are you using ; as a comment?) |
| 02:39:40 | Unhelpful | and i wouldn't bother with the temps-as-outputs if you already *have to* use explicit clobbers due to ldm/stm |
| 02:39:41 | stripwax | take a look at lib/asm_arm.h for examples |
| 02:41:00 | stripwax | also - you don't need "cc" clobber here. there's no condition code flags on those instructions. |
| 02:43:17 | saratoga | i don't think i need semi colons |
| 02:44:46 | saratoga | http://pastebin.com/m20527f49 |
| 02:44:58 | saratoga | the assembler is not happy |
| 02:45:08 | stripwax | how would it know where the instruction ends, if you don't have semicolons? |
| 02:45:36 | stripwax | remember, this is going through the C preprocessor. all those strings just get concatenated into one long string |
| 02:45:46 | saratoga | it needs new lines |
| 02:46:09 | stripwax | see asm_arm.h - I don't think you *need* newlines (e.g. vect_add) |
| 02:46:38 | stripwax | at a guess, you need either one of semicolons or newlines, I suppose |
| 02:47:36 | stripwax | you still need to use "%[r0]" in the asm, not just "r0" though. |
| 02:47:40 | Unhelpful | stripwax: anything the assembler will accept as ending a statement... |
| 02:47:51 | stripwax | good point |
| 02:48:12 | Unhelpful | stripwax: um... why would he need to use %[r0] unless that refers to a named input or output variable? |
| 02:48:23 | stripwax | - because it does? |
| 02:48:41 | Unhelpful | oh, it does? that's confusing :) |
| 02:48:56 | saratoga | data aborts |
| 02:49:04 | saratoga | i bet i have the ldm instructions wrong |
| 02:49:10 | stripwax | could set the inputs to be [z] "r" (z), instead of [r0] "r" (z), if it's less confusing |
| 02:49:38 | Unhelpful | r1-r8 should just be clobbers because of the ldm. and for the address you do indeed need to use the named parameter. |
| 02:49:39 | stripwax | saratoga - is that with the r0 fix? Otherwise, I think the r0 register is basically not going to be assigned to z |
| 02:49:50 | saratoga | ah |
| 02:50:09 | stripwax | so you're blatting over random memory locations probably :) |
| 02:50:12 | saratoga | so " : %[r0] "r" (z)" ? |
| 02:50:46 | saratoga | hmm no |
| 02:50:49 | stripwax | no |
| 02:51:05 | stripwax | i.e. ldmia %[r0], blah |
| 02:51:16 | saratoga | oh you mean for ldm |
| 02:51:30 | stripwax | or to make it less confusing- ldmia %[z], blah (and have [z] "r" (z) in the inputs section) |
| 02:52:16 | stripwax | Unhelpful - he needs to clobber r9-r12 too. Or are you saying those four should really be local temp variables and have the compiler assign those? |
| 02:52:26 | saratoga | http://pastebin.com/m79fe8df9 |
| 02:56:17 | saratoga | still no good |
| 02:57:39 | stripwax | still aborts? |
| 02:58:45 | saratoga | yeah |
| 02:59:45 | Unhelpful | stripwax: he could. i'm really not sure it will help any, but it might. |
| 03:00 |
| 03:00:19 | Unhelpful | isn't there a way to specify a specific range of memory as clobbered or as an output? |
| 03:00:28 | stripwax | I don't think so |
| 03:00:44 | saratoga | why would that be needed |
| 03:01:57 | Unhelpful | saratoga: if gcc might have any values live in registers it should know it needs to reload them... in most cases it doesn't really matter. |
| 03:02:33 | saratoga | isn't that what the memory clobber handles? |
| 03:02:39 | saratoga | or did you mean just to be more specific |
| 03:02:52 | Unhelpful | "If you know how large the accessed memory is, you can add it as input or output but if this is not known, you should add `memory'. As an example, if you access ten bytes of a string, you can use a memory input like: " |
| 03:03:08 | Unhelpful | saratoga: a memory clobber will force reloads of *anything* from memory |
| 03:03:28 | saratoga | looking at vector_fmul_reverse it lists everything as an output, and its a very similar function (writes ldm mul then stm) |
| 03:03:31 | saratoga | maybe i need to do that |
| 03:03:56 | stripwax | Yeah but that one updates the address pointer |
| 03:04:22 | stripwax | i.e. it returns the incremented pointer |
| 03:04:22 | saratoga | oh hmm |
| 03:04:39 | Unhelpful | saratoga: the pointer need not be an output if not updated. and clobbers are as good as outputs if you are using specific registers anyway, as you must with ldm/stm |
| 03:04:42 | | Quit kramer3d ("Leaving") |
| 03:05:04 | saratoga | am i using ldmia wrong then? |
| 03:05:21 | stripwax | I don't think so |
| 03:05:49 | saratoga | haha that fixed it |
| 03:05:55 | Unhelpful | there's an example here for how to clobber, input, or output a particular memory range: http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Extended-Asm.html#Extended-Asm |
| 03:06:03 | saratoga | although the audio is a little corrupted, so i obviously have a mistake somewhere |
| 03:07:38 | saratoga | 31.98MHz |
| 03:09:46 | stripwax | interesting. "you will want to add the volatile keyword if the memory affected is not listed in the inputs or outputs of the asm". but [z] is already in your inputs. So I wonder if you needed to put it into the outputs too and/or use "asm volatile" instead of "asm", in order for the "memory" clobber to work properly |
| 03:09:50 | stripwax | 31.98 for 192kbps? |
| 03:10:51 | saratoga | stripwax: yes 192k vorbis |
| 03:11:25 | stripwax | so about 1MHz improvement |
| 03:11:36 | stripwax | not bad!! |
| 03:11:38 | saratoga | yeah |
| 03:12:27 | saratoga | we'd get a lot more fixing hte other BFs too |
| 03:13:42 | stripwax | for the add/sub stuff, sure - but can only use the ldmia/stmia trick for fft4 |
| 03:13:46 | Unhelpful | saratoga: you're only using ldmia wrong if you are also incrementing the pointer in C and not using the pre-increment value outside of the asm. if only the asm modifies each bit of memory and the pointer is only needed in C for loop boundaries you can make the stm update the pointer for you (assuming the next memory to access follows this piece |
| 03:14:24 | saratoga | Unhelpful: the poitner doesn't change at all |
| 03:14:27 | stripwax | the asm isn't incrementing the pointer |
| 03:14:47 | saratoga | stripwax: i think it'll work in fft8 |
| 03:15:11 | stripwax | unhelpful - and it couldn't/shouldn't (not easily) because the value would need to be reused after the asm (not a simple loop) |
| 03:15:32 | Unhelpful | saratoga: then you're probably doing it right. if you were applying the same asm to consecutive blocks of memory you could declare the pointer an input/output and update it on the stm. |
| 03:15:39 | saratoga | although probably not as well since it'll probably run out of registers |
| 03:16:07 | saratoga | but still an extra stm or two is just 1 or 2 clocks wasted, still massive room for imrpvoement |
| 03:16:58 | stripwax | saratoga - right, it would require some extra careful rewriting by hand :) but I imagine a big benefit by writing fft8 by hand to *not* store all the fft4 results to memory [only store z[1] & z[3] immediately after fft4, because all the others need to be reused before writing] |
| 03:17:15 | saratoga | heres the almost working version if anyone wants to check my math: http://pastebin.com/m620017fb |
| 03:17:22 | saratoga | i need to stop doing this for a while before i lose my mind |
| 03:17:42 | stripwax | Probably need to just expand the equations in fft8 and do it all (again) by hand |
| 03:17:51 | stripwax | Right - don't want anyone to lose their mind over this! |
| 03:20:16 | stripwax | maths looks right btw |
| 03:21:15 | | Quit stripwax ("http://miranda-im.org") |
| 03:22:59 | | Quit DerPapst ("Leaving.") |
| 03:43:29 | | Join Phyber0ptik [0] (n=quassel@adsl-065-013-002-216.sip.asm.bellsouth.net) |
| 03:52:09 | Unhelpful | what a cliché, i figured out what is probably the best way to handle 32-bit inputs with my 31-bit divider while *in the shower*. could only have been worse if i'd been taking a bath or said "eureka" :P |
| 03:53:26 | | Quit Phyber0ptik (Remote closed the connection) |
| 03:57:55 | | Join kramer3d [0] (n=kramer@unaffiliated/kramer3d) |
| 04:00 |
| 04:00:28 | | Quit tchan ("WeeChat 0.3.1-dev") |
| 04:09:30 | | Join tchan [0] (n=tchan@lunar-linux/developer/tchan) |
| 04:14:01 | *** | Saving seen data "./dancer.seen" |
| 04:18:59 | | Quit Strife89 ("Bed.") |
| 04:41:29 | | Quit efyx (Remote closed the connection) |
| 04:47:01 | | Join kkurbjun [0] (n=kkurbjun@rockbox/developer/kkurbjun) |
| 04:47:27 | | Quit froggyman (Read error: 104 (Connection reset by peer)) |
| 04:48:44 | | Join Barahir [0] (n=jonathan@gssn-5f756448.pool.mediaWays.net) |
| 04:49:13 | CIA-6 | New commit by kkurbjun (r24138): Brickmania: Scale bitmaps with the high-res bricks to fit them to the LCD width for the Gigabeat F/X/S. |
| 04:51:17 | | Quit CaptainKewl (Read error: 104 (Connection reset by peer)) |
| 05:00 |
| 05:00:05 | CIA-6 | New commit by kkurbjun (r24139): Fix red. |
| 05:02:19 | | Join dys` [0] (n=andreas@krlh-5f735ec1.pool.mediaWays.net) |
| 05:04:15 | | Quit Sajber^1 (Read error: 54 (Connection reset by peer)) |
| 05:04:22 | | Quit Barahir_ (Read error: 110 (Connection timed out)) |
| 05:06:51 | | Join CaptainKewl [0] (n=jason@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 05:14:20 | | Quit dys (No route to host) |
| 05:21:14 | | Part toffe82_ |
| 05:34:36 | | Join Llorean [0] (n=DarkkOne@conr-adsl-dhcp-64-92-0-211.consolidated.net) |
| 05:51:07 | | Join BHSPitLappy [0] (n=BHSPitLa@unaffiliated/bhspitmonkey) |
| 05:51:33 | CIA-6 | New commit by kkurbjun (r24140): Brickmania: Change the drawing/collision detection to simplify position management. |
| 05:54:57 | | Quit GeekShadow ("The cake is a lie !") |
| 05:57:02 | saratoga | running time is wrong on targets with software USB because its only updated if you go into charging mode, not USB |
| 06:00 |
| 06:01:40 | saratoga | hmm actually it looks like you actually need to browse to the menu while its actively charging to reset it |
| 06:04:19 | saratoga | is touching the global_status struct from /firmware ok? |
| 06:04:39 | saratoga | it seems like the obvious solution is to just have the usb hardware update the running time counter on insert |
| 06:10:13 | | Quit MethoS- (Remote closed the connection) |
| 06:11:57 | | Quit fdinel ("Miranda IM! Smaller, Faster, Easier. http://miranda-im.org") |
| 06:11:58 | saratoga | imo the power_thread should be managing the running time, not screen.c |
| 06:14:04 | *** | Saving seen data "./dancer.seen" |
| 06:18:13 | | Join StealthyXIIGer [0] (n=stealthy@69.216.116.162) |
| 06:24:31 | | Join draeath [0] (n=pbransfo@unaffiliated/draeath) |
| 06:25:27 | draeath | I've got an e200r. I just recently updated to svn, and i find that when I connect USB, rockbox connects in MTP mode. I'd rather this not happen. I want it to behave like USB storage, or just reboot like it used to, letting the stock firmware handle it (which is configured for mass storage mode) |
| 06:25:56 | saratoga | rockbox doesn't have MTP mode, so if you're getting MTP you're in the OF |
| 06:26:02 | draeath | I'd check again |
| 06:26:26 | draeath | It does. it had a nice little rockbox splash too |
| 06:26:55 | draeath | (specifically stated MTP, and rhythmbox started up and behaved like an MTP player connected) |
| 06:28:05 | saratoga | you're probably confusing MSC with MTP |
| 06:28:51 | saratoga | rockbox has an MSC usb mode where it shows up as a normal usb disk, but not MTP (which is where you don't have direct access to the disk) |
| 06:29:39 | draeath | I plugged in just now, shows a USB connector and says "Multimedia Mode" ? |
| 06:29:55 | saratoga | that would be MSC |
| 06:30:17 | draeath | Hrm, but then hal or whatever is saying i connected a media player, rather than behaving like any random flash drive. |
| 06:30:27 | draeath | but i do see /dev/sdd is available, so yea |
| 06:31:42 | saratoga | assuming thats linux, you might have this problem: http://www.rockbox.org/wiki/LibGphoto2Bug |
| 06:32:20 | draeath | nah it reads it correctly. just wasn't expecting it to be treated "Special" now. |
| 06:32:24 | draeath | ok well nevermind then :) |
| 06:33:11 | draeath | Do you happen to know if it charges in this mode, or do I still need the OF for that? |
| 06:33:59 | saratoga | it charges |
| 06:34:57 | draeath | ty saratoga |
| 06:45:20 | | Quit Llorean ("Leaving.") |
| 06:45:30 | | Quit saratoga ("Page closed") |
| 07:00 |
| 07:01:40 | | Quit kkurbjun ("Leaving.") |
| 07:02:46 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 07:15:17 | | Part draeath |
| 07:18:33 | | Join Llorean [0] (n=DarkkOne@76.202.17.167) |
| 07:25:21 | | Join Llorean1 [0] (n=DarkkOne@adsl-76-202-17-167.dsl.hstntx.sbcglobal.net) |
| 07:32:38 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 07:42:08 | | Part S_a_i_n_t |
| 07:42:23 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 07:42:58 | | Quit Llorean (Read error: 110 (Connection timed out)) |
| 07:48:09 | | Quit S_a_i_n_t ("[St.] S_a_i_n_t st.lascivious@slingshot.co.nz") |
| 07:58:20 | | Join kcj1993 [0] (n=kcj1993@ip-118-90-94-99.xdsl.xnet.co.nz) |
| 07:59:50 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 08:00 |
| 08:02:53 | | Join AndyI [0] (n=pasha_in@212.14.205.32) |
| 08:04:20 | | Part S_a_i_n_t |
| 08:04:32 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 08:05:27 | | Quit S_a_i_n_t ("[St.] S_a_i_n_t st.lascivious@slingshot.co.nz") |
| 08:05:45 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 08:14:07 | *** | Saving seen data "./dancer.seen" |
| 08:14:27 | | Part kcj1993 ("Leaving") |
| 08:14:37 | | Quit CaptainKewl (Remote closed the connection) |
| 08:16:48 | | Quit AndyIL (Read error: 110 (Connection timed out)) |
| 08:24:43 | | Nick kramer3d is now known as kramkram (n=kramer@unaffiliated/kramer3d) |
| 09:00 |
| 09:00:08 | | Quit SolarWar (Read error: 110 (Connection timed out)) |
| 09:14:06 | | Quit Xerion (Read error: 60 (Operation timed out)) |
| 09:15:17 | | Join PaulJam [0] (n=Paule@p54BECA44.dip.t-dialin.net) |
| 09:21:22 | | Quit Spaceghost (Client Quit) |
| 09:42:18 | | Join Tomis2 [0] (n=Tomis@70.134.65.110) |
| 09:43:14 | | Quit kaniini (Read error: 60 (Operation timed out)) |
| 09:56:36 | | Join stoffel [0] (n=quassel@p57B4DBB1.dip.t-dialin.net) |
| 09:57:23 | | Quit PaulJam (Read error: 60 (Operation timed out)) |
| 09:57:49 | | Quit Tomis (Read error: 110 (Connection timed out)) |
| 09:57:49 | | Nick Tomis2 is now known as Tomis (n=Tomis@70.134.65.110) |
| 10:00 |
| 10:06:37 | | Quit xavieran (Client Quit) |
| 10:08:54 | | Join bmbl [0] (n=Miranda@unaffiliated/bmbl) |
| 10:14:10 | *** | Saving seen data "./dancer.seen" |
| 10:41:45 | | Quit BHSPitLappy (Read error: 110 (Connection timed out)) |
| 10:41:45 | | Join xavieran [0] (n=xavieran@ppp118-209-14-172.lns20.mel4.internode.on.net) |
| 10:42:45 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 10:43:31 | | Join bertrik [0] (n=bertrik@ip117-49-211-87.adsl2.static.versatel.nl) |
| 10:45:40 | | Join pamaury [0] (n=pamaury@ALyon-551-1-5-153.w92-137.abo.wanadoo.fr) |
| 10:48:02 | | Join merbanan [0] (n=banan@c-83-233-52-241.cust.bredband2.com) |
| 10:50:52 | | Join Grahack [0] (n=Grahack@stc92-1-82-227-106-100.fbx.proxad.net) |
| 10:53:45 | | Quit AstroBoi (Remote closed the connection) |
| 11:00 |
| 11:09:36 | bertrik | FlynDice, I'm seeing some weird sd debug code in debug-as3525.c: on line 298 we do sd_enable(true) and on line 303 we do sd_enable(false) again |
| 11:14:32 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 11:35:11 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 11:36:52 | | Join PaulJam [0] (n=Paule@p54BECA44.dip.t-dialin.net) |
| 11:44:39 | | Quit PaulJam (Nick collision from services.) |
| 11:44:48 | | Join PaulJam_ [0] (n=Paule@p54BECA44.dip.t-dialin.net) |
| 11:51:11 | | Nick dys` is now known as dys (n=andreas@krlh-5f735ec1.pool.mediaWays.net) |
| 11:51:20 | | Quit merbanan (Connection timed out) |
| 12:00 |
| 12:01:27 | | Quit kramkram ("Leaving") |
| 12:08:49 | | Join Sajber^ [0] (n=Sajber@h-142-12.A213.priv.bahnhof.se) |
| 12:14:14 | *** | Saving seen data "./dancer.seen" |
| 12:31:25 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 12:40:01 | | Quit yosafbridge ("Coyote finally caught me") |
| 12:40:11 | | Join yosafbridge [0] (n=yosafbri@li14-39.members.linode.com) |
| 12:42:07 | | Quit stripwax ("http://miranda-im.org") |
| 12:44:25 | | Join stripwax [0] (n=Miranda@87-194-34-169.bethere.co.uk) |
| 12:49:54 | | Quit Grahack ("Tu m'as vu ?") |
| 12:58:41 | | Join DerPapst [0] (n=DerPapst@91-64-221-175-dynip.superkabel.de) |
| 13:00 |
| 13:04:42 | | Nick rhodan__ is now known as rhodan (n=quassel@198-111.106-92.cust.bluewin.ch) |
| 13:09:15 | | Quit stripwax ("http://miranda-im.org") |
| 13:10:30 | | Quit tomers (Read error: 113 (No route to host)) |
| 13:12:25 | | Part S_a_i_n_t |
| 13:13:07 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 13:53:47 | | Join Omlet^away [0] (i=omlet05@240.186-240-81.adsl-dyn.isp.belgacom.be) |
| 13:59:12 | | Join kaniini [0] (n=kaniini6@dyn75-70.yok.fi) |
| 14:00 |
| 14:07:07 | | Join Xerion [0] (i=xerion@82-170-197-160.ip.telfort.nl) |
| 14:07:28 | | Join rhodan_ [0] (n=quassel@198-111.106-92.cust.bluewin.ch) |
| 14:11:08 | | Join dfkt [0] (i=dfkt@unaffiliated/dfkt) |
| 14:14:15 | *** | Saving seen data "./dancer.seen" |
| 14:19:32 | | Quit rhodan (Read error: 113 (No route to host)) |
| 14:23:40 | | Join GeekShadow [0] (n=Antoine@reactos/tester/GeekShadow) |
| 14:29:48 | | Join efyx [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 14:31:49 | CIA-6 | New commit by torne (r24141): Add strlcat to core to match strlcpy (also add to plugin api). Some uses of strcat could probably do with being changed to this. |
| 14:33:00 | Unhelpful | ape_normal runs faster without the divisor-is-2^n test... it's about .47MHz faster on e200. i wonder how often the divisor-is-one test hits... |
| 14:34:36 | | Quit stoffel (Read error: 60 (Operation timed out)) |
| 14:41:40 | | Quit kugel (Read error: 60 (Operation timed out)) |
| 14:58:40 | | Quit Omlet^away (Read error: 104 (Connection reset by peer)) |
| 15:00 |
| 15:08:20 | Unhelpful | removing special-cases for both x/1 and x/(2^N) from udiv_arm gets APE down a bit further, to 81.82MHz. the num<den case might be worth removing as well |
| 15:10:52 | | Join merbanan [0] (n=banan@c-83-233-52-241.cust.bredband2.com) |
| 15:16:18 | bertrik | Unhelpful, so it actually gets faster by removing 'optimisations'? |
| 15:20:54 | | Join kugel [0] (n=kugel@rockbox/developer/kugel) |
| 15:22:47 | | Part S_a_i_n_t |
| 15:23:02 | | Join BdN3504 [0] (n=5ce226a7@giant.haxx.se) |
| 15:23:27 | Torne | hm, what's the best way to handle conditional compilation of plugins that are very big? |
| 15:23:52 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 15:24:02 | BdN3504 | i have a problem finding a patch which solved my problem i already described here: http://www.rockbox.org/irc/log-20090927#14:24:22 |
| 15:24:29 | Torne | frotz currently needs 0xf630 bytes in pluginbuf which is too big for the archos targets, and it's likely to get bigger and not fit in the targets with 0x10000 either |
| 15:25:02 | bertrik | Torne, I think in apps/plugins/SOURCES |
| 15:25:31 | Torne | yes, but if i do it conditionally on PLUGIN_BUFFER_SIZE then i'm not sure how to put it in the manual |
| 15:25:43 | Torne | since the manual only knows about large_plugin_buffer which is much bigger (the one added for Lua) |
| 15:26:15 | bertrik | I don't know |
| 15:26:24 | BdN3504 | bertrik: you helped me then, could you help me now? |
| 15:27:30 | | Join Bagder [241] (n=daniel@rockbox/developer/bagder) |
| 15:27:57 | bertrik | BdN3504, I have to go now, maybe in an hour or so |
| 15:29:16 | BdN3504 | thanks |
| 15:31:22 | | Join CaptainKewl [0] (n=jason@207-237-117-89.c3-0.80w-ubr2.nyr-80w.ny.cable.rcn.com) |
| 15:31:28 | Unhelpful | Torne: why not build it as an overlay plugin on small-buffer targets? |
| 15:31:49 | Torne | because i don't know what that is |
| 15:31:59 | Torne | also if the plugin buffer is that small then there probably isn't enough ram to function usefully |
| 15:32:02 | Unhelpful | bertrik: well, they're both very rare cases if you assume that the numerator and divisor are randomly selected from all possible values |
| 15:32:11 | Torne | frotz steals the remainder of the plugin buffer to load the story file,a nd if that's not enough it steals the audio buffer |
| 15:32:17 | Torne | stories can be up to 512KB |
| 15:33:08 | Torne | hm actually |
| 15:33:11 | gevaerts | Torne: just revive the old bit-rotted low-mem code! |
| 15:33:37 | Unhelpful | Torne: overlays load into the audio buffer. you'd have almost the whole plugin buffer for data and the remainder of the audio buffer after the plugin loads into it. pictureflow builds as an overlay plugin on lowmem targets... this works great on archos since it uses the plugin buffer for the slide cache |
| 15:33:40 | Torne | i dunno if i can even find it :) |
| 15:33:49 | Torne | the swapping code is gone entirely :0 |
| 15:34:01 | Torne | Unhelpful: ah right |
| 15:34:25 | Torne | the story has to be contiguous so if the plugin buffer is less then 64kb then i probably can't fit the story in there either |
| 15:34:50 | Unhelpful | Torne: so just grab the audio buffer if you're using an overlay? you've already stopped playback... |
| 15:35:10 | Torne | yes, i just need to make sure not to overwrite myself as the comments say |
| 15:35:26 | Torne | didn't realise there was already a way to do this easily :) |
| 15:35:36 | Torne | i guess frotz can run on everything then, except the charcell devices |
| 15:36:04 | gevaerts | if you do overwrite yourself, someone will make use of that to write a bootloader |
| 15:36:10 | Torne | haha |
| 15:36:22 | Unhelpful | bertrik: also some of the special cases are probably *very* unlikely in the context of a range coder. i doubt divisors are exactly one or exactly powers of two very frequently. |
| 15:37:36 | Torne | gevaerts: actually using the low-memory version of the frotz code would be worse, because it's the interpreter binary that's too big for ram, not the story :) |
| 15:37:41 | Torne | the story should always fit in the audio buffer |
| 15:37:53 | Torne | the low memory version of the terp would be more code |
| 15:38:06 | gevaerts | hm, true |
| 15:38:32 | Torne | frotz is nearly done |
| 15:39:13 | Torne | undo is the only major thing left that doesn't work (expects malloc) |
| 15:39:28 | kugel | so use malloc |
| 15:39:31 | Unhelpful | as i'm *also* planning to replace libgcc's divider, some of these special cases might be worth keeping there... but possibly not, saving (numerator size * 2) + 15 cycles, roughly, in the case of divisor == 1, is probably not worth 2 cycles in the common case... |
| 15:39:38 | | Quit merbanan (Read error: 110 (Connection timed out)) |
| 15:39:38 | Torne | kugel: naw, not worth it |
| 15:39:41 | kugel | plugins and codecs actually have it |
| 15:39:52 | Unhelpful | undo is for sissies ;) |
| 15:39:52 | Torne | kugel: it only allocates and frees in a fixed sequence, the undos are a ring buffer |
| 15:40:10 | Torne | i can write a much more trivial implementation which will work |
| 15:40:24 | Torne | Unhelpful: indeed |
| 15:40:48 | Torne | Unhelpful: but there are interesting abuses of the save_undo opcode which might be nice to support |
| 15:40:57 | Torne | e.g. using it to do backtracking decision making ;) |
| 15:41:32 | Torne | since it basically saves a delta of all the writable memory of the VM, you can use it for control flow a la setjmp if you are insane |
| 15:41:34 | Unhelpful | this divider can alos process numerator<divisor in probably about 20 cycles, so that might not be a worthwhile optimization either... although, with uniformly distributed inputs it should happen about half the time. |
| 15:42:14 | Unhelpful | Torne: using it to backtrack in the story code, you mean? scary, sounds like an abuse. :P |
| 15:42:16 | gevaerts | Torne: people actually do that? |
| 15:42:22 | Torne | people do a lot of z-machine abuses |
| 15:42:41 | * | gevaerts can't help being impressed |
| 15:42:45 | Torne | Unhelpful: yes. it restores *all* state other than the return value of save_undo so it's even more drastic than setjmp/longjmp |
| 15:42:53 | Torne | you can only communicate one bit of information through it |
| 15:43:30 | gevaerts | One bit should be enough for everyone! |
| 15:43:32 | Torne | but you can abuse it to avoid having an unbounded return stack for some insane algorithms |
| 15:43:38 | * | Unhelpful bets that's also a "can't-happen" case for ape :P |
| 15:43:57 | Torne | or at least to make the unbounded amount smaller |
| 15:44:18 | Torne | you might do this if you were, say, implementing prolog |
| 15:44:32 | Unhelpful | implementing prolog. in z-machine. |
| 15:44:35 | Torne | or whatever other insane project you've come up with this month for your 80s virtual machine architecture |
| 15:49:47 | * | Torne wonders if anyone else wants to write a manual for frotz for him :) |
| 15:50:17 | Torne | also, i was thinking about plugins leaking filehandles. Might it be worth doing something to prevent this? |
| 15:50:31 | Unhelpful | removing these three "optimizations" is worth about 1.23MHz on e200 |
| 15:50:40 | | Join Omlet [0] (i=omlet05@240.186-240-81.adsl-dyn.isp.belgacom.be) |
| 15:50:55 | | Join arohtar [0] (n=faemir@78.33.109.163) |
| 15:52:20 | * | Torne also grumbles about frotz wanting ungetc |
| 15:53:10 | Unhelpful | hrm, this divider also appears to return 1 if the divisor exceeds numerator... that seems unright. :P |
| 15:56:04 | | Quit faemir (Read error: 60 (Operation timed out)) |
| 16:00 |
| 16:05:26 | bertrik | BdN3504, what is your question? |
| 16:05:36 | | Join BeFalou [0] (n=mamutoi@unaffiliated/befalou) |
| 16:12:13 | | Join stoffel [0] (n=quassel@p57B4DBB1.dip.t-dialin.net) |
| 16:12:23 | gevaerts | Torne: preventing that shouldn't be too hard with some open() and close() wrappers in plugin.c. I'm not sure if just closing all remaining open files is that useful though, maybe a panic is better... |
| 16:13:58 | gevaerts | on the other hand, there's plenty of precedent for autoclosing any remaining handles |
| 16:14:16 | *** | Saving seen data "./dancer.seen" |
| 16:14:17 | gevaerts | tsrs might need some special handling |
| 16:14:22 | pamaury | A panic is better because when a plugins leak filehandles, it is BAD, it should be fixed. I'm not sure adding some code to prevent it is a good way to tackle the problem. |
| 16:14:22 | Unhelpful | gevaerts: the open call might be in core code (say, opening an image by filename) |
| 16:15:05 | Unhelpful | does core track number of open handles? you could check those before and after starting the plugin... |
| 16:15:22 | CIA-6 | New commit by unhelpful (r24142): Remove special cases from udiv32_armv4.S, except for zero divisor and large numerator. Improvement of 1.23MHz on e200 with ape normal. |
| 16:15:23 | pamaury | no but it easy to count |
| 16:15:40 | gevaerts | not good enough. Other things might open files while the plugin is running |
| 16:15:43 | bertrik | I'd rather see a panic than some mechanism to autoclose |
| 16:15:57 | pamaury | I agree, that would be too complicated and error-prone |
| 16:16:37 | gevaerts | I don't think it would be that complicated |
| 16:16:57 | bertrik | we could increment a counter for each successfully opened file and decrement it for each successful close in the plugin api, and check that it is 0 at plugin exit |
| 16:16:58 | pamaury | Hum, how would you know if the open is done from a plugin or not ? |
| 16:17:25 | pamaury | That would mean adding code for each function in the plugin api that could possibly open a file |
| 16:17:36 | gevaerts | pamaury: plugins go through rb->, so you can easily add a wrapper |
| 16:18:06 | Unhelpful | pamaury: i think only for ones that pass a file back. if a core function leaves a file open that's not a plugin bug... |
| 16:18:06 | gevaerts | but yes, the problem is those less obvious functions |
| 16:20:12 | * | gevaerts agrees |
| 16:20:50 | pamaury | Which functions can lead to an unclosed open/opendir ? There are open, opendir of course and then ? |
| 16:21:15 | gevaerts | unless you get something else back that you have to release, but I'm not sure if there are any functions like that |
| 16:22:20 | pamaury | What about functions that play a sound ? How is it handled ? The buffering code handles that ? |
| 16:24:38 | BdN3504 | bertrik: hi, i described my problem here http://www.rockbox.org/irc/log-20090927#14:24:22 and you posted a patch to pastebin. i idiotically didn't keep a copy of that patch |
| 16:24:50 | kugel | Unhelpful: is that udiv32 faster than the gcc div routine? if yes, why don't we use it in the core also? |
| 16:25:14 | BdN3504 | what it does: it disables the play button and assigns the rec button the play button function |
| 16:25:15 | gevaerts | you can either control the playlist, in which case the core handles it, or play raw samples, in which case you're not passing file handles |
| 16:25:36 | CIA-6 | New commit by unhelpful (r24143): Add missing EOF newline. |
| 16:25:45 | Unhelpful | kugel: that's next :P |
| 16:25:54 | pamaury | gevaerts: what about bufopen/bufclose. I have no knownledge of audio code |
| 16:26:09 | gevaerts | hm, no idea |
| 16:27:22 | bertrik | BdN3504, I still had this patch locally, I think it's the same as the one discussed earlier: http://pastebin.ca/1735100 |
| 16:28:09 | BdN3504 | nice!!! thanks a lot! |
| 16:28:42 | kugel | Unhelpful: wasn't the div routines the only reason that we link libgcc? |
| 16:29:09 | gevaerts | pamaury: no plugin actually calls them |
| 16:29:36 | pamaury | ok, so only open and opendir seem to be concerned |
| 16:30:06 | | Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 16:30:51 | | Quit jae ("Lost terminal") |
| 16:31:05 | gevaerts | what I would do is keep open files in a bitmap |
| 16:31:41 | gevaerts | More reliable than just a counter in case of multiple close() calls |
| 16:32:27 | pamaury | you mean creating a bitmap was_opended_by_plugin such that was_opended_by_plugin[fd]=true iff fd is still open and the open was called by a plugin |
| 16:33:16 | gevaerts | yes, except that I'd just use one unsigned int |
| 16:33:19 | pamaury | (array or bitmap, implementation detail) |
| 16:34:08 | pamaury | That's seem easy and much more reliable than a counter of course. A counter is not sufficient anyway |
| 16:34:21 | gevaerts | if you do it that way close-on-exit is a trivial extension |
| 16:34:29 | pamaury | Yes |
| 16:34:53 | pamaury | We could close on exit and warn the user or panic or I don't know but the user you know to give feedback |
| 16:35:04 | pamaury | *should know |
| 16:35:43 | bertrik | how do you know which bit to set in the bitmap? |
| 16:36:12 | pamaury | with the fd |
| 16:36:27 | pamaury | (with the return value of open) |
| 16:36:46 | bertrik | can we guarantee limits on the range of the fd? |
| 16:37:16 | gevaerts | sure, that's the maximum number of open files, currently 8 |
| 16:37:30 | pamaury | 11 |
| 16:37:41 | gevaerts | ah, ok |
| 16:37:43 | bertrik | oh, ok only 8 or 11 files currently, didn't know that |
| 16:37:53 | pamaury | That's quite a limitation |
| 16:38:20 | pamaury | That's a good reason we fight against un-closed handles |
| 16:38:22 | pamaury | *to |
| 16:38:26 | gevaerts | You could do an array of unsigned ints, and some preprocessor magic to make it all work for >3w |
| 16:38:31 | gevaerts | *32 |
| 16:39:07 | gevaerts | or just an #error if it's set too high... |
| 16:39:23 | bertrik | I like that idea |
| 16:39:27 | pamaury | an #error is probably sufficient for now |
| 16:39:59 | * | kugel thinks a counter is sufficient |
| 16:40:04 | gevaerts | or a #warning and disable the guard |
| 16:40:23 | pamaury | kugel: a counter can't be sufficient |
| 16:40:45 | kugel | because the plugin needs to be fixed anyway, there's no need for closing leaked fds |
| 16:41:06 | pamaury | no I mean, it's not a reliable way to determine if it leaked or not |
| 16:41:09 | gevaerts | kugel: it's counter++ vs bitmap|(1<<fd), not that much difference |
| 16:41:41 | pamaury | what if another part of code opens a handle ? Say mtp for example, because you can do other things at the same time |
| 16:41:49 | | Quit BdN3504 ("CGI:IRC") |
| 16:41:53 | | Join bluebrother [0] (n=dom@rockbox/developer/bluebrother) |
| 16:42:22 | kugel | I thought only open() in plugins count |
| 16:42:29 | gevaerts | pamaury: it would presumably still be in a plugin wrapper |
| 16:43:07 | pamaury | ah yes |
| 16:43:31 | pamaury | a bitmap uses the same space and we have free close on exit |
| 16:43:38 | * | gevaerts thinks that the extra cost of a bitmap over a counter is small enough to go for the bitmap |
| 16:43:42 | kugel | gevaerts: except that bitmap|(1<<fd) is quite limited |
| 16:43:56 | kugel | doesn't really matter unless we were to up the limit |
| 16:43:57 | gevaerts | kugel: in what way? |
| 16:44:13 | gevaerts | we're at one third of the limit now |
| 16:45:12 | bertrik | I think a mechanism like this would be useful in the core too |
| 16:45:38 | | Join rhodan [0] (n=quassel@88-40.3-85.cust.bluewin.ch) |
| 16:45:44 | gevaerts | the bitmap will (or at least can) catch double close, while those would just break a counter |
| 16:46:07 | gevaerts | bertrik: it would, but it's a lot harder there I think |
| 16:46:55 | bertrik | gevaerts, I don't see why (yet) |
| 16:47:02 | gevaerts | There's no real point at which you know the expected state |
| 16:47:50 | gevaerts | and it's a lot harder to know where an open or close is called from |
| 16:48:02 | bertrik | ah yes of course |
| 16:48:18 | bertrik | it could catch a double close, but that's about it |
| 16:49:09 | | Quit rhodan_ (Read error: 60 (Operation timed out)) |
| 16:49:32 | gevaerts | you could make a debug screen that shows which files are open, and which thread opened them |
| 16:51:12 | pamaury | How do you know the thread ? |
| 16:51:21 | pamaury | (that would mean adding code ?) |
| 16:52:14 | gevaerts | it's extra code, yes |
| 16:52:33 | pamaury | only for debug build, if I understand |
| 16:52:35 | pamaury | ? |
| 16:52:59 | gevaerts | probably |
| 16:53:21 | gevaerts | you could do it for all builds, but that seems a bit wasteful |
| 16:53:44 | pamaury | indeed |
| 16:54:04 | kugel | did anyone ever do a debug build? |
| 16:54:14 | pamaury | debug build=build with debug menu for me |
| 16:54:24 | pamaury | :) |
| 16:54:27 | kugel | that's the normal build |
| 16:54:42 | pamaury | yes but I didn't want to write the entire sentence |
| 16:55:14 | kugel | I mean if you say "only for debug build" you still mean all builds :) |
| 16:55:33 | | Quit efyx (Remote closed the connection) |
| 16:57:21 | pamaury | ???? |
| 16:58:21 | kugel | the debug menu is in all builds |
| 16:59:07 | pamaury | really ? I thought it was only an option (configure asks for it) |
| 16:59:35 | gevaerts | the menu is always there |
| 16:59:46 | pamaury | but not accessible ? |
| 16:59:54 | gevaerts | it is |
| 17:00 |
| 17:00:51 | bertrik | a debug build for the sansa clip doesn't compile here, I'll try to make it work (and commit the changes later) |
| 17:01:46 | | Join efyx [0] (n=efyx@lap34-1-82-225-185-146.fbx.proxad.net) |
| 17:02:34 | pamaury | We could have a very special build which do stack-trace each time open is called to see where it leak ;) |
| 17:02:36 | kugel | funman seems to have success |
| 17:03:32 | CIA-6 | New commit by bertrik (r24144): Simplify some boolean expressions that compare directly against 'true' |
| 17:04:15 | | Quit dys (Read error: 104 (Connection reset by peer)) |
| 17:04:32 | | Join dys [0] (n=andreas@krlh-5f735ec1.pool.mediaWays.net) |
| 17:05:16 | bertrik | kugel, cool |
| 17:09:25 | kugel | let's hope his patch also works on the e200v2 |
| 17:09:41 | kugel | mc2739: ping :) |
| 17:10:27 | kugel | mc2739: have you seen funman's latest patch? |
| 17:11:11 | mc2739 | kugel: yes, I'll test when I get back in about 30 minutes |
| 17:11:18 | kugel | nice |
| 17:12:36 | pamaury | gevaerts: so, we go for this bitmap solution ? I can implement that if there's no objection |
| 17:13:38 | gevaerts | pamaury: I'd go for that one, yes |
| 17:14:06 | pamaury | Ok, I'll do that today if I have time or tomorrow, that's shouldn't be long |
| 17:14:24 | gevaerts | I might have a go now... |
| 17:14:48 | pamaury | ok, do so |
| 17:16:58 | | Quit arohtar (Read error: 60 (Operation timed out)) |
| 17:17:01 | * | pamaury thinks is still have a dircache bug to fix but delay the day when he will have to dive into it... |
| 17:18:09 | | Join evilnick [0] (i=457288ab@rockbox/staff/evilnick) |
| 17:18:53 | | Quit dys (Read error: 104 (Connection reset by peer)) |
| 17:19:11 | | Join dys [0] (n=andreas@krlh-5f735ec1.pool.mediaWays.net) |
| 17:27:47 | bertrik | we have a lot of source files without svn:keywords |
| 17:31:05 | | Quit dys (Read error: 104 (Connection reset by peer)) |
| 17:40:36 | | Join Highlander [0] (n=Highland@mek33-4-82-236-45-205.fbx.proxad.net) |
| 17:42:39 | | Quit PaulJam_ (Read error: 110 (Connection timed out)) |
| 17:47:06 | gevaerts | OK, I've added FS #10889 |
| 17:49:15 | pamaury | gevaerts: seem ok to me but I'll test it. Are you sure logf on exit is sufficient ? It a silent error |
| 17:49:17 | pamaury | *'s |
| 17:49:44 | gevaerts | pamaury: I know. I think we need a bit more discussion to know what exactly to do when detecting the issue |
| 17:50:11 | pamaury | yes, did you test it with a crappy plugin to check ? |
| 17:50:43 | pamaury | (also perhaps printing the leaked files is a good thing to help debugging on error) |
| 17:50:44 | gevaerts | I didn't test it at all :) |
| 17:50:51 | pamaury | ok |
| 17:51:07 | | Join hebz0rl [0] (n=hebz0rl@dslb-088-065-054-141.pools.arcor-ip.net) |
| 17:51:15 | bertrik | do we have a function to splash a text and wait for confirmation? |
| 17:51:52 | pamaury | I'm not sure but does plugins.c defines [insert here the #define that redirect logf to _logf and not to void)] so you're logf message is not lost ? |
| 17:52:50 | gevaerts | hm, good point |
| 17:54:24 | pamaury | that's #define LOGF_ENABLE |
| 17:54:51 | kugel | bertrik: no, such things are usually done by the yesno screen |
| 17:55:07 | kugel | but there's a patch of mine on the tracker to implement such a splash |
| 17:56:09 | gevaerts | printing files is a bit tricky. You can't easily get back at the filename from the fd as far as I can see, and just printing the fd doesn't seem that useful |
| 17:56:45 | pamaury | really, is it that tricky ? |
| 17:58:08 | | Join saratoga [0] (i=463f90ed@gateway/web/freenode/x-kishqowqivgnuscg) |
| 17:58:40 | saratoga | anyone know if FS #10887 - "Change poweroff to only check that the power button is pressed" is remotely safe ? |
| 17:58:52 | gevaerts | You can have the starting cluster if you like |
| 17:59:17 | pamaury | No really useful |
| 17:59:19 | pamaury | *t |
| 18:00 |
| 18:00:32 | | Join MagusG [0] (i=magusg@c-71-204-46-70.hsd1.ga.comcast.net) |
| 18:04:50 | bertrik | just knowing which plugin is leaking fd's or double-closing fd's is already very useful I think, even if you don't know the exact file name |
| 18:05:14 | FlynDice | funman's latest dbop patch seems to work just fine on my e280v2 |
| 18:09:05 | kugel | FlynDice: didn't you need to fix what I've mentioned in the previous comment? |
| 18:09:34 | | Quit Kopfgeldjaeger (Read error: 110 (Connection timed out)) |
| 18:09:38 | amiconn | Unhelpful: That *is* odd.. |
| 18:09:49 | FlynDice | kugel: no, but i didn't really look at that, it built just fine |
| 18:10:17 | kugel | strange, I haven't compiled myself but it shouldn't compile as I see it |
| 18:14:17 | *** | Saving seen data "./dancer.seen" |
| 18:16:21 | FlynDice | kugel: I see delay declared on line 31 and then used on line 51, what do you see? I'ts ifdef'd for fuze only also. The patch complained when I applied it but things seemed to be in order when I checked. |
| 18:18:07 | kugel | that's not the right patch I think |
| 18:18:17 | kugel | funman's latest patch doesn't #ifdef for the fuze only |
| 18:18:39 | FlynDice | well let me go back & check then |
| 18:18:45 | kugel | +#if defined(SANSA_FUZE) || defined(SANSA_E200V2)+ int delay = 50; |
| 18:19:11 | kugel | and there's a 'delay = 50;' before that |
| 18:19:13 | | Join Zaba [0] (n=zaba@about/goats/billygoat/zaba) |
| 18:19:34 | Zaba | hi guys, I know this is a little off-topic, but... I have a creative zen touch around here, and I was wondering, does it have its OS on the HD, or in some ROM? |
| 18:19:59 | kugel | if you know it's off-topic, why do you ask then? |
| 18:20:44 | Zaba | because people here have a chance of knowing, having dealt with various audio players before |
| 18:21:10 | saratoga | try rockbox-community |
| 18:28:44 | | Join soap_ [50] (n=soap@rockbox/staff/soap) |
| 18:29:29 | | Quit soap (Nick collision from services.) |
| 18:29:37 | | Nick soap_ is now known as Soap (n=soap@rockbox/staff/soap) |
| 18:29:42 | | Nick Soap is now known as soap (n=soap@rockbox/staff/soap) |
| 18:31:06 | FlynDice | kugel: you are correct about the delay being used before it's declared. I must have had some old leftover files. The patch applied cleanly this time and does not build. |
| 18:32:23 | saratoga | but it still doesn't work on the e200v2 anyway? |
| 18:32:49 | | Quit MagusG (Read error: 60 (Operation timed out)) |
| 18:33:12 | kugel | FlynDice: when git complains about existing files, then it doesn't apply the patch for those files |
| 18:33:55 | | Join froggyman [0] (n=sopgenor@pool-72-69-220-194.chi01.dsl-w.verizon.net) |
| 18:34:42 | FlynDice | Yes, but they are new files and they were there and looked correct when I checked. They must have been leftover from a previous patch... |
| 18:35:39 | FlynDice | saratoga: The problem doesn't occur on the e200v2's but the fixes have been breaking the e200v2's while fixing the fuze |
| 18:36:14 | kugel | can you reproduce mc2739's problems in plugins? |
| 18:37:51 | FlynDice | no more time right now, I'll try later |
| 18:38:20 | | Join tomers [0] (n=chatzill@bzq-84-109-85-100.red.bezeqint.net) |
| 18:39:42 | | Quit Utchybann ("I like core dumps") |
| 18:46:03 | Unhelpful | amiconn: is it really? i don't imagine that div == 2^N is a very common case, and it would have to be fairly common to be a real savings. num>1<<31 is also very uncommon, about 1 in a million. for APE i think i'll handle that case with a test and branch to some code that pushes some bits to stack and then calls the "small" division as a function, and fixes up the results. that will minimize the common-case cost of handling large numerators |
| 18:46:03 | Unhelpful | libgcc divider replacement it probably makes a bit more sense to spend a few more cycles to avoid the extra branches and possibly the stack push. |
| 18:51:17 | amiconn | Back when I did this implementation, optimising the 2^n case (from ordinary bit-checking in 2^i steps to the same algorithm used in ffs_arm.S) caused a measurable APE speedup |
| 18:54:46 | Unhelpful | a large one? if the main divider increases in speed then the tradeoff for special-case optimizations changes as well... my benchmarks on the ape normal sample were 82.55, 82.08, 81.82, and 81.32MHz. the first is svn, then with the 2^n test removed, then div==1, then the explicit num<div test |
| 18:55:46 | amiconn | Not a large one, but measurable. Iirc 1.5% or so |
| 18:59:03 | | Join funman [0] (n=fun@rockbox/developer/funman) |
| 18:59:20 | Unhelpful | that's pretty close to what changing the main divider loop got, so if you then improve the speed of that case a bit further still by removing the test, i can see how it would at least be even. |
| 18:59:27 | | Join flydutch [0] (n=flydutch@host51-165-dynamic.15-87-r.retail.telecomitalia.it) |
| 19:00 |
| 19:00:05 | kugel | funman: are you sure you posted the correct patch? it doesn't seem to build successfully |
| 19:00:44 | funman | I just read that, building again, I think I moved delay declaration after testing and before making the patch |
| 19:01:41 | | Quit Highlander (Read error: 104 (Connection reset by peer)) |
| 19:05:00 | funman | kugel: just uploaded a new patch with delay before reads increased to 100 nops, can you feel a difference in the scrollwheel ? |
| 19:05:17 | kugel | I'm not able to build right now |
| 19:05:53 | funman | no hurry, we're not even close to a release :/ |
| 19:06:20 | | Quit hebz0rl ("Ex-Chat") |
| 19:10:26 | | Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 19:11:30 | bertrik | funman, I can't test because I don't have an e200v2 or a fuze, but I think the only delay we need is just after waiting for FIFO empty, at least in theory |
| 19:11:32 | | Join xnyhps [0] (n=xnyhps@2001:470:1f15:da:0:0:0:1000) |
| 19:12:27 | funman | you can test on c200v2 ? |
| 19:12:32 | bertrik | yes |
| 19:13:07 | funman | it seems modification to DBOP_TIMPOL_23 isn't effective immediately |
| 19:13:11 | kugel | the lcd driver need a little delay after polling for fifo empty as well, IIRC |
| 19:13:14 | funman | the delay required might be much shorter though |
| 19:14:02 | kugel | drivers* |
| 19:14:15 | bertrik | I realise now that I mixed up DBOP_TIMPOL_23 and DBOP_TIMPOL_01 in my comment on the FS task |
| 19:17:41 | funman | I understood that, although I'm not sure why c0 & c1 haven't the same configuration |
| 19:19:31 | | Quit saratoga ("Page closed") |
| 19:22:23 | | Join Grahack [0] (n=Grahack@ip-222.net-82-216-222.rev.numericable.fr) |
| 19:23:44 | bertrik | funman, maybe one of those acts as a kind of lcd reset signal? |
| 19:28:37 | Unhelpful | ok, pretty sure i have the right math for taking n and the quotient and remainder from (n>>1/d) and figuring out the quotient and remainder for n/d |
| 19:28:53 | funman | I added a dbop_read_input() inside lcd_update_rect() to stress test it |
| 19:29:15 | Unhelpful | do we really need a special case for d == 0 in udiv_arm? on platform where we just use a C divide that case will throw a div0, so i'm imagining that is also a can't-happen... |
| 19:30:02 | funman | doesn't divide by 0 need a uint_infinity_t return type ? :) |
| 19:31:03 | funman | 10 nops are enough to not see any blue pixels / shifting |
| 19:31:06 | Unhelpful | funman: well, the libgcc divider should throw an exception for a divide by zero, and i'm pretty sure that an x/0 should cause a panic with a "divide by zero" message |
| 19:31:08 | | Quit martian67 (Nick collision from services.) |
| 19:31:09 | | Join lol2 [0] (n=arkfar@d198-166-17-170.abhsia.telus.net) |
| 19:31:21 | | Join martian67 [0] (n=arkfar@about/linux/regular/martian67) |
| 19:31:22 | | Quit lol2 (Remote closed the connection) |
| 19:31:23 | | Quit martian67 (Remote closed the connection) |
| 19:32:20 | Unhelpful | so, if we want to have the arm udiv implementation for APE behave the same as using a C division, we should call the div0 handler. and if faulty decoding instead of a panic is acceptable, we should just divid without checking :) |
| 19:32:58 | Unhelpful | if it's a condition that can't happen in a valid file then a broken decode is as "valid" as anything else we might do |
| 19:33:04 | funman | how much performance we lose with the check? |
| 19:33:09 | funman | it could help debug decoder |
| 19:34:05 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 19:34:22 | Unhelpful | well, the thing is that right now the check still returns a value instead of triggering a panic :) |
| 19:34:37 | Unhelpful | but true, it's possible that a valid file could cause a div0 due to decoder error |
| 19:36:51 | kugel | funman: 10 is what the lcd drivers also use I believe |
| 19:37:17 | kugel | I think they have it after configuring DBOP_CTRL too |
| 19:37:22 | funman | delay = 2 : still no problems |
| 19:38:16 | kugel | Unhelpful: don't we have a div0 handler for arm? |
| 19:39:02 | Unhelpful | funman: the test and branch cost two cycles, and ape does three divides per sample. i think i could make it cost one cycle with a small change to the divider... it inverts the divisor, we could set flags on than and beq to the div0 handler. |
| 19:39:13 | Unhelpful | kugel: we *have* one, but we don't *call* it :) |
| 19:39:38 | kugel | I think I've seen it in a plugin |
| 19:40:02 | | Join kramer3d [0] (n=kramer@unaffiliated/kramer3d) |
| 19:40:04 | Unhelpful | and costing a few more cycles right before panicing in a failure case to save one cycle in the working case seems fair :) |
| 19:40:11 | funman | Unhelpful: if b is conditional there's no extra cycle involved ? |
| 19:40:11 | | Quit kramer3d (Read error: 54 (Connection reset by peer)) |
| 19:40:12 | | Quit bmbl ("Bye!") |
| 19:41:53 | | Join StealthyXIIGer [0] (n=stealthy@69.216.116.162) |
| 19:42:14 | Unhelpful | funman: a skipped instruction costs at least 1c |
| 19:43:36 | pamaury | gevaerts: in you're code, I think the double free condition is the reverse: if(!(open_files & (1<<fd))) |
| 19:43:39 | | Quit amiconn (Nick collision from services.) |
| 19:43:41 | | Join pixelma_ [0] (i=quassel@rockbox/staff/pixelma) |
| 19:43:41 | | Quit pixelma (Nick collision from services.) |
| 19:43:41 | | Join amiconn_ [0] (i=quassel@rockbox/developer/amiconn) |
| 19:43:56 | | Nick pixelma_ is now known as pixelma (i=quassel@rockbox/staff/pixelma) |
| 19:43:59 | * | Unhelpful is a bit confused... div0 loads r0 from the stack top, #3 to r1, and then calls UIE... so you're supposed to push the address of the fault to the stack before calling it? |
| 19:44:01 | | Nick amiconn_ is now known as amiconn (i=quassel@rockbox/developer/amiconn) |
| 19:46:09 | funman | Unhelpful: check what libgcc does |
| 19:47:25 | Unhelpful | working on that now |
| 19:48:37 | mahoney | i've seemed to have lost some uh, loudness in my sansa, i can't figure out if my headphones are starting to die because of sweat or something or if it's a setting on rockbox |
| 19:48:43 | | Join SolarWar [0] (n=SolarWar@c-24-128-104-39.hsd1.ma.comcast.net) |
| 19:48:51 | funman | _dvmd_tls.o __div0 is 'bx lr' |
| 19:49:03 | | Join Zaba_ [0] (n=zaba@about/goats/billygoat/zaba) |
| 19:50:17 | funman | callers push lr on the stack though |
| 19:50:58 | funman | so we'd need to substract 4 to the value popped from the stack to get the real fault address |
| 19:51:05 | Unhelpful | it calls some "cfi_push" in the libgcc arm asm... i can't find a definition? |
| 19:51:58 | funman | are you checking the source ? i just opened libgcc.a |
| 19:52:04 | | Join fdinel [0] (n=Miranda@modemcable235.127-131-66.mc.videotron.ca) |
| 19:52:57 | bertrik | mahoney, I haven't noticed any changes w.r.t. volume on my sansa clip and sansa e200 |
| 19:53:26 | funman | mahoney: try removing the config file |
| 19:54:06 | Unhelpful | well, i first looked at what __div0 did in rockbox.elf. then i looked at libgcc source... which is not very enlightening. :/ |
| 19:54:38 | Unhelpful | but it does look like lr is on stack top when calling __div0, so i need to push it first (since this is an asm leaf function) |
| 19:56:27 | mahoney | ok funman willdo |
| 19:56:42 | | Quit Grahack ("Tu m'as vu ?") |
| 19:57:04 | mahoney | bertrik: yeah i can't tell if it's the headphones though they seem to die once i start to really perspire at the gym so it makes me think it could be the phones too |
| 20:00 |
| 20:00:04 | | Join MagusG [0] (i=magusg@c-71-204-46-70.hsd1.ga.comcast.net) |
| 20:00:22 | Unhelpful | we don't seem to apply an offset to lr before calling __div0 anywhere else... but maybe __div0 should apply one? |
| 20:00:24 | bertrik | Can we have genlang generate a comment with the id for each language string in lang_core.c? |
| 20:00:46 | funman | Unhelpful: i think __div0 should before calling UIE |
| 20:01:55 | | Quit Zaba (Read error: 110 (Connection timed out)) |
| 20:02:24 | | Join sefe [0] (n=5d68742c@giant.haxx.se) |
| 20:10:09 | mc2739 | funman: still no improvement for me with the latest patch on FS #10603 - maybe we should wait and see if FlynDice can reproduce the same problems I have with his e200v2. |
| 20:11:28 | gevaerts | pamaury: oh, right. Can you add a note on the tracker? |
| 20:14:20 | *** | Saving seen data "./dancer.seen" |
| 20:14:39 | Unhelpful | this looks about right... i haven't added __div0 support to the 31-bit divider body, yet. |
| 20:14:41 | Unhelpful | http://pastie.org/764196 |
| 20:14:54 | FlynDice | mc2739: funman: I get the same mpegplayer volume phenomenon but haven't checked rockboy/doom(don't have the extra stuff installed...) |
| 20:15:24 | gevaerts | pamaury: never mind, I've added one myself |
| 20:18:34 | | Quit GeekShadow (Read error: 104 (Connection reset by peer)) |
| 20:19:00 | | Quit sefe ("CGI:IRC (EOF)") |
| 20:19:21 | | Join saratoga [0] (i=9803c6dd@gateway/web/freenode/x-jcdfuasjojppojbz) |
| 20:21:25 | | Nick fxb__ is now known as fxb (n=felixbru@h1252615.stratoserver.net) |
| 20:21:47 | saratoga | what is the bug in mpeg player? seeking? |
| 20:23:48 | | Join martian67 [0] (n=arkfar@about/linux/regular/martian67) |
| 20:25:15 | mc2739 | saratoga: no, it is a scrollwheel problem. With FS #10603 installed, the volume can only be changed while paused. Without the patch, volume can be changed while playing or paused. |
| 20:25:28 | saratoga | let me try that |
| 20:26:07 | | Quit faemir (Read error: 54 (Connection reset by peer)) |
| 20:26:07 | mc2739 | with the doom and rockboy plugins, the scollwhell does not function at all |
| 20:26:46 | Unhelpful | ah, it's good to bx lr after after fixing up the result instead of falling through to the div0 handler :D |
| 20:26:58 | saratoga | yeah i can't change the volume on mine either |
| 20:27:05 | saratoga | weird that it works so well elsewhere |
| 20:28:18 | mc2739 | saratoga: kugel suggested that it may be due to the higher frame rates needed |
| 20:29:08 | kugel | it appears the approach fails if the lcd is very busy |
| 20:29:58 | mc2739 | although why would that cause a problem in the menus of doom and rockboy? |
| 20:30:34 | * | Unhelpful would love a hardware interrupt switch or button for when something gets stuck in a loop :/ |
| 20:31:06 | Unhelpful | so that rockbox could panic with a "killed at <address>" |
| 20:31:17 | | Quit Zaba_ (Remote closed the connection) |
| 20:31:19 | kugel | *cough* watchdog *cough* |
| 20:31:29 | Unhelpful | kugel: does e200 have one? |
| 20:31:47 | Unhelpful | right now the watchdog just shuts off when not serviced (on beast) |
| 20:32:17 | | Join faemir [0] (n=faemir@78.33.109.163) |
| 20:32:27 | kugel | no idea whether the e200 has one |
| 20:32:30 | amiconn | Unhelpful: div0 behaviour isn't consistent across target architectures iirc |
| 20:33:51 | Unhelpful | amiconn: well, i can move the test and save 1c in udiv, by changing the rsb \divisor, \divisor\ #0 to rsbs, and following with a beq |
| 20:35:02 | saratoga | Unhelpful: I think PP does have a watchdog |
| 20:35:11 | Unhelpful | although clearly something's going wrong with this version: http://pastie.org/764211 |
| 20:38:14 | Unhelpful | for a general-purpose divider it might make more sense to do the fixup stuff *around* the 31-bit divider, and possibly take a few extra cycles in it to spare a register for the unshifted numerator. |
| 20:39:59 | | Join fenugrec [0] (n=ABC@modemcable247.111-201-24.mc.videotron.ca) |
| 20:40:24 | saratoga | the PP product briefs appear to be gone from the internet |
| 20:46:35 | Unhelpful | we certainly don't seem to have code for supporting a PP watchdog (grep watchdog firmware/target) |
| 20:48:16 | CIA-6 | New commit by Blue_Dude (r24145): xobox: show game stats when finishing level |
| 20:51:21 | | Quit stoffel (Remote closed the connection) |
| 20:52:31 | | Nick Llorean1 is now known as Llorean (n=DarkkOne@adsl-76-202-17-167.dsl.hstntx.sbcglobal.net) |
| 20:53:50 | saratoga | Unhelpful: IIRC the AS chip on the PP5024 probably has a watchdog |
| 20:58:41 | | Join Buschel [0] (n=ab@p54A3C68F.dip.t-dialin.net) |
| 21:00 |
| 21:00:11 | saratoga | are we branching soon? |
| 21:00:48 | saratoga | i kind of want to commit the aac patches, but i won't if we're about to branch since they'll need testing on a wider variety of files then i have |
| 21:02:57 | kugel | we don't seem to freeze very soon |
| 21:03:16 | Buschel | Torne, don't you think it is time to submit fs#9708 (v9 dma patch + v2 cache alignment patch)? all the other further changes can be evaluated later on... |
| 21:03:39 | saratoga | ok then i'm just going to commit them |
| 21:08:39 | Unhelpful | hrm, i can't find any reason this should hang. the disassembly looks exactly like i'd expect. :/ |
| 21:10:36 | | Nick fxb is now known as fxb__ (n=felixbru@h1252615.stratoserver.net) |
| 21:11:37 | | Part fenugrec ("Leaving") |
| 21:12:32 | | Quit gevaerts (Nick collision from services.) |
| 21:12:41 | | Join gevaerts [0] (n=fg@rockbox/developer/gevaerts) |
| 21:14:49 | Unhelpful | ah, no, there was an error, not in control flow but in result. must've made the decoder go nuts somehow. |
| 21:22:28 | gibbon_ | good evening everybody |
| 21:22:57 | gibbon_ | i am not very happy to announce that i have to take down one of the rockbox build clients I contributed. |
| 21:24:07 | gibbon_ | is there any step besides stopping rbclient to permanently remove the machine from the build servers records? |
| 21:24:27 | CIA-6 | New commit by Buschel (r24146): Submit FS #10718. Small fix to calculation of estimated runtime to avoid negative results. |
| 21:24:33 | gevaerts | gibbon_: thanks for the time it was running! |
| 21:25:35 | kugel | gibbon_: nothing is needed, just stop it |
| 21:26:00 | gibbon_ | gevaerts: i was glad being able contribute that way... its really easy to set up a client and its the best i can do for the project for now |
| 21:26:28 | gibbon_ | so ou should basically thank the people who wrote that shiny and very helpful piece of software :) |
| 21:26:33 | gibbon_ | kugel: ok, thanks |
| 21:27:22 | gibbon_ | i am very sad to stop the machine, since i was watching the nuber of build clients drop in the last weeks ... increasing the average build cycle time to about twice the time, it needed a month or so ago |
| 21:28:01 | | Join toffe82 [0] (n=chatzill@adsl-70-235-224-119.dsl.frs2ca.sbcglobal.net) |
| 21:28:02 | bertrik | I'm sure it'll increase again, I guess it dropped because of the holidays |
| 21:28:19 | gevaerts | gibbon_: the build system does keep a full history. If you really want to remove traces, talk to Zagor |
| 21:28:59 | gibbon_ | gevaerts: no, thats fine. |
| 21:29:31 | | Join Barahir_ [0] (n=jonathan@gssn-5f757ea4.pool.mediaWays.net) |
| 21:30:04 | gibbon_ | gevaerts: i just was unsure if some part of the system should be notified if a build client will definately not reappear |
| 21:30:53 | gevaerts | gibbon_: no. It's really designed to handle clients coming and going |
| 21:31:05 | gibbon_ | even better. |
| 21:31:15 | mc2739 | gibbon_: that is the nice thing about the build system - clients can come and go at will without causing a problem |
| 21:31:52 | gibbon_ | i will spawn another, if new colocation hardware is available.. |
| 21:32:28 | gibbon_ | mc2739: yeah... i have not seen a more usable system than this before... its ... very nice :) |
| 21:33:04 | | Quit rhodan (No route to host) |
| 21:33:06 | * | kugel hasn't seen a comparable system at all yet :) |
| 21:33:33 | gibbon_ | kugel: also correct ;) |
| 21:36:31 | | Join phanboy4 [0] (n=benji@168.12.118.254) |
| 21:36:39 | Torne | Buschel: I'm going to submit it after we branch for release. |
| 21:38:47 | Buschel | Torne: fine. This wohle stuff was tested enough via flyspray. |
| 21:38:54 | Buschel | *whole |
| 21:39:06 | Torne | it's not been tested at all on many of the targets it affects |
| 21:39:46 | Buschel | well, then let us call for testers here :o) |
| 21:39:55 | Torne | but yes, i'm going to put the dma code in, and look at a etter way to align buffers (I don't like the current patch very muc and it doesn't help with all the other uffers in the system which need it) |
| 21:39:59 | Torne | already have |
| 21:40:04 | Torne | it's tested as much as it's going to be :) |
| 21:40:16 | Torne | so, after the release iw ill commit it and we will get more testers :) |
| 21:42:27 | | Quit Barahir (Read error: 110 (Connection timed out)) |
| 21:45:22 | Unhelpful | hrm, no way to panic from codec? |
| 21:45:50 | Unhelpful | i suspect a division error somewhere is causing the decoder to go wrong. it would be nice if it could just spit out the bad values. :/ |
| 21:52:30 | | Quit Zarggg () |
| 21:54:59 | CIA-6 | New commit by saratoga (r24147): Commit first part of FS #10832 by Juliusz Chroboczek. Allows playback of unstreamable AAC/ALAC files by stepping through the file to find the index, ... |
| 21:59:44 | | Quit Utchybann (Read error: 113 (No route to host)) |
| 22:00 |
| 22:02:15 | CIA-6 | New commit by saratoga (r24148): Second part of FS #10832 by Juliusz Chroboczek. Ignore empty mdat chunks in mp4 files. |
| 22:02:15 | | Quit domonoky (Read error: 104 (Connection reset by peer)) |
| 22:05:01 | | Join domonoky [0] (n=Domonoky@rockbox/developer/domonoky) |
| 22:14:24 | *** | Saving seen data "./dancer.seen" |
| 22:16:37 | | Quit phanboy4 ("Leaving") |
| 22:38:47 | | Quit dfkt ("-= SysReset 2.53=- Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn.") |
| 22:41:43 | pamaury | gevaerts: I test your FS #10889 patch and it works (I also add a ENABLE_LOGF #define). The remaining point is how the error is reported: logf only ? splash ? panic ? destroy device ? :) |
| 22:43:20 | gevaerts | pamaury: I'm not sure. panic seems a bit harsh, although it provides the most information (you can use the .elf file to find out where exactly it went wrong) |
| 22:43:58 | pamaury | I feel panic is a bit hard but perhaps splash or a screen to inform the user |
| 22:45:04 | gevaerts | maybe. It will confuse a lot of people though |
| 22:46:22 | pamaury | Perhaps go in a screen, display "Rockbox detected the plugins "...." has a problem and need to be fix. Report this bug to Rockbox team (error: plugin leak file handles)". And wait for the user to acknowledge |
| 22:47:06 | pamaury | It could be annoying if the plugin is leaking file each time it is launch but normally it's not the case |
| 22:47:38 | gevaerts | it shouldn't, true |
| 22:47:46 | bertrik | pamaury, if it is leaking every time, it *should* be annoying and fixed quickly IMO |
| 22:48:01 | pamaury | indeed |
| 22:48:42 | | Quit StealthyXIIGer (Read error: 110 (Connection timed out)) |
| 22:49:00 | pamaury | I don't exactly now how screens work in Rockbox but it feel a whole screen is better than a splash message that will probably be ignore |
| 22:49:03 | pamaury | *know |
| 22:49:31 | | Join FOAD_ [0] (n=dok@dinah.blub.net) |
| 22:50:41 | | Quit FOAD (Read error: 60 (Operation timed out)) |
| 22:50:41 | | Nick FOAD_ is now known as FOAD (n=dok@dinah.blub.net) |
| 22:55:03 | | Quit tomers ("ChatZilla 0.9.86 [Firefox 3.5.6/20091215231400]") |
| 22:56:48 | | Quit Buschel () |
| 22:59:40 | | Join DerPapst1 [0] (n=DerPapst@91-64-221-175-dynip.superkabel.de) |
| 23:00 |
| 23:04:43 | pamaury | gevaerts: is there a kind of screen like yesno but without choice ? Just a fullscreen with a message ? Perhaps you're not the one to ask ! I feel splash if too small |
| 23:05:01 | gevaerts | I'm not the one to ask indeed. I have no idea :) |
| 23:05:50 | pamaury | Does anymore know ? |
| 23:05:53 | pamaury | *anyone |
| 23:06:03 | * | pamaury is tired |
| 23:15:57 | | Quit DerPapst (Read error: 110 (Connection timed out)) |
| 23:22:31 | | Quit S_a_i_n_t ("[St.] S_a_i_n_t st.lascivious@slingshot.co.nz") |
| 23:23:00 | | Join S_a_i_n_t [0] (i=Saint@203.184.3.82) |
| 23:25:42 | | Join Utchybann [0] (n=lolo@ede67-1-81-56-102-26.fbx.proxad.net) |
| 23:33:21 | | Join Mouser_X [0] (n=3ff83802@giant.haxx.se) |
| 23:34:07 | | Quit Mouser_X (Client Quit) |
| 23:34:07 | bertrik | there seem to be a lot of little things wrong with the chip8 plugin |
| 23:35:10 | | Join JdGordon1 [0] (n=jonno@m4c5736d0.tmodns.net) |
| 23:37:49 | | Quit Barahir_ (Read error: 110 (Connection timed out)) |
| 23:46:41 | | Join merbanan [0] (n=banan@c-83-233-52-241.cust.bredband2.com) |
| 23:47:04 | | Quit pamaury ("exit(*(int *)0 / 0);") |
| 23:49:29 | | Join jamer [0] (n=d8c91986@giant.haxx.se) |
| 23:49:50 | | Nick jamer is now known as jamer123 (n=d8c91986@giant.haxx.se) |
| 23:50:33 | | Quit jamer123 (Client Quit) |
| 23:51:31 | CIA-6 | New commit by bertrik (r24149): Fix tabs in chip8 plugin |
| 23:51:57 | | Join jamer123 [0] (n=d8c91986@giant.haxx.se) |
| 23:52:21 | | Quit S_a_i_n_t ("[St.] S_a_i_n_t st.lascivious@slingshot.co.nz") |
| 23:52:57 | jamer123 | can anyone help me? |
| 23:53:29 | bertrik | yes probably, just ask your question |
| 23:53:52 | saratoga | what a wonderfully existential question |
| 23:54:34 | | Quit jamer123 (Client Quit) |
| 23:54:42 | | Join jamer123 [0] (n=d8c91986@giant.haxx.se) |
| 23:56:32 | jamer123 | well i wanna ask if your firmware can be used on a gigaware video media player |
| 23:57:38 | saratoga | theres a list of supported players on the front page |
| 23:57:43 | jamer123 | well i want to ask if my mp3 player ( a gigaware video media can use your firmware |
| 23:57:52 | jamer123 | well i want to ask if my mp3 player ( a gigaware video media can use your firmware |
| 23:58:01 | bertrik | the answer is no |
| 23:58:15 | jamer123 | not said there |
| 23:58:28 | bertrik | rockbox runs on toshiba gigabeat F and X, but not on gigaware players |
| 23:58:38 | jamer123 | sorry theres lag |
icon identifies that the person is a core developer (has commit access).