16:16 <ysionneau> Ralf from RTEMS is proposing to drop RTEMS support of lm32 arch because "the corresponding toolchain is in rather unusable shape with no improvements in sight"

16:17 <ysionneau> I can't blame him for thinking that

16:17 <ysionneau> Nobody is working on lm32 gcc support?

16:19 <ysionneau> and if nobody is, who could? I think someone at least tried to work on lm32 gcc ...

16:20 <ysionneau> maybe he can resume his work and do something about it

16:20 <ysionneau> before lm32 support is dropped from everywhere because of this toolchain nightmare

16:22 <lekernel> 4.5 works well enough for most practical purposes ...

16:22 <lekernel> including rtems, afaict

16:24 <lekernel> I tried to have it fixed, but all I could get was a 36k$ quote for "having a look at the situation" before doing any actually useful work :-)

16:25 <ysionneau> 17:22 < lekernel> 4.5 works well enough for most practical purposes ... < I agree

16:26 <ysionneau> but other projects supporting several arch and 1 toolchain don't want to stay stuck at old gcc just because of lm32

16:26 <ysionneau> I guess that's their issue

16:26 <ysionneau> or they just don't want to maintain 2 sets of patches for 2 gcc versions

16:26 <ysionneau> something like that

16:27 <ysionneau> except this $36k quote, nobody here (or on the ML) was working on gcc to fix it?

16:27 <lekernel> personally, I have more than enough work supporting LM32 projects that are bare metal; and for those, 4.5 works correctly enough

16:28 <lekernel> you can even run Lua or Ruby ...

16:28 <ysionneau> yes I knew you didn't have the time for that, you are already doing a lot :)

16:28 <ysionneau> and you don't need RTEMS anymore anyway

16:29 <ysionneau> I could try to contact Jörn Rennecke from Embecosm

16:29 <ysionneau> maybe he would accept to do some work on lm32 gcc for free

16:30 <ysionneau> he is a gcc expect

16:30 <ysionneau> expert*

16:30 <lekernel> I can perhaps find a bit of funding, but not $36k

16:30 <ysionneau> embecosm is helping a lot openrisc, they might agree on helping a bit lm32 :)

16:31 <ysionneau> and compiler is their expertise field

16:31 <ysionneau> that's exactly what lm32 need and that's exactly what they are good at

16:31 <ysionneau> I will try to contact him I think, maybe he would accept to help

16:32 <ysionneau> before contacting him I will try to gather some information about what is wrong in the first place

16:32 <ysionneau> to have something to explain :)

16:33 <ysionneau> I bet modern gcc does not even compile for lm32 target

16:34 <lekernel> last time I checked it compiled, and then segfaulted immediately when you compiled anything with it, with an infinite recursion loop

16:35 <lekernel> which also happens when the gcc build scripts themselves run it

16:37 <ysionneau> hum :( bad bad bad

16:37 <ysionneau> but simple enough to explain !

16:45 <larsc> I'll take a look for 34.9k$, no problem ;)

16:48 <ysionneau> ahah

16:48 <ysionneau> I could as well ... :p

16:48 <ysionneau> but no result guarantee

16:57 <davidc__> are you set on GCC? (IE, would an LLVM-based toolchain work as well?)

16:59 <ysionneau> I almost never used llvm stuff, but I would blindly accept the fact that it's much better

16:59 <ysionneau> though as not all project switched yet to clang, I would really like anyway to have modern gcc working for lm32

16:59 <ysionneau> I would like both gcc and clang support :)

17:00 <ysionneau> davidc__: you want to work (or are working?) on clang for lm32?

17:01 <davidc__> ysionneau: no; more that I'm vaguely interested at poking at LLVM backends

17:01 <davidc__> :)

17:04 <ysionneau> ok :)

17:13 <lekernel> davidc__, have you had a look at JB Bonn's existing work?

20:13 <qwebirc27866> I have written a D flip-flop (just for learning migen) http://pastebin.com/7dHy0jr0

20:14 <qwebirc27866> On the verilog output, I can see the reset section

20:14 <qwebirc27866> if (sys_rst) begin Q <= 1'd0; Qi <= 1'd0;

20:14 <davidc__> qwebirc27866: Qi = Signal(reset=1)

20:15 <davidc__> qwebirc27866: or Qi.reset = 1

20:16 <qwebirc27866> Thanks a lot!

20:16 <davidc__> or, rather than defining two regs holding D + ~D (Q and Qi), define one reg Q holding D, and then combinatorially define Qi

20:16 <davidc__> IE, self.comb += Qi.eq(~Q)

20:16 <qwebirc27866> hm... yes thats correct

20:17 <davidc__> either is essentialy correct; assuming proper use of sys_rst

20:21 <qwebirc27866> "assuming proper use of sys_rst" did you mean Qi = Signal(reset=1) ?

20:22 <davidc__> qwebirc27866: if you don't assert sys_rst somewhere, with the synchronous design, the D ff could be in an invalid state

20:22 <davidc__> qwebirc27866: or it could be in an invalid state prior to asserting sys_rst

20:25 <qwebirc27866> What are these lines which I get when I wrte a combinational logic ?

20:26 <qwebirc27866> synthesis translate_off reg dummy_s; initial dummy_s <= 1'd0;

20:26 <davidc__> qwebirc27866: IIRC bugfixes for simulation

20:26 <davidc__> qwebirc27866: they don't actually cause generation of real logic

20:27 <davidc__> qwebirc27866: (the synthesis translate off helps with that; and since its not actually connected to anything, it gets dropped)]

20:27 <davidc__> qwebirc27866: I think its to workaround sim bugs

20:28 <lekernel> it's to run the "always @(*)" blocks once at the beginning

20:28 <lekernel> otherwise, signals that are driven combinatorially in such a block (as opposed to using assign) have undefined values at startup

20:29 <lekernel> verilog is super annoying

20:30 <lekernel> those dummy signals generate an event at startup in the sensitivity list of those blocks, and so get them to run

20:30 <davidc__> see lekernel's answer- he knows verilog better than I

20:33 <lekernel> a cleaner way to solve this problem would be to compute the initial results of the always @(*) blocks, and assign those values to the affected signals in a "initial" block or using "reg x = y;" declarations

20:34 <lekernel> but this requires full evaluation/process running support in Migen, and it doesn't have this at the moment (we might want it to support simulations without instances better and faster; at this point we can get rid of the dummy signal hack easily)

20:39 <qwebirc27866> @lekernel: What are the future development plans for Migen ?