<azonenberg> lekernel: hi
<lekernel> hi
<azonenberg> I see you saw my latest test pattern, any thoughts?
<azonenberg> http://i.imgur.com/nsrQk.png is a lossless PNG version
<azonenberg> top right and top center of http://i.imgur.com/RQ1lO.png is the actual mask layout
<azonenberg> at ~600 DPI
<azonenberg> ready to be printed and reduced 40x onto the wafer
<lekernel> well, I don't know.
<lekernel> but it does look good and I'm eager to see what it's going to do on silicon :-)
<azonenberg> Lol me too
<azonenberg> Payday was thursday so i'm in the process of ordering blank wafers etc
<azonenberg> within a month i should be starting fab runs
<azonenberg> But in the meantime i'm killing time by doing mask design
<azonenberg> The plan for this mask is, stick the bottom (red) mask in
<azonenberg> Line up so that the horizontal axis is parallel to a <111> plane and roughly center it on the die
<azonenberg> Expose and etch
<azonenberg> Then do the second level on to pof that
<azonenberg> Align the central cross
<azonenberg> Expose, develop, etch
<azonenberg> And then use the vernier scales etc to see how close I got
<azonenberg> to perfect alignment
<azonenberg> In addition, the squares made out of parallel lines below the cross are there to test how well double etches turn out
<azonenberg> io, hole on top of hole and peak on top of peak
<azonenberg> Each etch will probably be a micron or so deep
<azonenberg> Which is about a minute in 30% KOH at 80C
<azonenberg> well actually that'd be 1.25um but close enough for testing, i just need it deep enough to see edges clearly
<Fallenou> which gcc are you using ATM ? 4.5.1 ? 4.5.2 ? 4.5.3 ?
<Fallenou> I am working a little bit on my lm32-rtems-gcc portfile for Mac OS
<Fallenou> my current version is 4.5.1
<Fallenou> I am wondering if I should update
<kristianpaul> gcc versión 4.5.2 (GCC)
<kristianpaul> I'm usign xiangfu's script
<Fallenou> kristianpaul: is this the version lekernel is using ?
<Fallenou> because rtems has a 4.5.3 version in its ftp
<lekernel> yes, i'm using 4.5.2
<Fallenou> lekernel: why not 4.5.3 ?
<Fallenou> just not tested yet ?
<Fallenou> or some reason
<lekernel> the rtems rpm's do not have the divider and sign extender enabled multilibs, and ralf is super anal about this, so i'm not using them
<lekernel> besides, 4.5.2 works fine
<Fallenou> I am not refering to their rpms
<Fallenou> but to their source tarballs
<lekernel> same ... it needs a little patch
<Fallenou> hum ok
<Fallenou> I guess I will stick with 4.5.2 then
<Fallenou> OK will put this patch in addition to their patch
<lekernel> I have fixed this in gcc svn, but now 4.6 is totally broken for lm32 ...
<lekernel> it's a mess
<Fallenou> hum ok :/
<Fallenou> if I add the divide and sign extension, will it still be compatible with lm32_evr ?
<lekernel> the only reasonable outcomes I see are (a) switch to llvm or (b) maintain a gcc fork (e.g. 4.4 which has working c++)
<lekernel> yes of course
<Fallenou> maitaining something has a big cost, especially if it's gcc ^^
<lekernel> not if you stick to the "if it's not broken do not touch it" rule
<lekernel> there's little innovation in gcc anyway
<Fallenou> hum ok so you would not backport gcc features into your fork
<lekernel> what features?
<lekernel> the only remotely interesting one is google go
<lekernel> wrt lm32, the newer gcc releases have mostly brought regressions
<Fallenou> oh really ?
<lekernel> yeah, c++ doesn't work anymore for example
<lekernel> in all 4.5.x
<Fallenou> :/
<Fallenou> I don't know if C++ is really a good choice for embedded applications
<lekernel> it could definitely work on large embedded systems like mm
<Fallenou> lekernel: you use newlib 1.19 or 1.18 ?
<lekernel> I don't know ... try 1.19?
<xiangfu> I am using 1.19
<xiangfu> Fallenou: what I can do/test on newlib-1.19?
<kristianpaul> at least works :-)
<Fallenou> no idea, really
<xiangfu> lekernel. so you think better fork gcc? if fix those problem will needs a lot of time in gcc 4.6 ?
<xiangfu> lekernel I know nothing about gcc code. never look into it. just asking.
<lekernel> xiangfu: if you want to mess with the compiler, try to write a lm32 llvm backend
<lekernel> but this is low priority anyway
<lekernel> I've tried to track down the current 4.6 problem, took an afternoon and gave up
<lekernel> it's mess
<kristianpaul> may not a mess at all, just we born in different ages than gnu/gcc people? :-)
<xiangfu> maybe I can try complain those bugs to gcc mailing list first : http://www.milkymist.org/wiki/index.php?title=GCC_bug_list :D
<lekernel> oh, don't bother
<lekernel> no one really cares about lm32 except us
<lekernel> probably you just won't get an answer
<lekernel> but we don't really need those bugs fixed anyway...
<xiangfu> hmm.. seems (a) switch to llvm  needs a lot of works: 1. write code 2. maintaining the code.
<kristianpaul> sh*t
<kristianpaul> two days lost because a forgot to initialize a counter !!
<kristianpaul> :/
<xiangfu> (c) fix bug in gcc 4.6 needs: 1. fix bug 2. keep eyes on gcc
<kristianpaul> s/a/i
<xiangfu> (b) maintain a gcc fork (e.g. 4.4 which has working c++). but we will far away from 'upstream' at someday, some new libs will not compiled someday :(
<Fallenou> lekernel: do we need multilib support ?
<Fallenou> I think we just need one libgcc with our settings
<lekernel> not really, if you can only build the library with all the CPU features enabled it's fine for our purposes
<Fallenou> yep ok
<Fallenou> I have some troubles compiling right now
<Fallenou> maybe you will understand
<Fallenou> arg ok i'm missing ppl (cloog)
<Fallenou> damn
<CIA-51> flickernoise: Sebastien Bourdeauducq master * re8509ad / src/keymap.c : No need to make curr_layout static - http://bit.ly/mgJ1Ak
<CIA-51> flickernoise: Sebastien Bourdeauducq master * r7b6d091 / src/keymap.c : Remove irrelevant comment - http://bit.ly/j1sUlv
<CIA-51> flickernoise: Sebastien Bourdeauducq master * r4629cc2 / src/flash.c : Cosmetic - http://bit.ly/lOpEMo
<CIA-51> flickernoise: Sebastien Bourdeauducq master * r2452c7c / src/flash.c : Coding style - http://bit.ly/kSYPL1
<CIA-51> mtk: Sebastien Bourdeauducq master * r7ce0056 / lib/userstate.c : Use new key codes for repeat - http://bit.ly/jDArW4