<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
<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 :)
<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