sh4rm4 has quit [Remote host closed the connection]
sh4rm4 has joined #milkymist
rejon has joined #milkymist
Jia has joined #milkymist
xiangfu has joined #milkymist
xiangfu has quit [Ping timeout: 248 seconds]
jimmythehorn has joined #milkymist
cladamw has joined #milkymist
xiangfu has joined #milkymist
<cladamw>
wpwrak, hehe ... tks for fixing the drills image. :-)
<wolfspraul>
good morning everybody :-)
<kristianpaul>
hi
cladamw has quit [Quit: Ex-Chat]
rejon has quit [Ping timeout: 252 seconds]
<kristianpaul>
lekernel: also imagine your new memory controller is generated by a script/such, will allow more people to use it without get caught by all migen ;-))
<kristianpaul>
dont know havent check, perhaps this still doable right now
<kristianpaul>
for example nasa, to they use whole soc? or just memory controller?..
<kristianpaul>
i hope i make my point and open opinion to you about migen :)
<stekern>
can't you just use migen to generate the verilog for one core?
<kristianpaul>
i guess yes
<kristianpaul>
not sure for the memory controller part
<wolfspraul>
it seems migen is the thing that will fragment milkymist into a bunch of buggy 1-person projects :-)
<wolfspraul>
soon we are ready for inclusion in opencores, all parts :-)
* kristianpaul
dont want that...
<wolfspraul>
maybe that's not a bad thing, and we can also find more things to use/reuse from opencores...
<kristianpaul>
+1 for reuse
<wolfspraul>
more or less everybody will patch up his own system in different ways anyway then
<wpwrak>
yeah, irrespective of technical merit, i see that risk with migen, too
cladamw has joined #milkymist
<kristianpaul>
patch up is good, if a solid base is agreed
<kristianpaul>
and maintained
<wpwrak>
cladamw: regarding the review, i haven't forgotten :)
<cladamw>
wpwrak, aha ... thanks you. take your time though. :-)
<wpwrak>
cladamw: making the proper catalogs for all the items is taking a bit more time than i thought. and i've been "away" for a while for that led torch project. sorry about that.
<wpwrak>
cladamw: i hope i'll catch up with the cataloging tools in the next days. then the reviews should be relatively straightforward.
<wpwrak>
unless there are surprises, of course :)
<cladamw>
wpwrak, no problem. no sorry. :-)
<stekern>
I think I just discovered a bug in the lm32 llvm backend, byval function arguments aren't handled correctly
<stekern>
they are just passed by reference, but not copied to the stack of the caller function
<cladamw>
(led torch) wpwrak sounds you kept working improvements from previous one?
<wolfspraul>
what's the *real* status of llvm btw?
<wolfspraul>
for lm32/milkymist
<wolfspraul>
my understanding is there are 2 compilers, gcc and llvm
<wolfspraul>
gcc is buggy but maybe or maybe not some people are fixing those bugs?
<wolfspraul>
and we seem to be using that compiler? or is 'we' only a very small number of people anyway?
<wolfspraul>
I never used it :-)
<wolfspraul>
then there is llvm, which has 'some' degree of lm32 support?
<wolfspraul>
how many people are using that?
<wpwrak>
stekern: "byval" that would be pretty much all function arguments ?
<wolfspraul>
if one of the two is better, shouldn't we focus on that and then make it work well?
<wolfspraul>
it seems we have two buggy and not really loved compilers
<wpwrak>
i don't dislike gcc. on the other hand, i'm suspicious about llvm :)
<stekern>
wpwrak: yes, but in LLVM IR "byval" is used to mark that (for example) a pointer parameter really should be passed by value
<stekern>
s/(for example)/
<wolfspraul>
we probably have 2-3 people that are actively using gcc for lm32
<wolfspraul>
and how many for llvm? 1? 2?
<wpwrak>
for all the lm32-independent stuff, one has to work with gcc pretty much all of the time anyway
rejon has joined #milkymist
<wpwrak>
stekern: ah, i see. so it's just an llvmism ?
<wpwrak>
stekern: i.e., if i pass a struct, nothing evil will happen ?
<stekern>
if you pass it as a non-pointer, evil might happen
<wpwrak>
stekern: all i need to see is the memcpy, which looks very appropriate there ;-)
<stekern>
wolfspraul: I wouldn't call it "using", but since I'm working on the openrisc backend and their ISAs are pretty similar, I've took a peek or two at it
<stekern>
wpwrak: yes, that's what missing in the llvm/clang output ;)
<wolfspraul>
maybe we should delete the milkymist soc v1 sources to accelerate migen/-ng adoption?
<wpwrak>
the dark force is strong in this one
jimmythehorn has quit [Quit: jimmythehorn]
rejon has quit [Ping timeout: 245 seconds]
wolfspraul has quit [Ping timeout: 245 seconds]
wolfspraul has joined #milkymist
wolfspraul has quit [Client Quit]
wolfspraul has joined #milkymist
wolfspraul is now known as Guest34622
Guest34622 has quit [Client Quit]
wolfspra1l has joined #milkymist
rejon has joined #milkymist
<wolfspra1l>
btw, I think I hit a little roadblock with fpgatools
<wolfspra1l>
the routing is a real maze
<wolfspra1l>
so I will go one step back, and work on a model of the chip (rather the routes) in C first
<wpwrak>
that's what routing is about :0
<wolfspra1l>
that model will create a memory-representation of the routing which I will verify by dumping it into an svg
<wolfspra1l>
not sure where this is going but I need something visual and something with more logic as can be expressed in C
<wolfspra1l>
since I am flooded with papers here and wild drawings :-)
<wolfspra1l>
printed papers :-)
<wolfspra1l>
that's reached an end
<wpwrak>
some amount of backtracking is to be expected in that line of work ;)
jimmythehorn has joined #milkymist
xiangfu has quit [Ping timeout: 255 seconds]
xiangfu has joined #milkymist
cladamw has quit [Quit: Leaving]
xiangfu has quit [Ping timeout: 264 seconds]
xiangfu has joined #milkymist
cladamw has joined #milkymist
cladamw has quit [Quit: Ex-Chat]
<Fallenou>
05:19 < wolfspraul> maybe we should delete the milkymist soc v1 sources to accelerate migen/-ng adoption? < wow I don't think that's necessary :)
<Fallenou>
wolfspra1l: we all used a lot lm32 gcc, to compile lm32-linux, rtems, flickernoise
<Fallenou>
wolfspra1l: I think at some point Milkymist bios was compiled with clang (llvm)
<Fallenou>
and then with gcc and maybe back with clang I don't know
<wolfspra1l>
which of the two compilers do you like better?
<Fallenou>
and from now on I think lekernel is using clang only for -ng bios
<Fallenou>
wolfspra1l: I have no experience with clang :/
<Fallenou>
sorry
<wolfspra1l>
feels like another fragmentation to me
<Fallenou>
I would say from a religious point of view I would prefer a working clang/llvm than a working gcc
<wolfspra1l>
but I have used neither myself, so I may just not know
<wolfspra1l>
can we build the entire m1 image with clang/llvm or are lots of things missing?
<Fallenou>
but gcc is a "strong" project. it existed for years
<Fallenou>
so I kind of trust this one
<Fallenou>
but it would be great if we could replace it with clang :)
<Fallenou>
linux people are trying to replace gcc with clang too
<Fallenou>
BSD people too
<Fallenou>
pkg-src too
<Fallenou>
gotta run to the office, bbl
<wolfspra1l>
sure if clang/llvm really works and can fully replace gcc, that sounds great
<wolfspra1l>
but until proven otherwise, I will assume it doesn't :-)
<larsc>
guilty until proven innocent?
<wolfspra1l>
yep
<wolfspra1l>
defendant has to prove innocence himself
<lekernel>
wolfspra1l: the -ng bios and the firmware (including lua, freetype, yaffs, etc.) compiles with clang
<stekern>
I'd say clang really works and can fully replace gcc if you don't rely to heavily on some gcc attributes (most of those are "hackaroundable" though), I don't know how the situation is for the lm32 parts though
<lekernel>
kristianpaul: yes, you can generate only one core with migen
<lekernel>
there are few disadvantages to using it... except that people don't look at it and still comment negatively
<lekernel>
a bit the same with clang, heh
<lekernel>
wolfspra1l: and sorry, but soc is almost a 1-person project already. also, the main contribs were the on-chip debugger (which stays in verilog in -ng), some USB stuff (likely, will also stay in verilog), and some C firmware (which are not affected by migen or even clang).
<Jia>
may I ask if I keep working on lm32-gcc is OK?
<wolfspra1l>
you said you would send a fix :-) did you do that?
<Jia>
wolfspra1l: I've summit a patch to gcc-patches :-)
<wolfspra1l>
great
<Jia>
and cc to lekernel
<wolfspra1l>
what's the effect of it?
<lekernel>
Jia: I prefer clang/llvm, but anything that makes software run better on lm32 is good.
<wolfspra1l>
does 4.6/7/later work now?
<wolfspra1l>
c++ also?
<Jia>
wolfspra1l: the libgcc bug, 4.8 trunk work now.
<wolfspra1l>
maybe xiangfu should try to build the entire m1 image with that?
<lekernel>
Jia: have you compiled and tested software with that?
<Jia>
wolfspra1l: C++ not yet.
<wolfspra1l>
I don't want to break down "compiler works" into this or that little library or bios or what not - can't handle that
<Jia>
OK, I'll try.
<wolfspra1l>
so either it works completely (better than before), or not at all
<wolfspra1l>
xiangfu: you there?
<xiangfu>
yes
<wolfspra1l>
maybe you can try the latest gcc 4.8 with jia's fixes and see how much works?
<wolfspra1l>
and let's include C++ in the test right away
<xiangfu>
ok
<wolfspra1l>
Jia: what's wrong with C++? can we continue with that?
<Jia>
wolfspra1l: I didn't know C++ has problem, if you need, I'll keep working on it.
<wolfspra1l>
definitely we 'need' that :-)
<lekernel>
xiangfu: sent you the patch
<Jia>
and, how can I work on lm32-clang?
<wolfspra1l>
is more like dying in the desert without water type of need
<lekernel>
Jia: you can try compiling the linux kernel... it's a good way to tickle clang/llvm bugs and problems
<xiangfu>
lekernel, thanks. got that email.
<wolfspra1l>
nobody will take a platform seriously where all the core devs together (whatever they may be focused on) cannot fix a C++ compiler bug for years
<Jia>
I'll try to catch your step.
<wolfspra1l>
even Itanium probably has more life in it :-)
<wolfspra1l>
and no, I stay away from C++ as much as possible
<lekernel>
wolfspra1l: I guess there are lots of C++ haters here ;)
<wolfspra1l>
but our inability to fix that kind of bug looks bad for the platform
<lekernel>
btw C++ support in clang is pretty encouraging
<wolfspra1l>
that's besides the point, I think c++ is a horrible disaster, nightmare
<lekernel>
also objective-c
<wolfspra1l>
but the fact that 'we' cannot fix that type of bug in the entire platform for years is quite telling to an outsider
<Jia>
gobjc is very old, and to die :-)
<wolfspra1l>
so if Jia slowly gets up to speed, maybe he can fix that as well :-)
<Fallenou>
09:46 < lekernel> Jia: I prefer clang/llvm, but anything that makes software run better on lm32 is good. < +42
<wolfspra1l>
that would be awesome
<wolfspra1l>
of course ideally we want both gcc *and* llvm to work fully and completely and out of the box for everything
<wolfspra1l>
I also still write letters to santa claus
<lekernel>
oh cmon
<wolfspra1l>
:-)
<wolfspra1l>
I'll add perfect gcc and llvm support on the next one :-)
<wolfspra1l>
Jia: thanks for your support!
<Jia>
wolfspra1l: my pleasure
<wolfspra1l>
let's see how far xiangfu gets with that latest compiler
<wolfspra1l>
I want to see that it really works, and reflash my m1 with the result
* Fallenou
is back
* xiangfu
update local gcc now. then try to patch, compile , compile..
<Jia>
lekernel: if I wanna working on llvm/clang, should I clone the git repo and...?
<xiangfu>
Jia, your patch is base on latest 'master' branch of gcc. right? just for double make sure.
<xiangfu>
Jia, merge your script file to this Makefile. add another target, like: make gcc-trunk
<Jia>
I'll try
kristianpaul has quit [Ping timeout: 272 seconds]
kristianpaul has joined #milkymist
<kristianpaul>
did my email about 5bit csr support arrive?
rejon_ has joined #milkymist
<wpwrak>
kristianpaul: the one with the patch ?
<wpwrak>
kristianpaul: or a reply to sebastien's one line rejection of the 1000+ lines patch ? :)
<kristianpaul>
lol yeah, just got email this morning
xiangfu has quit [Remote host closed the connection]
<kristianpaul>
wpwrak: 1000+ lines is bad?
<Jia>
wolfspraul: sorry, newlib make failed.
<wpwrak>
for harcoded constants, yes. you could have made it a parameter.
<Fallenou>
kristianpaul: does your patch have a downside ?
<Fallenou>
I mean increasing the csr id width
<kristianpaul>
a bit more routing i guess
<Fallenou>
does it decrease something else ?
<kristianpaul>
dont think so, or not realized yet
<kristianpaul>
anyway i just wanted to be there, my early atempt was even more mesier :)
<lekernel>
the increased resource usage should be minimal
<lekernel>
but (a) this needs testing against regressions (small mistakes can easily slip through in such code) (b) the preferred way for customized SoCs is to use -ng
<kristianpaul>
testing yes
<kristianpaul>
but is your prefered way lekernel
<lekernel>
seriously, adding a core to the system including DMA and such is 2-3 lines instead of a big mess
<kristianpaul>
yes..
<lekernel>
I can't see how you'd defend the old method
<kristianpaul>
I dont
<kristianpaul>
a parser we need :)
<kristianpaul>
or small tools as wpwrak quoted yday
<lekernel>
migen is a small tool
<lekernel>
if you only use the bus interconnect generator it's what? 1.5k lines?
<wpwrak>
what's not nice about migen is that it acts as a portal instead of a tool. to use migen, you have to do things "inside" migen. you can't just have your regular verilog and call migen when there's something tricky to do
<lekernel>
well you can - it's just that it's not done this way
<lekernel>
so this criticism should be for milkymist-ng, not migen :)
<kristianpaul>
exactly !, tought i will get confused and think are the same
<lekernel>
how would you like it to be?
<lekernel>
and what advantage would it have?
<wpwrak>
the (for the user) nicest but hardest to implement way would be an enhancement of the verilog language. so you'd preprocess regular verilog and only respond to specific migen constructs/directives.
<wpwrak>
now, perhaps that can be done without having to actually parse verilog
Jia has quit [Quit: Konversation terminated!]
<wpwrak>
e.g., if the task can be reduced to inserting blocks of things at specific places, you could simple have directives that do this.
<wpwrak>
or maybe have a mixture - parse the parts of verilog you have to, leave the rest alone
<lekernel>
generally, it can't be reduced to inserting blocks at specific places
<wpwrak>
the things migen does that need a language like python could then live either in separate files or be inlined. e.g., the whole memory bus system could probably be abstracted to a point where you'd have a "memory bus generator" that then makes the bits and pieces
<wpwrak>
for naming ? or does it also have to transform operations ?
Gurty has joined #milkymist
<lekernel>
the dataflow system does some transforms, yes
<lekernel>
also there are things like generic components that export abstract CSRs
<lekernel>
and the CSRs from those components can be combined into the CSR area of a peripherals
<lekernel>
one example is the generic interrupt controller that cores can include and map in their CSR area
<wpwrak>
and you can't just break the abstract CSRs down to pieces you insert at the right places ?
<lekernel>
??
<lekernel>
like #include ?
<lekernel>
this makes it uglier, not nicer
<wpwrak>
well, think of it as #include for now
<wpwrak>
or maybe #include(param, ...) :)
<wpwrak>
we can worry about making it pretty later :)
<lekernel>
the current way to do it is call get_registers() on the interrupt controller object, which returns the list of abstract registers, and concatenate it with own registers and pass the result to the CSR interface generator
<lekernel>
this is much clearer I think than macros
Jia has joined #milkymist
<wpwrak>
maybe you could express this as a set of migen "modules" you request somewhere early in the verilog ? then you add the respective include directives (or maybe have your parser find the corresponding places automatically)
<lekernel>
but why should it be based on verilog? I don't think it's such a better language than python...
Hodapp has quit [Ping timeout: 252 seconds]
<lekernel>
here you can even call into python libraries e.g. to pre compute DSP coefficients
<wpwrak>
it's one of the languages people who do this sort of things are most likely to know
Hodapp has joined #milkymist
<lekernel>
or even read C include files and retrieve the address at which peripherals should be mapped
<wpwrak>
and if they run into trouble, they have to fall back to verilog anyway
<lekernel>
not much more than they have to fall back to netlist when using verilog ...
<kristianpaul>
languge not at all, perhaps a easy to read config file is a good start too
Jia has quit [Read error: Connection reset by peer]
<wpwrak>
for DSP coefficient, in C you would do this simply by running a script/program that writes a file you can #include. people don't even bother to write C-with-Python-or-whatever-overlay preprocessors for tasks like this.
hypermodern has joined #milkymist
<kristianpaul>
wpwrak: could bison for example parse config files ans generate verilog from that?
<lekernel>
ok, but it's easier to do when you already have that system
<kristianpaul>
i havent never used bison, just thinking...
<wpwrak>
kristianpaul: bison generates C. but you can generate pretty much any parser that makes sense (*) with bison. and then your parser does whatever you want your parser to do :)
<lekernel>
kristianpaul: I recommend you try writing a simple wishbone slave core using verilog (since you like it that much), and add it in -ng. then we talk.
<kristianpaul>
why you insist on -ng ..
<wpwrak>
(*) it reaches its limits with ambiguous grammars. e.g., where you only find out late that a previous parsing decision was wrong.
<kristianpaul>
and yes i have some slace core in my gps branch
<lekernel>
kristianpaul: because, among many other things, your 1000-line patch would be reduced to about 2 lines :)
<kristianpaul>
of course your atitude is not open to suguestions anyway ng will be another one person project..
<lekernel>
I'm open to suggestions, but only after people have tried the stuff they are commenting on
<kristianpaul>
so why you insist on -ng so much? lets wait other year then anothe repo will be deleted from history?
<kristianpaul>
well
<lekernel>
not just a vague "it's over engineering", especially right after sending a messy patch that exemplifies how one problem is better solved with migen
<Fallenou>
I think you are too hard on migen
<wpwrak>
you have a point there ;-)
<kristianpaul>
yeah
<wpwrak>
but my first reaction wouldn't have been "migen" but "parameters" ;-)
<Fallenou>
I find it really cool so far, but my opinion does not weight much since I have almost never used it
<Fallenou>
I used it to generate the the soc.v I am using for my MMU simulations
<Fallenou>
and it worked fine
<Fallenou>
but indeed the kristianpaul patch is a really good example of what happens without migen : thousand lines for a simple change
<lekernel>
wpwrak: well, to be honest, VHDL would have solved it (with packages) as well
<Fallenou>
but yes, migen is most about data flow than having parametrazable CSR
<Fallenou>
this is the real value of migen, the token thing
<Fallenou>
and python object language
<wpwrak>
Fallenou: cristianpaul's patch illustrates mainly what happens if you hard-code constants all over the place. so he took something that had problems and didn't try to solve these problems, even though the problems should have become rather noticeable after the first few hundred changes :)
<wpwrak>
maybe he just tried to be polite :)
<Fallenou>
well ok CSR thing is just not the good example for migen advertisment :)
<kristianpaul>
still wishbone arbiter :)
<Fallenou>
but I still think migen is awesome :D
<lekernel>
well, migen does provide a very decent parameter system :)
<lekernel>
of course, if you reduce it to only that, it's over engineering
<kristianpaul>
fore sure it does.. but as in gnu and autotools i dont want to be trap in migen and ng ;-)
* kristianpaul
troll
<wolfspraul>
we need a credible path for everybody to move forward and adopt migen
<wolfspraul>
and I don't think we try to build such a path right now
<wolfspraul>
so there's just this great migen, if you don't understand how great it is you are an idiot and will be left behind
<wolfspraul>
of course that won't work :-)
<wolfspraul>
I work my way bottom up, verilog first - even that is quite high-level for me :-)
<kristianpaul>
and obscure (verilog) if we remenber the synthesis tools are/still closed source...
<lekernel>
if you consider that migen only emits a subset of verilog without too many of the annoying corner cases, it has a little point there ;)
aeris has quit [Ping timeout: 244 seconds]
aeris has joined #milkymist
Jia has joined #milkymist
<lekernel>
Jia: is there any other patch?
<lekernel>
for 4.6.3
<Jia>
I can make one for you, one minute
<lekernel>
please send it to devel@lists.milkymist.org
<Jia>
OK, but more time, I;m not using the git tree, just tarball
<Jia>
maybe 10 minutes is OK
<lekernel>
sure
<lekernel>
thanks!
<Jia>
networking is slow...
<lekernel>
great firewall people manually reviewing your data?
<Jia>
I hate GFW!
<Jia>
maybe they review my code and give me some comments:)
<Jia>
I hope they can help me fix the bug
<larsc>
hehe :)
<larsc>
always think positive
<Jia>
just kidding:)
<Fallenou>
could we expect small performance improvement in generated assembly using new gcc 4.6.3 ?
* Jia
is not sure...
<lekernel>
I don't think so, this is more about having a strong and up to date toolchain...