<wpwrak> "float atof(const char *s);" ... @%*#!
<wpwrak> that's why i love those systems that are almost POSIX but then, in a sudden fit of madness veer off into hell
<wpwrak> on other news, the input is now identical. valgrind still thinks my code works great. hmm ...
<kristianpaul> POSIX = hell ?
<kristianpaul> :)
<kristianpaul> really just asking, i never got a reason to follow posix yet
<wpwrak> no, POSIX is good, sane. calling function "atof" that is not compatible with POSIX/ANSI C atof isn't.
<wpwrak> and yes, you probably followed POSIX. it's kinda hard to write non-trivial programs without it ;-)
<kristianpaul> he
<kristianpaul> okay
<wpwrak> let's see how fixing atof changes the comparison ...
<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)
<evildaemon> @wpwrak Define "non-trivial" I'm sort of on that beginners journey. Knowing what you need to know really is half the battle.
<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 :)
<evildaemon> Not if it's hello world in assembly. ;)
<evildaemon> More seriously, I see your point.
<wpwrak> atof is defined in ANSI C, so that prototype isn't even ANSI C-compliant. even worse :)
<evildaemon> honestly wasn't even talking about that funcall.
<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)
<wpwrak> just the number of registers has increased, by the same number (per patch) for all schedulers. thus the ranking is the same.
<wpwrak> interesting: "altars of madness" uses almost all of the registers with the current scheduler
<wpwrak> also aqualung doesn't have much headroom
<wpwrak> interestingly, even though my unoptimized scheduler typically has the worst register allocation, it handles the pathological cases rather well
<larsc> haha
<aeris> C'est un peu comme une expo ou serait cote à cote des twingo et des ferrarie...
<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
<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 =]
<aeris> Yes, it's complementary
<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
<lekernel> and I happily leave those to the arduino developers
<wpwrak> lekernel could sell additional "IP blocks" for fancy peripherals ;-)
<kristianpaul> indeed artitsts love arduino, and hopefully milkymist with good reasons now :)
<wolfspraul> DJTachyon: wanna buy a Milkymist One? :-) https://sharism.cc/milkymist
<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
<DJTachyon> heh i got the email
<DJTachyon> im a bit poor right now
<DJTachyon> but i want one
<DJTachyon> i did just get a raise though
<wolfspraul> sounds good. while you are saving, we keep improving the software :-)
<DJTachyon> heheh sweet
<DJTachyon> brb coffee
<qi-bot> The Firmware build was successfull, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-09232011-1903/
<wpwrak> GRRR. include/base/assert.h: #define assert(x)
<wpwrak> no surprise it's so hard to reproduce the assertion violation
<wpwrak> hmm, does FN really wait for something like 15 seconds for BOOTP ?
<kristianpaul> boot frpm tftp?
<wpwrak> i mean when i just boot it without network
<kristianpaul> ah, yes there is a  delay but i never measired, as i'm not booting to rtems that often
<wpwrak> ;-)
<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.
<wpwrak> and of course, it pretty much dominates the entire boot time ...
<wpwrak> first greeting to "RTEMS SHELL", ~4.8 s
<wpwrak> then ~16 s until "BOOTP call failed"
<kristianpaul> now try ifconfig ;)
<wpwrak> address 0.0.0.0  (of course, there's no network :)
<kristianpaul> ah good
<wpwrak> then ~ 2 seconds nothing (flickernoise starting/initializing ?)
<wpwrak> then the patch compilation
<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)
<wpwrak> if the scanner was a little less braindead (sorry :), the whole compilation would probably be done in half a second