IRC logs for #openrisc Tuesday, 2018-03-20

--- Log opened Tue Mar 20 00:00:22 2018
wbxmafm[m]: hey, he just had started :P01:11
futarisIRCcloudshorne: Best of luck with the or1k-port of gcc.02:57
shornemafm[m]: only 32 now, feel free to contribute :)06:30
mafm[m]shorne: I'm kind of busy with riscv at the moment06:33
mafm[m]I din't mean to poke about it, just not sure if the openrisc specs now also work with 64-bits06:34
mafm[m]when we were working on the Debian port it was 32-bits only06:34
shornemafm[m]: the spec has 64-bit support07:33
shornebut I dont know of any cores with it07:33
shornerD[31:0] ← extz(Immediate) << 1607:34
shornerD[63:0] ← extz(Immediate) << 1607:34
shornerow 1, is 32-bit systems, row 2 is 64-bit07:34
ZipCPUshorne: Feel free to holler if you get into any CPU trouble.07:42
ZipCPUSorry, any GCC trouble.07:42
ZipCPUIt would be good for my skills to help someone else debug GCC, and I've been through that path at least once before.07:43
stekernshorne: way to go!07:47
shorneZipCPU: you might want to join #gcc over on OFTC, I have been asking a few things over there07:56
shornebut I'll echo here if I get stuck07:56
ZipCPUSure!  I've seen some of the discussions over there, I just don't check there that often.07:56
shorneIll try to send out some mails with patches for review when I get something that compiles07:56
ZipCPUCare to share where you are at in the process?07:56
shornethis is my todo list, for bootstrap07:57
ZipCPUBy "bootstrap", do you have the cross compiler working?07:57
shorne- build infra + basic files - DONE07:57
shorne- register definitions - DONE07:57
shorne- calling conventions07:57
shorne- memory layout07:57
shorne- load/store07:57
shorne- moves07:57
shorne- jump07:57
shorne- branches07:58
shorneI am working on Moves & Load/Store now07:58
shorneThen will move to calling conventions07:58
ZipCPUAhh, yes, moves and load/store's were some of the hardest problems I had to deal with.07:58
shornethere is another item for07:58
shorne  - arithmatic07:58
ZipCPUThe whole reload issue was ... quite confusing for me for some time.07:58
ZipCPUOnce you get load/store/move working, arithmetic will be easy.07:58
shornethere are a lot of other things too, like pipelines, attributes, clobbers07:59
shornebut not needed to thing about for now07:59
shorneZipCPU: and enlightening tips you have for reload,  I understand that first registers are allocated to pseudos, then for reload they try to allocate to real regstiers07:59
ZipCPUHow are you going about debugging things?  Hopefully, you've found the -fdump* series of options?07:59
shornebut then they have these flags reload_in_progress...08:00
shorneZipCPU: yes -fdump-all-all08:00
ZipCPUYeah, that reload thing *really* got me.08:00
ZipCPUSo, here's what I learned ....08:00
shorneor -fdump-rtl-all-all08:00
shorneI really dont enjoy the globals08:00
ZipCPU(Yes!) GCC commits to an instruction pattern long before it commits to registers.08:01
ZipCPUThe trick, though, in any load/store architecture is that the instructions can rarely handle the "modes" that result from reload.08:01
shorneI dont get the reload_in_progress thing yet08:01
ZipCPU(I'm getting there) "ADD" for example, can't usually read from memory.  However, GCC will commit to it long before it knows whether or not the ADD operands or result is in memory.08:02
ZipCPUload/store/move are special instructions.  They are not allowed to affect any flags (Or1k doesn't have flags, right?), and they might be added into the stream to deal with ... what's it called ... register spill?08:03
shorneor1k, has flags but not affected by load/store/move for the most part08:03
shorneatomics load/store are an exception08:04
ZipCPUSo, as I recall, the way I handled this was to place load/store/mov instructions all within the same def_insn element, and then used the flags to determine which one.08:04
shorneyes, during register allocation, if not enougn registers, a spill is needed08:04
ZipCPUThat way, when you go through reload, the instruction doesn't change .... only the eventual form of the instruction chagnes.08:04
* ZipCPU looks up what that third term was called ...08:05
shorneyes, thats what I was planning too, just one def_insn for load,store,move,load_immediate, etc08:05
ZipCPUAhh, here's the terms: predicates and constraints.08:06
ZipCPUThe rule is: predicates are used when assigning the instruction--constraints are ignored.08:06
ZipCPUconstraints are used to handle reloads08:06
ZipCPUThe trick is, following reloads, an instruction that GCC has already committed to might not match the constraints.08:07
ZipCPU(or during reloads I guess)08:07
shorneI see, yeah that is one thing that was not completely clear yet08:07
ZipCPUThe constraints are then used to guide the reloading.08:07
ZipCPUYeah ... I had to trace (debug by printf) through *a*lot* of GCC code to figure that out.08:08
shorneI did a lot of that too so far08:08
shornertl dumps, and printfs, then when I get stuck I took some time to read what is "register allocat" what is "spill" in some formal documentation08:08
shorne(not gcc docs)08:09
shornethen there is some interesting stuff with Flog Control Diagrams, and edge diagrams etc08:09
ZipCPUI spent a lot of time trying to figure out what GCC was trying to use an instruction that didn't match the predicates, only to discover that it had matched the predicates *once* and now it was ignoring those and working from the constraints only08:10
shorneI think recently they are trying to deco the 'reload' and replace with the "ira"08:10
ZipCPUYes.  I need to get into those.  Familiar with what a "basic block" is?08:10
shornebasic block is everyting between branches right?08:11
shorneI think I figured that out a long time ago08:11
ZipCPUIn other words, you can reorder instructions to your hearts content within a basic block.08:11
ZipCPU(Reordering is on my to-do list ...)08:11
shorneI might as well put some comments in my and file to explain what they are08:12
ZipCPUComments are always good things.  :)08:12
shornei.e. one is for instructions, one is for reload08:12
ZipCPUOh, and then ... if you ever have to trace through the instruction issue ... heheh ...08:12
shorneZipCPU: are you going to upstream your gcc port?08:13
ZipCPUI'm forever thinking about it.08:13
ZipCPUI'm really sitting on the fence regarding it.08:13
ZipCPUI could be easily persuaded in one direction or the other ...08:14
shorneAre you using the lastest version of GCC i.e. 8.0.1?08:19
ZipCPUNo.  I'm currently using 6.2.0, but I can see benefits in moving to later versions.08:19
ZipCPU6.2.0 wasn't a problem for me while or1k was stuck in 4.xx ;P08:20
ZipCPUMaybe I should ask in #gcc on OFTC if they'd be interested in a GCC back end for the ZipCPU ...08:25
shorneZipCPU: I think they would as long as there are some users and its maintained08:35
shorneHave you had a look at moxie?08:35
ZipCPUWell, it's maintained.  I just don't know how many users there are.08:35
ZipCPUYes, I have looked at moxie.08:36
ZipCPUIt was the reference for the gentleman who helped me get started in the first place.08:36
shorneyes, its a very simple soft core only cpu built as a tutorial on how to port to gnu toolchain08:37
shorneI think if thats in then ZipCPU could also be added08:37
shorneI guess you would need binutils too08:38
ZipCPUMakes good sense.  Esp since I'm using the ZipCPU as a demo project for how to build CPU components on my blog.08:38

Generated by 2.15.2 by Marius Gedminas - find it at!