| wpwrak | "float atof(const char *s);" ... @%*#! | 01:50 |
|---|---|---|
| wpwrak | that's why i love those systems that are almost POSIX but then, in a sudden fit of madness veer off into hell | 01:51 |
| wpwrak | on other news, the input is now identical. valgrind still thinks my code works great. hmm ... | 01:52 |
| kristianpaul | POSIX = hell ? | 01:56 |
| kristianpaul | :) | 01:56 |
| kristianpaul | really just asking, i never got a reason to follow posix yet | 01:56 |
| wpwrak | no, POSIX is good, sane. calling function "atof" that is not compatible with POSIX/ANSI C atof isn't. | 01:59 |
| wpwrak | and yes, you probably followed POSIX. it's kinda hard to write non-trivial programs without it ;-) | 01:59 |
| kristianpaul | he | 02:01 |
| kristianpaul | okay | 02:01 |
| wpwrak | let's see how fixing atof changes the comparison ... | 02:12 |
| wpwrak | (getting the numeric values of constants right affects how registers are allocated. so there will now be a bit more registers. shouldn't affect the code size, though) | 02:16 |
| evildaemon | @wpwrak Define "non-trivial" I'm sort of on that beginners journey. Knowing what you need to know really is half the battle. | 02:57 |
| wpwrak | oh, anything more demanding than "hello world" ;-) in fact, as far as i know, ANSI C is included in POSIX, so even "hello world" uses POSIX :) | 03:01 |
| evildaemon | Not if it's hello world in assembly. ;) | 03:03 |
| evildaemon | More seriously, I see your point. | 03:03 |
| wpwrak | atof is defined in ANSI C, so that prototype isn't even ANSI C-compliant. even worse :) | 03:04 |
| Action: evildaemon honestly wasn't even talking about that funcall. | 03:05 | |
| wpwrak | i kinda wonder if this is intentional or if sebastien was misled by the function's name (which is indeed not very cleverly chosen) | 03:05 |
| wpwrak | updated comparison chart: http://downloads.qi-hardware.com/people/werner/m1/perf/chart-20110923.html | 03:36 |
| wpwrak | just the number of registers has increased, by the same number (per patch) for all schedulers. thus the ranking is the same. | 03:37 |
| wpwrak | interesting: "altars of madness" uses almost all of the registers with the current scheduler | 03:38 |
| wpwrak | also aqualung doesn't have much headroom | 03:38 |
| wpwrak | interestingly, even though my unoptimized scheduler typically has the worst register allocation, it handles the pathological cases rather well | 03:43 |
| lekernel | http://arduino.cc/blog/2011/09/23/milkymist-and-arduino-a-workshop/ | 09:43 |
| larsc | haha | 09:47 |
| aeris | C'est un peu comme une expo ou serait cote à cote des twingo et des ferrarie... | 09:53 |
| lekernel | aeris, :) you're seeing it the wrong way. the workshop isn't for developers or hackers, but for artists and other creative people with little electronics knowledge | 09:58 |
| lekernel | I believe it's totally appropriate to organize such a workshop for them, especially since such people often cluelessly ask me if the M1 is based on arduino =] | 09:58 |
| aeris | Yes, it's complementary | 09:59 |
| lekernel | yeah, the arduino has a great deal of sensor interfaces (some people love this stuff) and simple software libraries to use them - we don't | 10:03 |
| lekernel | and I happily leave those to the arduino developers | 10:03 |
| wpwrak | lekernel could sell additional "IP blocks" for fancy peripherals ;-) | 11:44 |
| kristianpaul | indeed artitsts love arduino, and hopefully milkymist with good reasons now :) | 13:25 |
| wolfspraul | DJTachyon: wanna buy a Milkymist One? :-) https://sharism.cc/milkymist | 13:31 |
| wolfspraul | we have them available now, and they are great. here's a video of a recent performance http://blip.tv/problematyka/usta-concert-at-cc-summit-2011-global-party-zachta-art-gallery-5567139 | 13:32 |
| DJTachyon | heh i got the email | 13:37 |
| DJTachyon | im a bit poor right now | 13:37 |
| DJTachyon | but i want one | 13:37 |
| DJTachyon | i did just get a raise though | 13:38 |
| wolfspraul | sounds good. while you are saving, we keep improving the software :-) | 13:40 |
| DJTachyon | heheh sweet | 13:43 |
| DJTachyon | brb coffee | 13:43 |
| qi-bot | The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09232011-1903/ | 18:40 |
| wpwrak | GRRR. include/base/assert.h: #define assert(x) | 21:03 |
| wpwrak | no surprise it's so hard to reproduce the assertion violation | 21:04 |
| wpwrak | hmm, does FN really wait for something like 15 seconds for BOOTP ? | 23:48 |
| kristianpaul | boot frpm tftp? | 23:49 |
| wpwrak | i mean when i just boot it without network | 23:50 |
| kristianpaul | ah, yes there is a delay but i never measired, as i'm not booting to rtems that often | 23:51 |
| wpwrak | ;-) | 23:51 |
| wpwrak | i've heard there was such a delay in the past. but i thought it had been removed by now. seems rather useless to wait for the network by default. | 23:52 |
| wpwrak | and of course, it pretty much dominates the entire boot time ... | 23:52 |
| wpwrak | first greeting to "RTEMS SHELL", ~4.8 s | 23:53 |
| wpwrak | then ~16 s until "BOOTP call failed" | 23:53 |
| kristianpaul | now try ifconfig ;) | 23:53 |
| wpwrak | address 0.0.0.0 (of course, there's no network :) | 23:54 |
| kristianpaul | ah good | 23:55 |
| wpwrak | then ~ 2 seconds nothing (flickernoise starting/initializing ?) | 23:57 |
| wpwrak | then the patch compilation | 23:57 |
| wpwrak | patches take about 10.5 seconds with the original scheduler, about 4.0 seconds with my scheduler (doesn't really make a difference whether you optimize or not .. well, something like 20-40 ms) | 23:58 |
| wpwrak | if the scanner was a little less braindead (sorry :), the whole compilation would probably be done in half a second | 23:59 |
| --- Sat Sep 24 2011 | 00:00 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!