**** BEGIN LOGGING AT Thu Jul 17 02:59:59 2014 Jul 17 03:00:17 I still think you could alter the mapping a bit to need less conditionals when parsing on the PRU Jul 17 03:02:26 I checked, it won't really make too much of a difference..... I can have 7th bit high for 64 bit stuff, but then it'll reduce only one if statement. Jul 17 03:03:08 having fixed place for operands would work, but as per my original inst encoding scheme, a lot has to be changed. Jul 17 03:03:46 and most importantly, having fixed operand position => certain inst become 64 bit :/ Jul 17 03:04:39 might be worth the trade off since they're not stored in the pru program memory Jul 17 03:06:14 hmm... Jul 17 03:06:21 possibly Jul 17 03:08:14 does the ti compiler support inline assembly? might be worth doing some tasks that way Jul 17 03:12:06 the thing is there will still be exceptions, e.g. "SET DIO[x], y" the operands are x and y rather than "DIO[x]" and "y" as it would have been if DIO were a normal array. Jul 17 03:12:30 ^ for the every operator has it own place thing Jul 17 03:12:46 yeah, it does have inline assembly Jul 17 03:19:06 alexanderhiam : for what I know the firmware has crossed the 50% mark (4KB). and I still have 35% features left. so it may fill the 8KB space if I'm going the way I am right now. But once I abstract stuff into functions and optimize the compiling etc, I'm sure stuff will fit in. Jul 17 03:21:38 I also have plans of removing *many* of the if elses and optimizing on the switch cases. I'm quite sure stuff should fit in after that. Jul 17 03:21:40 abstracting mgiht add overhead as well, might be worth adding the -k flag to compiling step to keep save an assembly file and keep an eye on that as you change stuff Jul 17 03:22:23 i.e. clpru --c99 -k pru0_firmware.c Jul 17 03:22:33 generates pru0_firmware.asm Jul 17 03:23:19 just to make sure things are happening in a sane way; it is a beta compiler after all Jul 17 03:28:11 karki: do you have code composer studio? from the compiler README it looks like the CCS debugger works with the PRU, though that might need a JTAG connection Jul 17 03:28:20 yeah, wonder when the gcc stuff will be out Jul 17 03:28:37 I jave no ccs or jtag :'( Jul 17 03:30:28 what about this: http://sourceforge.net/projects/prudebug/ Jul 17 03:38:22 interesting :) Jul 17 03:38:28 I'll have a look Jul 17 03:38:40 though I can't get even it to run :( Jul 17 04:01:36 * alexanderhiam is doing a bad job forming sentences tonight Jul 17 04:20:24 alexanderhiam may be a bit too sleepy :p Jul 17 04:29:01 meeting in about an hour? Jul 17 04:53:58 karki: right, 7 minutes now? Jul 17 04:55:44 make it 10 min :p (I have a tiny task to do) Jul 17 05:03:44 jkridner: you around? Jul 17 05:04:35 I'm back! Jul 17 05:04:44 panto : you free? Jul 17 05:07:27 maybe this wasn't the best time... Jul 17 05:08:12 hmm.... probably not :/ Jul 17 05:14:21 karki_: well it's panto's AM, if he drops in you want to figure out a better time for him and let jkridner and I know? I think it would be best to all get back on the same page before talking with chris again Jul 17 05:14:49 alexanderhiam : sure :) Jul 17 05:37:47 morning Jul 17 05:37:52 I'm here Jul 17 05:38:07 sorry, baby needed depooping Jul 17 05:38:33 karki_, here Jul 17 05:38:35 did you get covered by it in the process? Jul 17 05:38:37 :D Jul 17 05:39:57 almost :) Jul 17 05:43:54 panto : hi Jul 17 05:44:12 I wanted to talk about the JIT implementation! Jul 17 05:45:06 If I know how the jit is to be done, I can work my way around what I want to do now, keeping in mind the JIT additions later on. Jul 17 05:46:27 ok Jul 17 05:46:47 there are various level's of jit-iness Jul 17 05:47:23 as it is right now you're doing bytecode execution Jul 17 05:48:31 and you have a loop that goes through the instructions one by one and executes them Jul 17 05:49:45 yes Jul 17 05:50:07 and it happens to be very slow :( Jul 17 05:50:40 well, the PRU is not a general purpose cpu architecture Jul 17 05:51:00 have you measured how much time each instruction execution takes? Jul 17 05:51:33 not really, but the toggle speed without delay came up to 300khz, which is surprisingly slow Jul 17 05:51:38 if I had to guess the amount of leg-work done dwarfs the amount of time spend executing the real instructions Jul 17 05:52:30 but as of now all inst are being read from the memory, could that be a reason for slowness? Jul 17 05:52:45 yes, that's quite slow as well Jul 17 05:53:02 past a link to the sources please to take a look Jul 17 05:53:51 https://github.com/deepakkarki/pruspeak/blob/master/src/pru-firmware/pru0_firmware.c Jul 17 05:54:44 panto : the comment block at line 528 has the old implementation. Jul 17 05:55:04 yeah Jul 17 05:55:36 reading from memory is slow but that's not the problem Jul 17 05:56:06 I can't think why it is going slow? Jul 17 05:56:10 there is no -o3 flag Jul 17 05:56:15 during compilation Jul 17 05:56:22 it's the amount of code that has to execute until you get to the point to execute Jul 17 05:56:32 PRU has no caches, and is non-pipelined Jul 17 05:56:59 can you disassemble the object file and put it on pastebin? (pru0_firmware.o) Jul 17 05:57:18 how do you dissassemble? Jul 17 05:58:21 dispru Jul 17 05:58:53 ok :) Jul 17 06:03:15 panto : https://gist.github.com/deepakkarki/6043479524162dc73247 Jul 17 06:05:38 look at something as simple as the goto handler Jul 17 06:06:38 I'm looking Jul 17 06:07:22 each of those instructions takes 1cycle to execute Jul 17 06:07:46 yeah, 5ns Jul 17 06:08:12 and goto is the simplest instruction Jul 17 06:08:22 if you take a look at if it's even worse Jul 17 06:09:32 so let's go back to jit Jul 17 06:09:40 okay :) Jul 17 06:10:01 but is there anyway to minimise the number of inst in the goto, if handler Jul 17 06:10:11 there is Jul 17 06:10:25 but you won't get that much of an optimization Jul 17 06:10:34 at most you'll get it to run twice as fast Jul 17 06:10:52 so the problem is not with my style of coding? Jul 17 06:11:05 there is no problem per se Jul 17 06:11:15 your code is perfectly fine Jul 17 06:11:20 well... that is always a problem but that is not the problem you are looking at ;) Jul 17 06:11:31 even if it's a little bit inefficient Jul 17 06:11:47 it is real time right? the timings are consistent Jul 17 06:12:03 there's no jitter -> real time performance Jul 17 06:12:15 yes Jul 17 06:12:17 there is a misconception that says real-time equals to fast Jul 17 06:12:27 that's not the case, it means consistent Jul 17 06:12:40 now, let's go back to the jit Jul 17 06:12:47 ko! Jul 17 06:12:50 ok! Jul 17 06:13:51 if you take a look at a fragment of bot-speak code it would look something like this (pseudo code) Jul 17 06:14:00 set_dio(0, 1) Jul 17 06:14:06 set_dio(1, 0) Jul 17 06:14:10 wait(50) Jul 17 06:14:12 I disagree with that definition of RT Jul 17 06:14:20 ds2, oh? Jul 17 06:14:21 RT means predictable Jul 17 06:14:50 yeah, consistency is predictable Jul 17 06:15:05 * panto <- not native speaker, some times it shows Jul 17 06:15:07 you can have consistancy w/o predictability Jul 17 06:15:30 they are slightly different Jul 17 06:16:16 yeah Jul 17 06:16:44 ok, let's go back to the jit example Jul 17 06:16:55 :) Jul 17 06:17:21 assume that the calls above were having the same prototypes in C code of the PRU Jul 17 06:17:50 and instead of reading the bot-speak instructions you included them in your program Jul 17 06:18:08 void bot_speak() { set_dio(0, 1); set_dio(1, 0); wait(50); } Jul 17 06:18:34 what would happen if you defined set_dio() & wait() as either inline functions or macros? Jul 17 06:18:44 ah, okay! so there is some sort of a template beforehand Jul 17 06:19:11 don't rush, there's still issues remaining :) Jul 17 06:19:16 :p Jul 17 06:20:06 what do you mean what would happen? (the inline functions and macros thing) Jul 17 06:20:41 you mean instead of a normal call? Jul 17 06:20:42 what would the effect be on the bot_speak() function having this content? compared to running the bytecode interpreter Jul 17 06:20:59 nothing really Jul 17 06:21:03 wrong Jul 17 06:21:27 a number of things happen Jul 17 06:21:36 other than the fact it'll be faster Jul 17 06:21:41 1. There is no function call/return overhead Jul 17 06:22:18 faster cause you don't really have to fetch and interpret an inst! huge +point Jul 17 06:22:26 there is more Jul 17 06:22:55 2. there are a number of constants in the function calls - that means that the compiler is free to remove all the conditional logic that doesn't apply Jul 17 06:23:39 3. there is less need for temporary variables after all that; it is quite probable that no stack will need to be setup and everything will fit in registers Jul 17 06:24:59 :) Jul 17 06:26:08 well, I do have one question. How will we handle single commands that can come in while a script is executing? Jul 17 06:26:29 wait again Jul 17 06:26:51 this is what we'd do if we would compile the botspeak firmware each time with a C compiler Jul 17 06:31:08 and this JITed code, it runs on PRU0? Jul 17 06:35:13 ugh, got disconnected Jul 17 06:35:15 karki_, what was the last thing you've read Jul 17 06:36:55 panto : this is what we'd do if we would compile the botspeak firmware each time with a C compiler Jul 17 06:37:20 what we need to do is assemble PRU assembly fragments in ARM, stitch together the equivalent PRU code and pass it off to the PRU to execute Jul 17 06:37:28 think about what this means :) Jul 17 06:37:37 so instead of passing the bot-speak bytecode, you pass pre-compiled, optimized (hopefully) PRU code chunks Jul 17 06:37:44 and also try to find out information about how the davlik android java jit works :) Jul 17 06:37:54 wonder if there is enough room to put in all the op-code support in PRU IRAM Jul 17 06:38:02 then use the debugger interface to run each op-code Jul 17 06:38:32 I don't know Jul 17 06:38:46 ok, got to take off now :) Jul 17 06:38:49 l8rs Jul 17 06:38:54 panto : when next? Jul 17 06:39:54 karki_, read about davlik Jul 17 06:40:03 cool! Jul 17 06:40:05 sure Jul 17 11:16:52 evening all Jul 17 11:17:46 things are looking a little better now, will be fully back in action by this weekend Jul 17 11:42:04 KumarAbhishek : how are you handling buffer overflow during streaming in BeagleLogic? Jul 17 13:04:15 karki: I set an error sysfs attribute and add an entry to the kernel logs Jul 17 13:06:03 thanks Jul 17 13:06:59 I could have aborted the transaction but instead decided to let the operation continue and just let the user know that an error had occurred Jul 17 13:12:14 yeah, that seems like a clean choice :) Jul 17 14:17:55 hmm... suddenly hot plugging ftdi devices completely crashes windows... thanks for the great os microsoft! Jul 17 14:18:35 <_av500_> thank intel for USB too Jul 17 14:18:51 yup Jul 17 14:19:23 I mean these things have only been in development for decades, of course they're not going to work yet Jul 17 14:19:28 <_av500_> I had USB hang Linux kernels too Jul 17 14:19:50 at least you can tell what's going on when it happens in linux Jul 17 14:20:17 the "solutions" for problems like this on windows tend to be "oh, just reinstall windows, it fixes everything!" Jul 17 16:35:53 alexanderhiam : Normally throwing the PC out of the "window" solves the problem with windows ;) Jul 17 16:36:21 * karki_ has a short temper, he almost did that once :p Jul 17 16:36:37 unfortunately this one also has my main linux partition on it Jul 17 16:36:43 or else I might Jul 17 16:38:29 * vvu tries to dream that in the future he will have a job that will require to use linux. Jul 17 16:42:25 oh btw karki_, I must insist that you revice the opcode naming in you pru firmware, the difference between SET_DIO_a and SET_DIO_b isn't at all clear Jul 17 16:43:14 yeah..... Jul 17 16:43:20 * alexanderhiam is a stickler for friendly naming Jul 17 16:43:22 ;) Jul 17 16:43:25 * karki_ is terrible at naming things Jul 17 16:44:08 worth a watch: https://www.youtube.com/watch?v=FvzdONIqDJ8 Jul 17 16:44:11 * karki_ named his cat "meow meow"; shows how good he is at naming stuff Jul 17 16:45:34 well cats are a different story Jul 17 16:45:58 mine's Moondog Jul 17 16:46:18 always confuses the vet Jul 17 16:46:45 ds2: how is it going? Jul 17 16:47:30 alexanderhiam : you don't even want to know what I named my hamsters :p Jul 17 16:47:47 amaze us karki_ Jul 17 16:47:58 ;) Jul 17 16:48:18 gold flake and snow flake Jul 17 16:48:33 *flake Jul 17 16:49:34 then they had baby hamsters, the babies are called son-1 son-2, daughter-1..... etc :/ Jul 17 16:51:23 my function's naming convention is slightly better :D Jul 17 16:51:47 ^ that did not come out right Jul 17 16:52:04 irc logs are forever Jul 17 18:19:07 hey alexanderhiam Jul 17 18:28:13 panto: why would one see “Override Board Name,00A0,Override Manuf,BB-BONE-PRU-05” in my slots ?? can’t find what it means exactly Jul 17 19:48:59 hey DiegoTc Jul 17 19:49:34 hey alexanderhiam, wondering if you did the svg Jul 17 19:49:35 for checking it Jul 17 19:51:01 DiegoTc: I started on it, haven't had a chance to finish yet though Jul 17 19:51:37 I'll work on it more in the next couple days and let you know Jul 17 19:51:50 ok, thanks alexanderhiam **** ENDING LOGGING AT Fri Jul 18 03:00:00 2014