<wpwrak> let's see what scale factor i have to apply ...
<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
<kristianpaul> wow
<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
<wpwrak> well, let's be conservative and say about 500 ms. definitely under 1 s.
<kristianpaul> si bad comparate two strings a LOT?
<kristianpaul> if you do that too often you mean you need something else elaborate instead (a library) ?
<wpwrak> you need a tokenizer :)
<wpwrak> and a decent data structure for the identifiers
<wpwrak> well, you can skip the tokenizer and just do the data structure. that's the key thing.
<wpwrak> then each strcmp(foo, bar) becomes foo != bar
<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)
<kristianpaul> (foo != bar) that seems to speed up :)
<wpwrak> yeah, it usually does. particularly if strcmp isn't a built-on :)
<wpwrak> (built-in = carefully optimized inline function)
<wpwrak> actually, there's a low-hanging fruit ... lemme try something
<wpwrak> let's see if the critter still runs after that hack ...
<wpwrak> hmm, no big difference. how peculiar.
<wpwrak> *hmm* where does libbase get installed ... ?
<wpwrak> well, anyway ... time to brag a little about the scheduler
<wpwrak> ah no, it does seem to use a builtin for strcmp. hmm.
<evildaemon> Is it possible to use (Read: test) FNP in Linux?
<wolfspra1l> wpwrak: yes, excellent work!
<wolfspra1l> sounds like we can include it upstream right away...
<wolfspra1l> I think the BOOTP delay is stuck because the SoC cannot detect cable presence right now, or something like that
<wolfspra1l> if I got the details wrong, bear with me ;-)
<wpwrak> wolfspra1l: thanks ! :)
<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 ...
<wpwrak> (e.g., an abort would mean that the FPVM code generator has failed)
<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 ?
<wpwrak> evildaemon: i think you can run it under qemu. but i don't know the details.
<evildaemon> (By the way, the reason I ask is that this link is broken for me: http://milkymist.org/msd/)
<evildaemon> Which is the link to the binaries on the flickernoise page, in case that needed clarification.
<wpwrak> i think this is the new location: http://milkymist.org/updates/
<evildaemon> Hmmm, wouldn't this mean the website needs to be updated?
<evildaemon> (Which is ironic, considering the name of the directory.)
<wpwrak> i think xiangfu is taking care of that. if you find a place that still refers to msd/, please tell him
<wpwrak> (ironic) yeah ;-)
<evildaemon> I did, here is he?
<evildaemon> *where
<wpwrak> probably enjoying the weekend :)
<wolfspra1l> which website?
<wolfspra1l> I don't think xiangfu has exclusive access anywhere, I'm pretty sure about that actually :-)
<wolfspra1l> because even if he would, I would open up that access right away
<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
<wolfspra1l> evildaemon: which website/url is out of date?
<evildaemon> http://milkymist.org/flickernoise.html At the bottom, under source code.
<wolfspra1l> I'm not sure whether xiangfu has access to that, but for sure lekernel does
<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.
<wolfspra1l> evildaemon: he, sorry cannot follow
<wolfspra1l> you mean the 'still hesitating' box on milkymist.org ?
<wolfspra1l> and that won't show up with noscript, but then you turned noscript off and tried # (?)
<wolfspra1l> don't understand
<wolfspra1l> which browser do you use?
<wolfspra1l> (I'm asking because I need to think about some ways to market/advertize M1, in friendly ways...)
<evildaemon> I was praising it.
<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.)
<evildaemon> If that's still a "WTF?" ignore the first sentence, and focus on the praise.
<wolfspra1l> got disconnected, will check the backlog :-)
<evildaemon> Anyway, it's projects like this that make me wish I needed them. (Or had a large amount of disposable income.)
<wolfspra1l> evildaemon: you could help us tremendously by just spreading the word
<wolfspra1l> about what Milkymist is, what is can do today, what it hopefully can do tomorrow, etc.
<wolfspra1l> s/what is/what it/
<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...
<wpwrak> lots more :)
<wolfspra1l> evildaemon: what do you like about Milkymist?
<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
<wpwrak> keeping things easy ;-)
<wpwrak> naw, RTEMS must have concurrency. after all, you have the shell where you can do things while the rest boots.
<lekernel> wpwrak, regarding your comment about atof: there is no double support in demo firmware/BIOS, only float
<lekernel> you'll probably find that printf is funny as well
<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
<wpwrak> "demo firmware" = flickernoise ?
<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
<lekernel> no, the small proof of concept renderer that comes with mm soc
<lekernel> without rtems
<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 ;-)
<wpwrak> (demo) oh, i see. one more item i don't know yet :)
<lekernel> libbase is only used for the BIOS on prod devices
<lekernel> all the rest uses rtems libc
<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.
<lekernel> I don't see what kind of conflict you run into?
<wpwrak> aah, i see. then i need to go over my build process again
<lekernel> if your atof() returns a double instead of a float, the compiler should nicely convert it into float
<lekernel> unless you include the libbase headers, which you shouldn't do when building on a system with a libc already
<lekernel> the only libbase header that libfpvm should need is version.h
<wpwrak> yeah, i get the libbase headers. don't remember why, but it didn't compile without them
<lekernel> maybe because of version.h?
<wpwrak> possibly. i need to check this again
<wpwrak> libbase also screws up my libc profiling. one more reason to be rid of it :)
<lekernel> nah but just don't use it. it's only for systems without libc.
<wpwrak> ah, this is where i get it from: software/include.mak:INCLUDES=...
<wpwrak> which in included by software/libfpvm/Makefile
<wpwrak> s/in/is/
<wpwrak> waiting for the russian hinterlands to reconnect ... ;)
<wpwrak> welcome back ! ;-)
<wpwrak> (regarding libbase) ah, this is where i get it from: software/include.mak:INCLUDES=...
<wpwrak> which in included by software/libfpvm/Makefile
<wpwrak> so i guess i should just override INCLUDES ?
<lekernel> mh, maybe we should move version.h to another folder
<lekernel> software/libfpvm/Makefile is only for building for demo firmware
<lekernel> use e.g. the x86-linux subfolder instead
<lekernel> evildaemon, fixing that link, moment
<wpwrak> ah, that looks a bit more sane
<wpwrak> btw, why CC=clang ?
<lekernel> the less GNU software I use, the better I feel
<lekernel> GCC should die and be replaced with LLVM or PCC
<wpwrak> ;-))
<wpwrak> dunno. gcc has served me well so far.
<wpwrak> now, let's kill libbase ...
<lekernel> wpwrak, so, what name should I use for your new shiny scheduler?
<lekernel> right now we hava GFPUS for Greedy Floating Point Unit Scheduler
<lekernel> WFPUS ?
<wpwrak> oh, i thought it came from GPU ;-))
<lekernel> evildaemon, link fixed, thanks for reporting
<wpwrak> qfpus for quick ... no, q almost looks like g, too confusing
<wpwrak> wfpus sounds like "wumpus" :)
<wpwrak> maybe "r" for "rapid" or, even though a bit lame, "n" for "new" ?
<lekernel> LNFPUS? ('lamely named')
<wpwrak> hehe ;-)
<wpwrak> "Lean New" :)
<wpwrak> i would just call it sched.c, but i can see how that might cause confusion with the task scheduler
<lekernel> we can keep multiple schedulers in libfpvm ...
<wpwrak> yup, that would be an option. at least while experimenting.
<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
<wpwrak> not sure if you saw that one:
<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
<lekernel> yes, got it :)
<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.
<wpwrak> oh, and when does it make sense to not define PRINTF_FLOAT ? another bios/demo quirk ?
<lekernel> yes
<lekernel> you would love this :)
<lekernel> in C variadic functions always promote float arguments to double
<lekernel> it's a compiler built in and there's no way to disable it (with gcc at least)
<lekernel> since doubles do not work with BIOS/demo, the workaround this macro controls is passing pointer to floats to printf()
<lekernel> (ofc the tweaked printf() implementation also expects such pointers when it sees %f)
<wpwrak> urgh :-(
<wpwrak> i think the promotion to double is even ANSI C standard. checking ...
<lekernel> yes I think it's in some standard
<wpwrak> yes, K&R 2n Ed. A.7.3.2
<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)
<lekernel> ah? I didn't find that option when I looked for it...
<wpwrak> or just support double in the bios/demo :)
<lekernel> yeah well
<lekernel> this is old code and I had other priorities
<lekernel> yes, we have a large flash and sdram now, and we can easily add double support
<wpwrak> do you even still use the demo ? if not, perhaps dropping support for it would be the easiest way to sanity
<lekernel> yes, I used it recently to do some performance tweaking when trying to increase resolution
<lekernel> I think it's still useful because it's straightforward to hack into when experimenting
<wpwrak> okay. no gordian solution then :)
<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 ? :(
<wpwrak> the upgrade does look clean .. nothing else affected, it says. now, do i trust THAT ... ?
<wpwrak> well, no risk no fun. let's do it :)
<wpwrak> grmbl. hitting more binutils/libc/gcc compatibilities. does anyone ever test profiling ? :-(
<wpwrak> s/compat/incompat/
<lekernel> bbl... thanks for your work on pfpu wpwrak :)
<cde> kikoo
<cde> hey wolfspraul :)
<wolfspraul> cde: hi
<cde> how are you?
<xiangfu> cde, where you get this link? we should fix it.
<xiangfu> cde, you can check the history here: http://projects.qi-hardware.com/schhist/m1-jtag-serial/ which is very cool.
<cde> thanks
<cde> GND on the CMOS chip in pin 5 right ? (Vss)
<cde> and pin 1 is chip select
<cde> wishes he had his SOIC test clip at home
<xiangfu> fixed. you can also edit them with out register user
<cde> cool thanks
<cde> so btw, I do get an error message in Windows, says the USB device has malfunction and that it could not recognize it
<xiangfu> cde, (pin 1, 5)  the U1 you mean? you want reflash your jtag board?
<xiangfu> cde, have you tried it under Linux?
<cde> hmm shorting chip select doesn't seem to help
<cde> well I'm justing trying wolfspraul's advice
<cde> btw, is the USB JTAG board compatible with the Flyswatter ?
<xiangfu> cde, oh. I remember that.
<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
<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
<cde> btw, "never hot-plug the daughterboard, both Milkymist One and daughterboard need to be powered off when they are being connected"
<cde> I think I did exactly that :(
<cde> that's probably how I damaged the daughterboard, thanksfully the M1 seems unharmed
<xiangfu> cde, that one JTAG should be compatible. only the serial port is different.
<cde> that's very cool! I'm going to try it, if it works wolfspraul won't have to send me a replacement board
<xiangfu> cde, you may need a RS232 <--> TTL convert for get more info from serial console.
<xiangfu> cde, yes. try JTAG first :)
<cde> hmm it has this 243EC with does TTL<->RS232 so my pl2303 cable should do just fine, in theory
<cde> damn, both are male RS232 connectors
<cde> hates RS232
<wolfspraul> cde: ah, now I know who cde is :-)
<wolfspraul> you hot-plugged jtag-serial, hmm
<wolfspraul> well, on one hand I tend to stay away from easy 'too good to be true' explanations
<wolfspraul> of course we can always say "that was it"
<wolfspraul> then maybe if it was indeed the source of the problem, we should add a warning label somewhere?
<wolfspraul> "don't hotplug jtag-serial" ?
<wolfspraul> or on the silkscreen somewhere
<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
<wolfspraul> I don't think I need the old one back, it's not worth the effort
<wolfspraul> we blame 'hotplugging' until we know better :-)
<cde> ok :)
<wolfspra1l> cde: what's the latest status?
<wolfspra1l> jtag works with your other board?
<cde> oh, I didn't try that yet
<cde> at least it should be electrically compatible, the USB JTAG daughterboard is 3.3V right ?
<wolfspra1l> don't want to say anything wrong ;-)
<wolfspra1l> I would think so, yes. but double-check elsewhere... I'm not positive right now.
<cde> argh, not going to work, pin spacing is different (larger on the flyswatter), it doesn't fit :(
<cde> I have like three different JTAG cables right now, each for a different board...
<cde> btw, it would be very nice to have a small hole in the casing for the USB cable to go through
<roh> usually one doesnt need jtag.
<roh> thats why there is no hole
<cde> yes. it's not a big deal anyway, and I can always drill a hole myself ;)
<roh> well.. i could provide pre-cut sidepanels.. but so far you are the first to ask
<cde> don't worry. I'll probably reflash very rarely anyway
<cde> and there is always the flickernoise way
<kristianpaul> dam gcc 4.6.1 freezed my system when compiling for lm32 :/
<wpwrak> how did it do that ? :) do you have swap enabled ?
<kristianpaul> yes i have swap
<kristianpaul> i dont know
<kristianpaul> last thing i remenber was music stoped and linux start killing processes
<kristianpaul> and happened twice, i'm compiling 4.5.2 right now
<wpwrak> sounds like running out of memory
<kristianpaul> 1Gb ram 1.7Gb swap, first time happens :)
<kristianpaul> nice, 4.5.2 finished compilation OK
<wpwrak> tiny :)
<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 ;-)