| wpwrak | let's see what scale factor i have to apply ... | 00:00 |
|---|---|---|
| wpwrak | hmm .. about 300. so with better supported gcc, the all the compilations together should take roughly 200 ms. plus file system delays, whatever they are | 00:08 |
| kristianpaul | wow | 00:09 |
| wpwrak | the problem with the scanner is that it uses strcmp a LOT. this seem to be made worse by strcmp not being a built-on, so you get a function call each time | 00:12 |
| wpwrak | well, let's be conservative and say about 500 ms. definitely under 1 s. | 00:15 |
| kristianpaul | si bad comparate two strings a LOT? | 00:18 |
| kristianpaul | if you do that too often you mean you need something else elaborate instead (a library) ? | 00:19 |
| wpwrak | you need a tokenizer :) | 00:19 |
| wpwrak | and a decent data structure for the identifiers | 00:19 |
| wpwrak | well, you can skip the tokenizer and just do the data structure. that's the key thing. | 00:20 |
| wpwrak | then each strcmp(foo, bar) becomes foo != bar | 00:21 |
| wpwrak | initialization may be a bit of a problem, because there are quite a lot of pre-defined items. so it would be good to do this only once, not for each individual compilation run. (actually, i need to see if this isn't already happening) | 00:22 |
| kristianpaul | (foo != bar) that seems to speed up :) | 00:24 |
| wpwrak | yeah, it usually does. particularly if strcmp isn't a built-on :) | 00:24 |
| wpwrak | (built-in = carefully optimized inline function) | 00:24 |
| wpwrak | actually, there's a low-hanging fruit ... lemme try something | 00:25 |
| wpwrak | let's see if the critter still runs after that hack ... | 00:28 |
| wpwrak | hmm, no big difference. how peculiar. | 00:32 |
| wpwrak | *hmm* where does libbase get installed ... ? | 00:36 |
| wpwrak | well, anyway ... time to brag a little about the scheduler | 00:41 |
| wpwrak | ah no, it does seem to use a builtin for strcmp. hmm. | 00:56 |
| evildaemon | Is it possible to use (Read: test) FNP in Linux? | 02:19 |
| wolfspra1l | wpwrak: yes, excellent work! | 02:21 |
| wolfspra1l | sounds like we can include it upstream right away... | 02:22 |
| wolfspra1l | I think the BOOTP delay is stuck because the SoC cannot detect cable presence right now, or something like that | 02:22 |
| wolfspra1l | if I got the details wrong, bear with me ;-) | 02:22 |
| wpwrak | wolfspra1l: thanks ! :) | 02:25 |
| wpwrak | (upstream) maybe after a little bit of cleanup. not sure how people feel about all the aborts and asserts i have in there. in theory, you should never hit them, but ... | 02:25 |
| wpwrak | (e.g., an abort would mean that the FPVM code generator has failed) | 02:26 |
| wpwrak | (bootp) even if we don't have carrier detection, why do we need to set up networking before FN runs anyway ? can't RTEMS just run this in parallel ? | 02:27 |
| wpwrak | evildaemon: i think you can run it under qemu. but i don't know the details. | 02:34 |
| evildaemon | (By the way, the reason I ask is that this link is broken for me: http://milkymist.org/msd/) | 02:35 |
| evildaemon | Which is the link to the binaries on the flickernoise page, in case that needed clarification. | 02:36 |
| wpwrak | i think this is the new location: http://milkymist.org/updates/ | 02:42 |
| evildaemon | Hmmm, wouldn't this mean the website needs to be updated? | 02:44 |
| evildaemon | (Which is ironic, considering the name of the directory.) | 02:44 |
| wpwrak | i think xiangfu is taking care of that. if you find a place that still refers to msd/, please tell him | 02:44 |
| wpwrak | (ironic) yeah ;-) | 02:45 |
| evildaemon | I did, here is he? | 02:45 |
| evildaemon | *where | 02:45 |
| wpwrak | probably enjoying the weekend :) | 02:50 |
| wolfspra1l | which website? | 02:56 |
| wolfspra1l | I don't think xiangfu has exclusive access anywhere, I'm pretty sure about that actually :-) | 02:56 |
| wolfspra1l | because even if he would, I would open up that access right away | 02:57 |
| wolfspra1l | xiangfu is traveling a bit over the Chinese October holidays, so he may be online once in a while the next 2 weeks or so, over expensive 3G | 02:57 |
| wolfspra1l | evildaemon: which website/url is out of date? | 02:58 |
| evildaemon | http://milkymist.org/flickernoise.html At the bottom, under source code. | 02:58 |
| wolfspra1l | I'm not sure whether xiangfu has access to that, but for sure lekernel does | 03:00 |
| Action: evildaemon is glad he turned off noscript to try his hand at using # to point to the source code heading. The "still hesitating" box is one of the better ways I've seen to make advertising...addictive. | 03:04 | |
| wolfspra1l | evildaemon: he, sorry cannot follow | 03:08 |
| wolfspra1l | you mean the 'still hesitating' box on milkymist.org ? | 03:08 |
| wolfspra1l | and that won't show up with noscript, but then you turned noscript off and tried # (?) | 03:08 |
| wolfspra1l | don't understand | 03:08 |
| wolfspra1l | which browser do you use? | 03:09 |
| wolfspra1l | (I'm asking because I need to think about some ways to market/advertize M1, in friendly ways...) | 03:09 |
| evildaemon | I was praising it. | 03:10 |
| evildaemon | And pointing out that I would have never noticed it if i didn't try doing: http://milkymist.org/flickernoise.html#source-code (Which didn't work.) | 03:11 |
| evildaemon | If that's still a "WTF?" ignore the first sentence, and focus on the praise. | 03:13 |
| wolfspra1l | got disconnected, will check the backlog :-) | 03:16 |
| evildaemon | Anyway, it's projects like this that make me wish I needed them. (Or had a large amount of disposable income.) | 03:32 |
| wolfspra1l | evildaemon: you could help us tremendously by just spreading the word | 03:48 |
| wolfspra1l | about what Milkymist is, what is can do today, what it hopefully can do tomorrow, etc. | 03:48 |
| wolfspra1l | s/what is/what it/ | 03:48 |
| wolfspra1l | also even if you don't have the hardware, you can do a lot of good stuff with qemu. of course trying on real hardware is more fun... | 03:49 |
| wpwrak | lots more :) | 03:51 |
| wolfspra1l | evildaemon: what do you like about Milkymist? | 03:51 |
| kristianpaul | parallel, i think rtems suport threads, xiangu told thats implemented in the rss wall code if i remenber well, but to be honest i'm not using rtems since long, seema bare metal gcc-lm32 plus a hacked mm1 bios is just enought for me rigt now | 06:16 |
| wpwrak | keeping things easy ;-) | 07:49 |
| wpwrak | naw, RTEMS must have concurrency. after all, you have the shell where you can do things while the rest boots. | 07:49 |
| lekernel | wpwrak, regarding your comment about atof: there is no double support in demo firmware/BIOS, only float | 09:08 |
| lekernel | you'll probably find that printf is funny as well | 09:08 |
| lekernel | I did that in 2008-ish when all that stuff had to be crammed into one little block RAM array, and didn't feel the need to update it since then | 09:09 |
| wpwrak | "demo firmware" = flickernoise ? | 09:16 |
| wpwrak | does the build that runs on the M1 actually use libbase ? i haven't quite figured out how this gets involved. when i look at the headers that get #included, they look very non-libbase-ish | 09:17 |
| lekernel | no, the small proof of concept renderer that comes with mm soc | 09:19 |
| lekernel | without rtems | 09:19 |
| wpwrak | so i get the rater odd scenario of the M1 build, where I could imagine a reason for needing libbase, apparently not using libbase, but the native x86-64 build, where I have a perfectly good libc, needing libbase to get make all the includes work. so i'm a little confused ;-) | 09:19 |
| wpwrak | (demo) oh, i see. one more item i don't know yet :) | 09:19 |
| lekernel | libbase is only used for the BIOS on prod devices | 09:20 |
| lekernel | all the rest uses rtems libc | 09:20 |
| wpwrak | one way to solve the atof problem could be to just give it a different name. then there wouldn't be a conflict with ANSI C and any "real" libc. | 09:20 |
| lekernel | I don't see what kind of conflict you run into? | 09:20 |
| wpwrak | aah, i see. then i need to go over my build process again | 09:21 |
| lekernel | if your atof() returns a double instead of a float, the compiler should nicely convert it into float | 09:21 |
| lekernel | unless you include the libbase headers, which you shouldn't do when building on a system with a libc already | 09:22 |
| lekernel | the only libbase header that libfpvm should need is version.h | 09:23 |
| wpwrak | yeah, i get the libbase headers. don't remember why, but it didn't compile without them | 09:23 |
| lekernel | maybe because of version.h? | 09:23 |
| wpwrak | possibly. i need to check this again | 09:24 |
| wpwrak | libbase also screws up my libc profiling. one more reason to be rid of it :) | 09:24 |
| lekernel | nah but just don't use it. it's only for systems without libc. | 09:24 |
| wpwrak | ah, this is where i get it from: software/include.mak:INCLUDES=... | 09:28 |
| wpwrak | which in included by software/libfpvm/Makefile | 09:29 |
| wpwrak | s/in/is/ | 09:29 |
| wpwrak | waiting for the russian hinterlands to reconnect ... ;) | 09:30 |
| wpwrak | welcome back ! ;-) | 09:35 |
| wpwrak | (regarding libbase) ah, this is where i get it from: software/include.mak:INCLUDES=... | 09:35 |
| wpwrak | which in included by software/libfpvm/Makefile | 09:35 |
| wpwrak | so i guess i should just override INCLUDES ? | 09:35 |
| lekernel | mh, maybe we should move version.h to another folder | 09:35 |
| lekernel | software/libfpvm/Makefile is only for building for demo firmware | 09:36 |
| lekernel | use e.g. the x86-linux subfolder instead | 09:36 |
| lekernel | evildaemon, fixing that link, moment | 09:37 |
| wpwrak | ah, that looks a bit more sane | 09:38 |
| wpwrak | btw, why CC=clang ? | 09:38 |
| lekernel | the less GNU software I use, the better I feel | 09:40 |
| lekernel | GCC should die and be replaced with LLVM or PCC | 09:41 |
| wpwrak | ;-)) | 09:41 |
| wpwrak | dunno. gcc has served me well so far. | 09:41 |
| wpwrak | now, let's kill libbase ... | 09:44 |
| lekernel | wpwrak, so, what name should I use for your new shiny scheduler? | 09:45 |
| lekernel | right now we hava GFPUS for Greedy Floating Point Unit Scheduler | 09:45 |
| lekernel | WFPUS ? | 09:45 |
| wpwrak | oh, i thought it came from GPU ;-)) | 09:46 |
| lekernel | evildaemon, link fixed, thanks for reporting | 09:46 |
| wpwrak | qfpus for quick ... no, q almost looks like g, too confusing | 09:47 |
| wpwrak | wfpus sounds like "wumpus" :) | 09:48 |
| wpwrak | maybe "r" for "rapid" or, even though a bit lame, "n" for "new" ? | 09:50 |
| lekernel | LNFPUS? ('lamely named') | 09:51 |
| wpwrak | hehe ;-) | 09:51 |
| wpwrak | "Lean New" :) | 09:51 |
| wpwrak | i would just call it sched.c, but i can see how that might cause confusion with the task scheduler | 09:52 |
| lekernel | we can keep multiple schedulers in libfpvm ... | 09:54 |
| wpwrak | yup, that would be an option. at least while experimenting. | 09:55 |
| wpwrak | ah, and you always want to turn on optimization (LCPF). it increases total run time by about 40 ms (at the moment that would be 1%), but produces significantly better code | 09:57 |
| wpwrak | not sure if you saw that one: | 10:03 |
| wpwrak | ah, and you always want to turn on optimization (LCPF). it increases total run time by about 40 ms (at the moment that would be 1%), but produces significantly better code | 10:03 |
| lekernel | yes, got it :) | 10:03 |
| wpwrak | but let me first clean up my sched.c a little more. there's also one kind of dependency LCFP doesn't consider (write-write) when computing the path length. have to see if that has any effect. | 10:04 |
| wpwrak | oh, and when does it make sense to not define PRINTF_FLOAT ? another bios/demo quirk ? | 10:08 |
| lekernel | yes | 10:09 |
| lekernel | you would love this :) | 10:09 |
| lekernel | in C variadic functions always promote float arguments to double | 10:10 |
| lekernel | it's a compiler built in and there's no way to disable it (with gcc at least) | 10:10 |
| lekernel | since doubles do not work with BIOS/demo, the workaround this macro controls is passing pointer to floats to printf() | 10:10 |
| lekernel | (ofc the tweaked printf() implementation also expects such pointers when it sees %f) | 10:11 |
| wpwrak | urgh :-( | 10:12 |
| wpwrak | i think the promotion to double is even ANSI C standard. checking ... | 10:12 |
| lekernel | yes I think it's in some standard | 10:12 |
| wpwrak | yes, K&R 2n Ed. A.7.3.2 | 10:14 |
| wpwrak | you could avoid all that mess in gcc with -fshort-double (well, you then wouldn't be compatible with libc, but that shouldn't matter at this point) | 10:17 |
| lekernel | ah? I didn't find that option when I looked for it... | 10:17 |
| wpwrak | or just support double in the bios/demo :) | 10:17 |
| lekernel | yeah well | 10:18 |
| lekernel | this is old code and I had other priorities | 10:18 |
| lekernel | yes, we have a large flash and sdram now, and we can easily add double support | 10:18 |
| wpwrak | do you even still use the demo ? if not, perhaps dropping support for it would be the easiest way to sanity | 10:20 |
| lekernel | yes, I used it recently to do some performance tweaking when trying to increase resolution | 10:20 |
| lekernel | I think it's still useful because it's straightforward to hack into when experimenting | 10:21 |
| wpwrak | okay. no gordian solution then :) | 10:22 |
| wpwrak | hmm. to install a profilinc libc, aptitude wants to downgrade libc if i tell it i have lucid or upgrade it if i tell it i have maverick. do i trust this ? :( | 10:40 |
| wpwrak | the upgrade does look clean .. nothing else affected, it says. now, do i trust THAT ... ? | 10:41 |
| wpwrak | well, no risk no fun. let's do it :) | 10:41 |
| wpwrak | grmbl. hitting more binutils/libc/gcc compatibilities. does anyone ever test profiling ? :-( | 10:55 |
| wpwrak | s/compat/incompat/ | 10:55 |
| lekernel | bbl... thanks for your work on pfpu wpwrak :) | 11:12 |
| cde | kikoo | 11:43 |
| cde | hey wolfspraul :) | 12:44 |
| wolfspraul | cde: hi | 13:00 |
| cde | how are you? | 13:02 |
| cde | so, http://projects.qi-hardware.com/schhist/mmone-jtag-serial-cable/pdf_usb_jtag.pdf is 404 :( | 13:07 |
| xiangfu | cde, http://projects.qi-hardware.com/schhist/m1-jtag-serial/pdf_head/usb_jtag.pdf | 13:12 |
| xiangfu | cde, where you get this link? we should fix it. | 13:12 |
| xiangfu | cde, you can check the history here: http://projects.qi-hardware.com/schhist/m1-jtag-serial/ which is very cool. | 13:13 |
| cde | from http://en.qi-hardware.com/wiki/Milkymist_JTAG-serial_daughterboard | 13:13 |
| cde | thanks | 13:13 |
| cde | GND on the CMOS chip in pin 5 right ? (Vss) | 13:13 |
| cde | and pin 1 is chip select | 13:14 |
| Action: cde wishes he had his SOIC test clip at home | 13:15 | |
| xiangfu | fixed. you can also edit them with out register user | 13:17 |
| cde | cool thanks | 13:18 |
| cde | so btw, I do get an error message in Windows, says the USB device has malfunction and that it could not recognize it | 13:20 |
| xiangfu | cde, (pin 1, 5) the U1 you mean? you want reflash your jtag board? | 13:23 |
| xiangfu | cde, have you tried it under Linux? | 13:23 |
| cde | hmm shorting chip select doesn't seem to help | 13:23 |
| cde | well I'm justing trying wolfspraul's advice | 13:24 |
| cde | btw, is the USB JTAG board compatible with the Flyswatter ? | 13:25 |
| xiangfu | cde, oh. I remember that. | 13:25 |
| cde | see http://www.tincantools.com/product.php?productid=16134, both feature an FTDI and this 14-pin JTAG header so I thought they might be compatible | 13:25 |
| xiangfu | (Flyswatter) don't know that. for Windows you can check this: http://www.milkymist.org/wiki/index.php?title=Update_JTAG_firmware_on_Windows | 13:26 |
| xiangfu | I mean this page: http://www.milkymist.org/wiki/index.php?title=JTAG_windows_driver | 13:26 |
| cde | btw, "never hot-plug the daughterboard, both Milkymist One and daughterboard need to be powered off when they are being connected" | 13:27 |
| cde | I think I did exactly that :( | 13:27 |
| cde | that's probably how I damaged the daughterboard, thanksfully the M1 seems unharmed | 13:28 |
| xiangfu | cde, that one JTAG should be compatible. only the serial port is different. | 13:28 |
| cde | that's very cool! I'm going to try it, if it works wolfspraul won't have to send me a replacement board | 13:29 |
| xiangfu | cde, you may need a RS232 <--> TTL convert for get more info from serial console. | 13:30 |
| xiangfu | cde, yes. try JTAG first :) | 13:30 |
| cde | hmm it has this 243EC with does TTL<->RS232 so my pl2303 cable should do just fine, in theory | 13:33 |
| cde | damn, both are male RS232 connectors | 13:33 |
| Action: cde hates RS232 | 13:33 | |
| wolfspraul | cde: ah, now I know who cde is :-) | 13:45 |
| wolfspraul | you hot-plugged jtag-serial, hmm | 13:45 |
| wolfspraul | well, on one hand I tend to stay away from easy 'too good to be true' explanations | 13:46 |
| wolfspraul | of course we can always say "that was it" | 13:46 |
| wolfspraul | then maybe if it was indeed the source of the problem, we should add a warning label somewhere? | 13:47 |
| wolfspraul | "don't hotplug jtag-serial" ? | 13:47 |
| wolfspraul | or on the silkscreen somewhere | 13:47 |
| wolfspraul | whether you find a replacement or not, it's sure that I will mail a new jtag-serial board to you so your m1 is complete and original | 13:51 |
| wolfspraul | I don't think I need the old one back, it's not worth the effort | 13:51 |
| wolfspraul | we blame 'hotplugging' until we know better :-) | 13:51 |
| cde | ok :) | 14:47 |
| wolfspra1l | cde: what's the latest status? | 14:55 |
| wolfspra1l | jtag works with your other board? | 14:56 |
| cde | oh, I didn't try that yet | 14:56 |
| cde | at least it should be electrically compatible, the USB JTAG daughterboard is 3.3V right ? | 14:56 |
| wolfspra1l | don't want to say anything wrong ;-) | 15:00 |
| wolfspra1l | I would think so, yes. but double-check elsewhere... I'm not positive right now. | 15:01 |
| cde | argh, not going to work, pin spacing is different (larger on the flyswatter), it doesn't fit :( | 15:01 |
| cde | I have like three different JTAG cables right now, each for a different board... | 15:03 |
| cde | btw, it would be very nice to have a small hole in the casing for the USB cable to go through | 15:04 |
| roh | usually one doesnt need jtag. | 15:11 |
| roh | thats why there is no hole | 15:11 |
| cde | yes. it's not a big deal anyway, and I can always drill a hole myself ;) | 15:14 |
| roh | well.. i could provide pre-cut sidepanels.. but so far you are the first to ask | 15:16 |
| cde | don't worry. I'll probably reflash very rarely anyway | 15:17 |
| cde | and there is always the flickernoise way | 15:18 |
| kristianpaul | dam gcc 4.6.1 freezed my system when compiling for lm32 :/ | 19:04 |
| wpwrak | how did it do that ? :) do you have swap enabled ? | 20:46 |
| kristianpaul | yes i have swap | 20:49 |
| kristianpaul | i dont know | 20:49 |
| kristianpaul | last thing i remenber was music stoped and linux start killing processes | 20:50 |
| kristianpaul | and happened twice, i'm compiling 4.5.2 right now | 20:50 |
| wpwrak | sounds like running out of memory | 20:57 |
| kristianpaul | 1Gb ram 1.7Gb swap, first time happens :) | 22:11 |
| kristianpaul | nice, 4.5.2 finished compilation OK | 22:13 |
| wpwrak | tiny :) | 22:32 |
| wpwrak | a while ago, i noticed on my 8 GB system that i didn't have swap enabled. apparently, i had been running without it for months without noticing ;-) | 22:33 |
| --- Sun Sep 25 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!