--- Log for 02.01.110 Server: niven.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 1 month and 1 day ago 00.12.01 Quit toffe82 (Read error: 110 (Connection timed out)) 00.13.54 *** Saving seen data "./dancer.seen" 00.17.54 # 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 # stripwax: is tremor actually doing any better? 00.20.56 # looking at it i don't think so 00.21.07 # it uses fewer temporary variables, but it uses them over and over 00.21.19 # 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 # i think its basically the same as what we do 00.22.30 # and the solution on ARM for Tremor was to write those butterflies in asm 00.23.07 # I mean, tremor never takes the address (via &) of any of those temporary variables. So they can all be registers. 00.23.27 # Only the real memory writes go via & 00.23.58 # Maybe I shouldn't be using XPROD31/XNPROD31 in TRANSFORM macros.. 00.24.34 # does the ffmpeg one do that? 00.29.02 # 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 # thats probably my fault for CMUL 00.29.54 # 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 # 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 # New commit by 03tomers (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 # ugh add r7, r0, #8 then ldr r3, [r7, #4] 00.33.45 # thats the same as just doing ldr r3, [r7, #12] right? 00.34.31 # err ldr r3, [r0, #4] 00.34.40 # err ldr r3, [r0, #12] 00.34.49 # what the hell is the compiler doing 00.34.51 # :) right unless you also (need to) reuse r7? 00.35.15 # it does not 00.35.20 # if they all look like that, then yeah, that sounds really crappy 00.35.43 # i see why doing these butterflies in ASM for Tremor speed things up so much 00.35.54 # gcc seems terribly confused by them 00.42.47 # how many registers can I actually use on ARM? r0 through r12 or can I use more? 00.47.27 # I think all but pc really 00.48.34 # 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 # so thats r0 through r13? 00.49.24 Nick kramer3d is now known as kramkram (n=kramer@unaffiliated/kramer3d) 00.51.31 # 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 # again, provided you push/pop the ones that aren't {r0-r3,r12} before using them 00.52.22 # i'd forgotten how much i hate doing asm 00.52.52 # 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 # svn://svn.rockbox.org check the wiki pages for UsingSVN. 00.55.07 # hmm... I have tried that with no success 00.55.20 # check the wiki pages... 00.56.05 # thanks 00.56.08 # I will 00.56.28 # its annoying that ldm can't stride by two words at a time 00.56.48 # got it 00.56.55 Join StealthyXIIGer [0] (n=stealthy@69.216.116.162) 00.56.56 # svn://svn.rockbox.org/rockbox/trunk 00.57.10 # opensrcguy - depends if you want trunk or not ;-) 00.57.19 # oh no 00.57.26 # I just want to start exploring there 00.57.34 # I am going to get the mini2440 port 00.57.49 # saratoga - yeah, .. but when/where do we need that? 00.58.14 # for butterflies, then i could load just the real parts in one stride 00.58.25 # since they're stored interleaved 00.58.37 # can't we just load them all (real+imag) in one go? 00.59.24 # yeah but i won't have enough registers to store them all, and all the results 00.59.33 # so i won't be able to use stm to write them back out 01.03.01 Quit pamaury ("exit(*(int *)0 / 0);") 01.03.48 Quit bmbl ("Bye!") 01.04.07 # saratoga - which piece of code are you looking at 01.04.12 # fft4 01.04.35 # ah right 01.04.47 # i think the best i can do is one ldm and two seperate stm 01.04.54 # which isn't bad 01.05.08 # only wastes a few cycles due to lack of registers 01.06.02 # have you seen how mdct_arm.S does butterfly_8 ? 01.06.41 # 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 # in crt0.asm I see there is a call to map_section but I cannot find where that function is at 01.07.12 # 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 # stripwax: hmm let me see how they do it 01.08.16 # oh wow thats a lot smarter then I 01.12.13 # 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 # i don't think its quite the same thing as fft4 01.12.35 # it's not 01.12.48 # but yeah i should be able to step through in similar order 01.12.55 # exactly 01.13.10 # its really stupid that i'm doing this, a computer would be so much better 01.13.24 # hah 01.13.36 # O2 / O3 definitely didn't do any better on that code? 01.14.31 # i've got them if you want to see 01.14.35 # 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 # O2 is even longer then O1, which is ridiculous 01.15.31 # i don't know how it managed to add more ops 01.15.36 # isn't O2 supposed to be 'minimize size' ? 01.15.54 # or am i misremembering / thinking about vc++ 01.16.18 # thats Os 01.17.56 Join kramer3d [0] (n=kramer@unaffiliated/kramer3d) 01.19.05 # wonder if that would play nicely. 01.20.14 # wow this is actually really easy and i just suck 01.20.29 # i have registers left over 01.20.40 # hahaha 01.21.06 # what is the point of rsb on arm? 01.21.08 # 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 # isn't it the same as sub with the operands flipped? 01.21.21 # saratoga - so you can still do tricks with the second operand 01.21.30 # oh for shifting? 01.21.31 # e.g. shifts 01.21.32 # yeah 01.22.00 # gcc uses it sometimes instead of sub without touching the second argument 01.22.02 # i wonder why 01.23.42 # * stripwax shrugs 01.24.01 Quit opensrcguy () 01.24.23 # also second operand doesn't have to be a register, but first operand does 01.24.25 # I think 01.24.33 # e.g. rsb r0, r0, #0 01.25.14 # ok. so with some tweaks, gcc seems to spit out something almost reasonably, with some ldmias in it 01.25.21 # no stmias unfortunately 01.25.21 Quit kramkram (Read error: 60 (Operation timed out)) 01.25.51 # 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 # 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.08.42 # do i have to store all registers I touch ? 02.08.58 # only if you need them again 02.09.53 # in a function call that is 02.10.17 # stripwax: http://pastebin.com/m34619a34 02.10.21 # 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 # so I only need to do stmdb sp!, {r4, r5, r6, r7, r8, r9, r10, r11} ? 02.11.43 # and I guess I should try to use r14 then if its free 02.11.57 # {r4-r11,lr} 02.12.13 # which one is lr? 02.12.14 # assuming that you won't be modifying r13 (=sp) or r15 (=pc). lr=r14 02.12.27 # = function return address 02.12.29 # i don't touch 14 02.12.46 # ok, no need to stack it in that case 02.12.57 # i'll rearrange my registers to touch fewer important ones 02.13.21 # what happens to r1-r3 when you call? does the caller automatically stack them if it needs them? 02.13.31 # or does the compiler purposefully not use them around function calls 02.13.57 *** Saving seen data "./dancer.seen" 02.14.54 # the compiler uses r0 thru r3 for function arguments (the first four arguments to the function). 02.15.19 # 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 # http://pastebin.com/f50a4d7b8 02.16.04 # 34 clocks when inlined assuming no memory latency 02.17.19 # gcc used 63 clocks 02.17.25 # so a factor of 2 improvement 02.17.32 # presumably fft16 would (=could) reuse some of those fft4 results without needing to store/reload ? 02.17.40 # I'm not sure how much benefit that would yield 02.17.47 # hey that's pretty good 02.18.04 # what's the performance on target like? 02.18.07 # no idea 02.18.12 # not even sure if its correct :) 02.18.55 # if I declare this inside a .S file can it still be inlined without stacking everything? 02.19.13 # or should I make it an asm block inside a c function? 02.23.57 # 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 # Unhelpful: so just list r1-r12 as outputs? 02.25.43 # 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 # that will allow registers in the asm block to be subject to compiler register allocation 02.26.05 # why is that better then clobbering? 02.26.11 # ah ok 02.26.53 # 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 # Unhelpful: http://pastebin.com/m40eb175a 02.30.38 # is that what you mean? 02.32.06 # 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 # so just clobber them? 02.33.08 # yep 02.33.39 # is it possible to have asm that has no 'output' registers? 02.33.48 # the only output of this is really memory 02.34.50 # i keep getting an impossible constraint error 02.34.58 # 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 # shouldn't it be just "r" ? 02.37.01 # instead of a? 02.37.24 # yeah, I think so. what is "a" ? 02.37.49 # i don't know 02.37.51 # heh 02.37.57 # am i not allowed to ahve comments in an asm block? 02.38.00 # its erroring on those now 02.38.06 # also, shouldn't you refer to it as %[r0] or something? rather than r0. 02.38.36 # saratoga: i usually just use C comments... 02.39.20 # 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 # 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 # take a look at lib/asm_arm.h for examples 02.41.00 # also - you don't need "cc" clobber here. there's no condition code flags on those instructions. 02.43.17 # i don't think i need semi colons 02.44.46 # http://pastebin.com/m20527f49 02.44.58 # the assembler is not happy 02.45.08 # how would it know where the instruction ends, if you don't have semicolons? 02.45.36 # remember, this is going through the C preprocessor. all those strings just get concatenated into one long string 02.45.46 # it needs new lines 02.46.09 # see asm_arm.h - I don't think you *need* newlines (e.g. vect_add) 02.46.38 # at a guess, you need either one of semicolons or newlines, I suppose 02.47.36 # you still need to use "%[r0]" in the asm, not just "r0" though. 02.47.40 # stripwax: anything the assembler will accept as ending a statement... 02.47.51 # good point 02.48.12 # stripwax: um... why would he need to use %[r0] unless that refers to a named input or output variable? 02.48.23 # - because it does? 02.48.41 # oh, it does? that's confusing :) 02.48.56 # data aborts 02.49.04 # i bet i have the ldm instructions wrong 02.49.10 # could set the inputs to be [z] "r" (z), instead of [r0] "r" (z), if it's less confusing 02.49.38 # 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 # 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 # ah 02.50.09 # so you're blatting over random memory locations probably :) 02.50.12 # so " : %[r0] "r" (z)" ? 02.50.46 # hmm no 02.50.49 # no 02.51.05 # i.e. ldmia %[r0], blah 02.51.16 # oh you mean for ldm 02.51.30 # or to make it less confusing- ldmia %[z], blah (and have [z] "r" (z) in the inputs section) 02.52.16 # 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 # http://pastebin.com/m79fe8df9 02.56.17 # still no good 02.57.39 # still aborts? 02.58.45 # yeah 02.59.45 # stripwax: he could. i'm really not sure it will help any, but it might. 03.00.19 # isn't there a way to specify a specific range of memory as clobbered or as an output? 03.00.28 # I don't think so 03.00.44 # why would that be needed 03.01.57 # 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 # isn't that what the memory clobber handles? 03.02.39 # or did you mean just to be more specific 03.02.52 # "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 # saratoga: a memory clobber will force reloads of *anything* from memory 03.03.28 # 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 # maybe i need to do that 03.03.56 # Yeah but that one updates the address pointer 03.04.22 # i.e. it returns the incremented pointer 03.04.22 # oh hmm 03.04.39 # 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 # am i using ldmia wrong then? 03.05.21 # I don't think so 03.05.49 # haha that fixed it 03.05.55 # 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 # although the audio is a little corrupted, so i obviously have a mistake somewhere 03.07.38 # 31.98MHz 03.09.46 # 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 # 31.98 for 192kbps? 03.10.51 # stripwax: yes 192k vorbis 03.11.25 # so about 1MHz improvement 03.11.36 # not bad!! 03.11.38 # yeah 03.12.27 # we'd get a lot more fixing hte other BFs too 03.13.42 # for the add/sub stuff, sure - but can only use the ldmia/stmia trick for fft4 03.13.46 # 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 # Unhelpful: the poitner doesn't change at all 03.14.27 # the asm isn't incrementing the pointer 03.14.47 # stripwax: i think it'll work in fft8 03.15.11 # 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 # 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 # although probably not as well since it'll probably run out of registers 03.16.07 # but still an extra stm or two is just 1 or 2 clocks wasted, still massive room for imrpvoement 03.16.58 # 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 # heres the almost working version if anyone wants to check my math: http://pastebin.com/m620017fb 03.17.22 # i need to stop doing this for a while before i lose my mind 03.17.42 # Probably need to just expand the equations in fft8 and do it all (again) by hand 03.17.51 # Right - don't want anyone to lose their mind over this! 03.20.16 # 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 # 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.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 # New commit by 03kkurbjun (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 # New commit by 03kkurbjun (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 # New commit by 03kkurbjun (r24140): Brickmania: Change the drawing/collision detection to simplify position management. 05.54.57 Quit GeekShadow ("The cake is a lie !") 05.57.02 # running time is wrong on targets with software USB because its only updated if you go into charging mode, not USB 06.01.40 # hmm actually it looks like you actually need to browse to the menu while its actively charging to reset it 06.04.19 # is touching the global_status struct from /firmware ok? 06.04.39 # 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 # 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 # 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 # rockbox doesn't have MTP mode, so if you're getting MTP you're in the OF 06.26.02 # I'd check again 06.26.26 # It does. it had a nice little rockbox splash too 06.26.55 # (specifically stated MTP, and rhythmbox started up and behaved like an MTP player connected) 06.28.05 # you're probably confusing MSC with MTP 06.28.51 # 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 # I plugged in just now, shows a USB connector and says "Multimedia Mode" ? 06.29.55 # that would be MSC 06.30.17 # Hrm, but then hal or whatever is saying i connected a media player, rather than behaving like any random flash drive. 06.30.27 # but i do see /dev/sdd is available, so yea 06.31.42 # assuming thats linux, you might have this problem: http://www.rockbox.org/wiki/LibGphoto2Bug 06.32.20 # nah it reads it correctly. just wasn't expecting it to be treated "Special" now. 06.32.24 # ok well nevermind then :) 06.33.11 # Do you happen to know if it charges in this mode, or do I still need the OF for that? 06.33.59 # it charges 06.34.57 # ty saratoga 06.45.20 Quit Llorean ("Leaving.") 06.45.30 Quit saratoga ("Page closed") 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.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.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.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.09.36 # 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.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.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.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 # New commit by 03torne (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 # 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.08.20 # 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 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 # 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 # 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 # 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 # Torne, I think in apps/plugins/SOURCES 15.25.31 # 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 # since the manual only knows about large_plugin_buffer which is much bigger (the one added for Lua) 15.26.15 # I don't know 15.26.24 # bertrik: you helped me then, could you help me now? 15.27.30 Join Bagder [241] (n=daniel@rockbox/developer/bagder) 15.27.57 # BdN3504, I have to go now, maybe in an hour or so 15.29.16 # 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 # Torne: why not build it as an overlay plugin on small-buffer targets? 15.31.49 # because i don't know what that is 15.31.59 # also if the plugin buffer is that small then there probably isn't enough ram to function usefully 15.32.02 # 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 # 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 # stories can be up to 512KB 15.33.08 # hm actually 15.33.11 # Torne: just revive the old bit-rotted low-mem code! 15.33.37 # 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 # i dunno if i can even find it :) 15.33.49 # the swapping code is gone entirely :0 15.34.01 # Unhelpful: ah right 15.34.25 # 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 # Torne: so just grab the audio buffer if you're using an overlay? you've already stopped playback... 15.35.10 # yes, i just need to make sure not to overwrite myself as the comments say 15.35.26 # didn't realise there was already a way to do this easily :) 15.35.36 # i guess frotz can run on everything then, except the charcell devices 15.36.04 # if you do overwrite yourself, someone will make use of that to write a bootloader 15.36.10 # haha 15.36.22 # 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 # 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 # the story should always fit in the audio buffer 15.37.53 # the low memory version of the terp would be more code 15.38.06 # hm, true 15.38.32 # frotz is nearly done 15.39.13 # undo is the only major thing left that doesn't work (expects malloc) 15.39.28 # so use malloc 15.39.31 # 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 # kugel: naw, not worth it 15.39.41 # plugins and codecs actually have it 15.39.52 # undo is for sissies ;) 15.39.52 # kugel: it only allocates and frees in a fixed sequence, the undos are a ring buffer 15.40.10 # i can write a much more trivial implementation which will work 15.40.24 # Unhelpful: indeed 15.40.48 # Unhelpful: but there are interesting abuses of the save_undo opcode which might be nice to support 15.40.57 # e.g. using it to do backtracking decision making ;) 15.41.32 # 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 # this divider can alos process numerator Torne: using it to backtrack in the story code, you mean? scary, sounds like an abuse. :P 15.42.16 # Torne: people actually do that? 15.42.22 # people do a lot of z-machine abuses 15.42.41 # * gevaerts can't help being impressed 15.42.45 # 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 # you can only communicate one bit of information through it 15.43.30 # One bit should be enough for everyone! 15.43.32 # 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 # or at least to make the unbounded amount smaller 15.44.18 # you might do this if you were, say, implementing prolog 15.44.32 # implementing prolog. in z-machine. 15.44.35 # 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 # also, i was thinking about plugins leaking filehandles. Might it be worth doing something to prevent this? 15.50.31 # 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 # 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.05.26 # 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 # 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 # 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 # tsrs might need some special handling 16.14.22 # 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 # gevaerts: the open call might be in core code (say, opening an image by filename) 16.15.05 # does core track number of open handles? you could check those before and after starting the plugin... 16.15.22 # New commit by 03unhelpful (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 # no but it easy to count 16.15.40 # not good enough. Other things might open files while the plugin is running 16.15.43 # I'd rather see a panic than some mechanism to autoclose 16.15.57 # I agree, that would be too complicated and error-prone 16.16.37 # I don't think it would be that complicated 16.16.57 # 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 # Hum, how would you know if the open is done from a plugin or not ? 16.17.25 # That would mean adding code for each function in the plugin api that could possibly open a file 16.17.36 # pamaury: plugins go through rb->, so you can easily add a wrapper 16.18.06 # 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 # but yes, the problem is those less obvious functions 16.20.12 # * gevaerts agrees 16.20.50 # Which functions can lead to an unclosed open/opendir ? There are open, opendir of course and then ? 16.21.15 # 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 # What about functions that play a sound ? How is it handled ? The buffering code handles that ? 16.24.38 # 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 # 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 # what it does: it disables the play button and assigns the rec button the play button function 16.25.15 # 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 # New commit by 03unhelpful (r24143): Add missing EOF newline. 16.25.45 # kugel: that's next :P 16.25.54 # gevaerts: what about bufopen/bufclose. I have no knownledge of audio code 16.26.09 # hm, no idea 16.27.22 # 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 # nice!!! thanks a lot! 16.28.42 # Unhelpful: wasn't the div routines the only reason that we link libgcc? 16.29.09 # pamaury: no plugin actually calls them 16.29.36 # 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 # what I would do is keep open files in a bitmap 16.31.41 # More reliable than just a counter in case of multiple close() calls 16.32.27 # 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 # yes, except that I'd just use one unsigned int 16.33.19 # (array or bitmap, implementation detail) 16.34.08 # That's seem easy and much more reliable than a counter of course. A counter is not sufficient anyway 16.34.21 # if you do it that way close-on-exit is a trivial extension 16.34.29 # Yes 16.34.53 # 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 # *should know 16.35.43 # how do you know which bit to set in the bitmap? 16.36.12 # with the fd 16.36.27 # (with the return value of open) 16.36.46 # can we guarantee limits on the range of the fd? 16.37.16 # sure, that's the maximum number of open files, currently 8 16.37.30 # 11 16.37.41 # ah, ok 16.37.43 # oh, ok only 8 or 11 files currently, didn't know that 16.37.53 # That's quite a limitation 16.38.20 # That's a good reason we fight against un-closed handles 16.38.22 # *to 16.38.26 # You could do an array of unsigned ints, and some preprocessor magic to make it all work for >3w 16.38.31 # *32 16.39.07 # or just an #error if it's set too high... 16.39.23 # I like that idea 16.39.27 # an #error is probably sufficient for now 16.39.59 # * kugel thinks a counter is sufficient 16.40.04 # or a #warning and disable the guard 16.40.23 # kugel: a counter can't be sufficient 16.40.45 # because the plugin needs to be fixed anyway, there's no need for closing leaked fds 16.41.06 # no I mean, it's not a reliable way to determine if it leaked or not 16.41.09 # kugel: it's counter++ vs bitmap|(1< 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 # I thought only open() in plugins count 16.42.29 # pamaury: it would presumably still be in a plugin wrapper 16.43.07 # ah yes 16.43.31 # 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 # gevaerts: except that bitmap|(1< doesn't really matter unless we were to up the limit 16.43.57 # kugel: in what way? 16.44.13 # we're at one third of the limit now 16.45.12 # 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 # the bitmap will (or at least can) catch double close, while those would just break a counter 16.46.07 # bertrik: it would, but it's a lot harder there I think 16.46.55 # gevaerts, I don't see why (yet) 16.47.02 # There's no real point at which you know the expected state 16.47.50 # and it's a lot harder to know where an open or close is called from 16.48.02 # ah yes of course 16.48.18 # 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 # you could make a debug screen that shows which files are open, and which thread opened them 16.51.12 # How do you know the thread ? 16.51.21 # (that would mean adding code ?) 16.52.14 # it's extra code, yes 16.52.33 # only for debug build, if I understand 16.52.35 # ? 16.52.59 # probably 16.53.21 # you could do it for all builds, but that seems a bit wasteful 16.53.44 # indeed 16.54.04 # did anyone ever do a debug build? 16.54.14 # debug build=build with debug menu for me 16.54.24 # :) 16.54.27 # that's the normal build 16.54.42 # yes but I didn't want to write the entire sentence 16.55.14 # 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 # ???? 16.58.21 # the debug menu is in all builds 16.59.07 # really ? I thought it was only an option (configure asks for it) 16.59.35 # the menu is always there 16.59.46 # but not accessible ? 16.59.54 # it is 17.00.51 # 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 # We could have a very special build which do stack-trace each time open is called to see where it leak ;) 17.02.36 # funman seems to have success 17.03.32 # New commit by 03bertrik (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 # kugel, cool 17.09.25 # let's hope his patch also works on the e200v2 17.09.41 # mc2739: ping :) 17.10.27 # mc2739: have you seen funman's latest patch? 17.11.11 # kugel: yes, I'll test when I get back in about 30 minutes 17.11.18 # nice 17.12.36 # gevaerts: so, we go for this bitmap solution ? I can implement that if there's no objection 17.13.38 # pamaury: I'd go for that one, yes 17.14.06 # Ok, I'll do that today if I have time or tomorrow, that's shouldn't be long 17.14.24 # I might have a go now... 17.14.48 # 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 # 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 # OK, I've added FS#10889 17.49.15 # 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 # *'s 17.49.44 # pamaury: I know. I think we need a bit more discussion to know what exactly to do when detecting the issue 17.50.11 # yes, did you test it with a crappy plugin to check ? 17.50.43 # (also perhaps printing the leaked files is a good thing to help debugging on error) 17.50.44 # I didn't test it at all :) 17.50.51 # ok 17.51.07 Join hebz0rl [0] (n=hebz0rl@dslb-088-065-054-141.pools.arcor-ip.net) 17.51.15 # do we have a function to splash a text and wait for confirmation? 17.51.52 # 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 # hm, good point 17.54.24 # that's #define LOGF_ENABLE 17.54.51 # bertrik: no, such things are usually done by the yesno screen 17.55.07 # but there's a patch of mine on the tracker to implement such a splash 17.56.09 # 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 # really, is it that tricky ? 17.58.08 Join saratoga [0] (i=463f90ed@gateway/web/freenode/x-kishqowqivgnuscg) 17.58.40 # anyone know if FS#10887 - "Change poweroff to only check that the power button is pressed" is remotely safe ? 17.58.52 # You can have the starting cluster if you like 17.59.17 # No really useful 17.59.19 # *t 18.00.32 Join MagusG [0] (i=magusg@c-71-204-46-70.hsd1.ga.comcast.net) 18.04.50 # 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 # funman's latest dbop patch seems to work just fine on my e280v2 18.09.05 # 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 # Unhelpful: That *is* odd.. 18.09.49 # kugel: no, but i didn't really look at that, it built just fine 18.10.17 # 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 # 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 # that's not the right patch I think 18.18.17 # funman's latest patch doesn't #ifdef for the fuze only 18.18.39 # well let me go back & check then 18.18.45 # +#if defined(SANSA_FUZE) || defined(SANSA_E200V2)+ int delay = 50; 18.19.11 # and there's a 'delay = 50;' before that 18.19.13 Join Zaba [0] (n=zaba@about/goats/billygoat/zaba) 18.19.34 # 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 # if you know it's off-topic, why do you ask then? 18.20.44 # because people here have a chance of knowing, having dealt with various audio players before 18.21.10 # 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 # 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 # but it still doesn't work on the e200v2 anyway? 18.32.49 Quit MagusG (Read error: 60 (Operation timed out)) 18.33.12 # 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 # 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 # 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 # can you reproduce mc2739's problems in plugins? 18.37.51 # 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 # 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 # 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 # 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 # 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
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 # 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.05 # funman: are you sure you posted the correct patch? it doesn't seem to build successfully 19.00.44 # 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 # 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 # I'm not able to build right now 19.05.53 # 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 # 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 # you can test on c200v2 ? 19.12.32 # yes 19.13.07 # it seems modification to DBOP_TIMPOL_23 isn't effective immediately 19.13.11 # the lcd driver need a little delay after polling for fifo empty as well, IIRC 19.13.14 # the delay required might be much shorter though 19.14.02 # drivers* 19.14.15 # I realise now that I mixed up DBOP_TIMPOL_23 and DBOP_TIMPOL_01 in my comment on the FS task 19.17.41 # 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 # funman, maybe one of those acts as a kind of lcd reset signal? 19.28.37 # 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 # I added a dbop_read_input() inside lcd_update_rect() to stress test it 19.29.15 # 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 # doesn't divide by 0 need a uint_infinity_t return type ? :) 19.31.03 # 10 nops are enough to not see any blue pixels / shifting 19.31.06 # 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 # 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 # 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 # how much performance we lose with the check? 19.33.09 # it could help debug decoder 19.34.05 Join faemir [0] (n=faemir@78.33.109.163) 19.34.22 # well, the thing is that right now the check still returns a value instead of triggering a panic :) 19.34.37 # but true, it's possible that a valid file could cause a div0 due to decoder error 19.36.51 # funman: 10 is what the lcd drivers also use I believe 19.37.17 # I think they have it after configuring DBOP_CTRL too 19.37.22 # delay = 2 : still no problems 19.38.16 # Unhelpful: don't we have a div0 handler for arm? 19.39.02 # 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 # kugel: we *have* one, but we don't *call* it :) 19.39.38 # I think I've seen it in a plugin 19.40.02 Join kramer3d [0] (n=kramer@unaffiliated/kramer3d) 19.40.04 # 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 # 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 # funman: a skipped instruction costs at least 1c 19.43.36 # gevaerts: in you're code, I think the double free condition is the reverse: if(!(open_files & (1< Unhelpful: check what libgcc does 19.47.25 # working on that now 19.48.37 # 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 # _dvmd_tls.o __div0 is 'bx lr' 19.49.03 Join Zaba_ [0] (n=zaba@about/goats/billygoat/zaba) 19.50.17 # callers push lr on the stack though 19.50.58 # so we'd need to substract 4 to the value popped from the stack to get the real fault address 19.51.05 # it calls some "cfi_push" in the libgcc arm asm... i can't find a definition? 19.51.58 # 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 # mahoney, I haven't noticed any changes w.r.t. volume on my sansa clip and sansa e200 19.53.26 # mahoney: try removing the config file 19.54.06 # 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 # 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 # ok funman willdo 19.56.42 Quit Grahack ("Tu m'as vu ?") 19.57.04 # 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.04 Join MagusG [0] (i=magusg@c-71-204-46-70.hsd1.ga.comcast.net) 20.00.22 # we don't seem to apply an offset to lr before calling __div0 anywhere else... but maybe __div0 should apply one? 20.00.24 # Can we have genlang generate a comment with the id for each language string in lang_core.c? 20.00.46 # 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 # 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 # pamaury: oh, right. Can you add a note on the tracker? 20.14.20 *** Saving seen data "./dancer.seen" 20.14.39 # this looks about right... i haven't added __div0 support to the 31-bit divider body, yet. 20.14.41 # http://pastie.org/764196 20.14.54 # 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 # 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 # what is the bug in mpeg player? seeking? 20.23.48 Join martian67 [0] (n=arkfar@about/linux/regular/martian67) 20.25.15 # 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 # let me try that 20.26.07 Quit faemir (Read error: 54 (Connection reset by peer)) 20.26.07 # with the doom and rockboy plugins, the scollwhell does not function at all 20.26.46 # 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 # yeah i can't change the volume on mine either 20.27.05 # weird that it works so well elsewhere 20.28.18 # saratoga: kugel suggested that it may be due to the higher frame rates needed 20.29.08 # it appears the approach fails if the lcd is very busy 20.29.58 # 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 # so that rockbox could panic with a "killed at
" 20.31.17 Quit Zaba_ (Remote closed the connection) 20.31.19 # *cough* watchdog *cough* 20.31.29 # kugel: does e200 have one? 20.31.47 # 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 # no idea whether the e200 has one 20.32.30 # Unhelpful: div0 behaviour isn't consistent across target architectures iirc 20.33.51 # 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 # Unhelpful: I think PP does have a watchdog 20.35.11 # although clearly something's going wrong with this version: http://pastie.org/764211 20.38.14 # 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 # the PP product briefs appear to be gone from the internet 20.46.35 # we certainly don't seem to have code for supporting a PP watchdog (grep watchdog firmware/target) 20.48.16 # New commit by 03Blue_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 # 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.11 # are we branching soon? 21.00.48 # 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 # we don't seem to freeze very soon 21.03.16 # 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 # ok then i'm just going to commit them 21.08.39 # 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 # ah, no, there was an error, not in control flow but in result. must've made the decoder go nuts somehow. 21.22.28 # good evening everybody 21.22.57 # i am not very happy to announce that i have to take down one of the rockbox build clients I contributed. 21.24.07 # is there any step besides stopping rbclient to permanently remove the machine from the build servers records? 21.24.27 # New commit by 03Buschel (r24146): Submit FS#10718. Small fix to calculation of estimated runtime to avoid negative results. 21.24.33 # gibbon_: thanks for the time it was running! 21.25.35 # gibbon_: nothing is needed, just stop it 21.26.00 # 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 # so ou should basically thank the people who wrote that shiny and very helpful piece of software :) 21.26.33 # kugel: ok, thanks 21.27.22 # 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 # I'm sure it'll increase again, I guess it dropped because of the holidays 21.28.19 # gibbon_: the build system does keep a full history. If you really want to remove traces, talk to Zagor 21.28.59 # gevaerts: no, thats fine. 21.29.31 Join Barahir_ [0] (n=jonathan@gssn-5f757ea4.pool.mediaWays.net) 21.30.04 # 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 # gibbon_: no. It's really designed to handle clients coming and going 21.31.05 # even better. 21.31.15 # gibbon_: that is the nice thing about the build system - clients can come and go at will without causing a problem 21.31.52 # i will spawn another, if new colocation hardware is available.. 21.32.28 # 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 # kugel: also correct ;) 21.36.31 Join phanboy4 [0] (n=benji@168.12.118.254) 21.36.39 # Buschel: I'm going to submit it after we branch for release. 21.38.47 # Torne: fine. This wohle stuff was tested enough via flyspray. 21.38.54 # *whole 21.39.06 # it's not been tested at all on many of the targets it affects 21.39.46 # well, then let us call for testers here :o) 21.39.55 # 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 # already have 21.40.04 # it's tested as much as it's going to be :) 21.40.16 # 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 # hrm, no way to panic from codec? 21.45.50 # 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 # New commit by 03saratoga (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.02.15 # New commit by 03saratoga (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 # 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 # 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 # I feel panic is a bit hard but perhaps splash or a screen to inform the user 22.45.04 # maybe. It will confuse a lot of people though 22.46.22 # 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 # 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 # it shouldn't, true 22.47.46 # pamaury, if it is leaking every time, it *should* be annoying and fixed quickly IMO 22.48.01 # indeed 22.48.42 Quit StealthyXIIGer (Read error: 110 (Connection timed out)) 22.49.00 # 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 # *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.04.43 # 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 # I'm not the one to ask indeed. I have no idea :) 23.05.50 # Does anymore know ? 23.05.53 # *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 # 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 # New commit by 03bertrik (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 # can anyone help me? 23.53.29 # yes probably, just ask your question 23.53.52 # 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 # well i wanna ask if your firmware can be used on a gigaware video media player 23.57.38 # theres a list of supported players on the front page 23.57.43 # well i want to ask if my mp3 player ( a gigaware video media can use your firmware 23.57.52 # well i want to ask if my mp3 player ( a gigaware video media can use your firmware 23.58.01 # the answer is no 23.58.15 # not said there 23.58.28 # rockbox runs on toshiba gigabeat F and X, but not on gigaware players 23.58.38 # sorry theres lag