<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>
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.
<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?
<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>
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>
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 ;-)