IRC logs for #openrisc Thursday, 2016-05-12

--- Log opened Thu May 12 00:00:02 2016
SMDwrkHi, everyone. I glimpsed at mor1kx verilog code and I have to ask(disclaimer: I'm not good rtl coder at all) has it been done that way on purpose?07:27
stekernI guess it depends what you refer to with "that way" ;)07:29
SMDwrkI'm confused with alu and decoder parts: they seem a bit messy and are hard to read07:32
SMDwrkOr maybe I don't see the whole picture07:34
SMDwrkI.e. if you have time, please, take a look at my approach with mips cpu: - that's sort of decode thing in mor1kx07:35
stekernwell, apart from extensive use of tick-define macros, it's not terribly different from:
stekern(+ or1k has a bit messy instruction encoding...)07:39
SMDwrkYep, I'm confused that there is a output for every existing opcode(decode_op_div_o, decode_op_jr_o, etc)07:41
stekernthat is on purpose, otherwise you will have to further "decode" down the pipeline07:42
mithroKind of a weird question. If I have say a 20bit to 20bit lookup table, is there an way to work out an efficient minimal implementation of the table?07:44
SMDwrkstekern: Ok then, and another question: alu, which executes most of things in parallel and then correct result is chosen upon operation wires, is better than giant switchcase based on "alu opcode"?07:50
SMDwrkGiant mux is not a good idea though07:50
ZipCPU|LaptopSMDwrk: What's wrong with a giant mux?  In RTL, you are stuck with doing every operation anyway, what's wrong with just selecting the correct answer from among the possibilities?07:55
SMDwrkZipCPU|Laptop: I mean giant mux is smth like so selecting correct answer could be a good idea07:57
ZipCPU|LaptopAre you suggesting that approach, or suggesting against it?07:59
SMDwrkZipCPU|Laptop: actually I'm not suggesting but asking what's better and why08:00
ZipCPU|LaptopNot sure I have a good answer for you.  They both look roughly equivalent to me, save that I don't see anything switching on the clock in the OpenRISC code.  That's got to be elsewhere.08:04
SMDwrkIn my case there should be let's say 32 way mux while in orisc one it could be 8 way. There is mul/div working on the clk and fpu as far as I can see. Logic and shifts are done in continuous assignments.08:10
ZipCPU|LaptopLet's see if I've captured the question well: In approach 1) all of the instructions have their own flags indicating which instruction will be done,08:13
ZipCPU|Laptopin approach 2) all instructions are done and selected between via a big case/mux statement based upon the opcode.08:14
ZipCPU|LaptopDid I capture the difference?08:14
ZipCPU|LaptopIn the case of #1, you set your self up for concurrent execution--multiple instructions can be executed at once, given that the operands are ready.08:29
ZipCPU|Laptop(I don't know if or1k does this ... anyone?)08:30
ZipCPU|LaptopIf you don't do concurrent execution, though, then you may need to maintain (via flip-flops/registers) the decoded state until you finally use it.08:31
stekernSMDwrk: part of it goes down to coding style too, you could construct your alu opcode to be onehot to achieve the same result08:46
stekernI largely used the same style when I did this:
stekernwhich is a lot simpler than mor1kx08:48
SMDwrkOk, thanks!09:00
ZipCPU|Laptopstekern: Were you the one who had worked on the pipelined ECO32?  I heard it was only partially successful.  Can you tell me if it ever fully worked?09:42
stekernthe link above is to a pipelined version of eco3209:43
stekernit worked enough to boot linux at least09:43
shorneolofk: wallento: looking at the g++ virtual construction, I traced it down to __do_global_ctors_aux, I believe the virtuals should be contructed in here. But the constructor list in my binary is empty. Looking into more details.09:45
ZipCPU|Laptopstekern: Can you tell me whether all of the instruction set was fully implemented?09:47
stekernas far as I remember, yes09:48
stekernat least as it was defined at that point in time09:48
stekernI don't know if there has been any changes/additions since then09:48
ZipCPU|LaptopOkay.  I had just heard something different from Hellwig, that his last student had not been able to complete a pipelined version and so the project was ongoing and still needing to be completed.09:48
stekernah, that's probably a seperate story, I was never a student of Hellwig09:50
ZipCPU|LaptopNo wonder.  That explains things then.09:52
wallentoshorne: is that newlib specific10:01
wallentobecause at this time we used uclibc because of c++ support10:01
wallentoWe needed to compile a bulky kernel (FIASCO.OC microkernel)10:01
shornewallento: I was thinking it might be10:22
wallentookay, I am not sure about c++ in newlib at all to be honest10:23
wallentoI will try the example with the musl toolchain10:23
wallentobut anyways, you are right, it is probably not related10:23
shorneI need to try the whole thing with musl too10:24
shorneneed to build musl10:24
olofkshorne: Sorry for not being more helpful. Been a lot on my plate lately, but I'll help you out when I get the time10:42
olofkBut not with the c++ stuff. That stuff is just too weird :)10:42
shorneNo worries, hopefully after this I can get back to the dma controller stuff10:43
olofkYeah. That would be great too10:46
olofkBut this reg testing has been great as it revealed several bugs in other components too. We should perhaps file some bugs before we forget about them10:47
olofkBut of course, we still have everything recorded in the grand OpenRISC documentation database at :)10:47
olofkNote to future olofk: We need to implement the rest of the reentrant functions in newlib, find out why sys/mman.h is missing, fix the c++ virtual stuff, understand why gdb-python isn't always enabled10:49
olofkshorne: Building musl was pretty straight-forward last time I tried.10:51
olofkHmm.. wallento. You removed the build instructions from opencores wiki, and I can't find them now10:51
wallentowhich one?10:52
wallento(the idea of the wiki is that you can see the old version in the history by the way ;)10:53
wallentooh, the musl toolchain10:54
wallentoit has moved, but was not completed apparently:
wallentoI will complete now10:54
wallentothe link is here:
olofkThe old instructions are here in the meantime
wallentosneak peak: clone the repo and run build.sh10:56
shorneolofk: the build is in progress, it seems straight forward enough no failures yet11:01
shornewallento: clone and build is what I did11:02
olofkwallento: Great. One less dependency on opencores12:58
wallentoolofk: yeah, that was my ambitious plan with deleting stuff13:03
wallentoonly legacy stuff should remain :)13:04
olofkwallento: Yeah, I've been meaning to do the same for quite some time. Just got a bit suprised when I couldn't find the instructions at the new site13:07
SMDwrkwhat's wrong with btw?13:20
olofkSMDwrk: Lack of maintenance makes it hard to rely upon. We have already lost the bug tracker and the mailing list13:46
SMDwrkoh, then, as I've already suggested, I can share my 16 amd cores workstation: you could loose something there tooo14:00
olofkSMDwrk: Yes. We're grateful for the offer. Unfortunately we don't have any ready workloads to run there right now :/14:26
shorneneed some work to get gdb working woth or1k-linux-musl (the traps are not implemented)
shorneI think most can come from the newlib implementations. I need to see what though17:35
shorneIll, get back to that later. I think this c++ thing should work, olofk's test ran with newlib and it worked. SOmething is wrong on myside/myversion Ill try to bisect it17:45
shorneolofk: Can you check one thing on your testsuite, there should be a file ./gdb/testsuite/outputs/gdb.cp/virtfunc/virtfunc18:21
shorneCan you run or1k-elf-objdump -s ./gdb/testsuite/outputs/gdb.cp/virtfunc/virtfunc | grep -C5 '\.ctors'18:21
shornefor me I get:18:21
shorneContents of section .ctors: 32cbc ffffffff 00000000                    ........18:21
shornemeaning (no global initializers)18:22
shornebetter yet run: or1k-elf-objdump -s -j .ctors ./gdb/testsuite/outputs/gdb.cp/virtfunc/virtfunc18:36
--- Log closed Fri May 13 00:00:04 2016

Generated by 2.15.2 by Marius Gedminas - find it at!