| --- Log opened Tue Mar 20 00:00:22 2018 | ||
| wbx | mafm[m]: hey, he just had started :P | 01:11 |
|---|---|---|
| futarisIRCcloud | shorne: Best of luck with the or1k-port of gcc. | 02:57 |
| shorne | mafm[m]: only 32 now, feel free to contribute :) | 06:30 |
| mafm[m] | shorne: I'm kind of busy with riscv at the moment | 06:33 |
| mafm[m] | I din't mean to poke about it, just not sure if the openrisc specs now also work with 64-bits | 06:34 |
| mafm[m] | when we were working on the Debian port it was 32-bits only | 06:34 |
| shorne | mafm[m]: the spec has 64-bit support | 07:33 |
| shorne | but I dont know of any cores with it | 07:33 |
| shorne | i.e. | 07:34 |
| shorne | l.movhi | 07:34 |
| shorne | rD[31:0] ← extz(Immediate) << 16 | 07:34 |
| shorne | rD[63:0] ← extz(Immediate) << 16 | 07:34 |
| shorne | row 1, is 32-bit systems, row 2 is 64-bit | 07:34 |
| ZipCPU | shorne: Feel free to holler if you get into any CPU trouble. | 07:42 |
| ZipCPU | Sorry, any GCC trouble. | 07:42 |
| ZipCPU | It 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 |
| stekern | shorne: way to go! | 07:47 |
| shorne | ZipCPU: you might want to join #gcc over on OFTC, I have been asking a few things over there | 07:56 |
| shorne | but I'll echo here if I get stuck | 07:56 |
| ZipCPU | Sure! I've seen some of the discussions over there, I just don't check there that often. | 07:56 |
| shorne | Ill try to send out some mails with patches for review when I get something that compiles | 07:56 |
| ZipCPU | Care to share where you are at in the process? | 07:56 |
| shorne | this is my todo list, for bootstrap | 07:57 |
| ZipCPU | By "bootstrap", do you have the cross compiler working? | 07:57 |
| shorne | - build infra + basic files - DONE | 07:57 |
| shorne | - register definitions - DONE | 07:57 |
| shorne | - calling conventions | 07:57 |
| shorne | - memory layout | 07:57 |
| shorne | - load/store | 07:57 |
| shorne | - moves | 07:57 |
| shorne | - jump | 07:57 |
| shorne | - branches | 07:58 |
| shorne | I am working on Moves & Load/Store now | 07:58 |
| shorne | Then will move to calling conventions | 07:58 |
| ZipCPU | Ahh, yes, moves and load/store's were some of the hardest problems I had to deal with. | 07:58 |
| shorne | there is another item for | 07:58 |
| shorne | - arithmatic | 07:58 |
| ZipCPU | The whole reload issue was ... quite confusing for me for some time. | 07:58 |
| ZipCPU | Once you get load/store/move working, arithmetic will be easy. | 07:58 |
| shorne | there are a lot of other things too, like pipelines, attributes, clobbers | 07:59 |
| shorne | but not needed to thing about for now | 07:59 |
| shorne | ZipCPU: 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 regstiers | 07:59 |
| ZipCPU | How are you going about debugging things? Hopefully, you've found the -fdump* series of options? | 07:59 |
| shorne | but then they have these flags reload_in_progress... | 08:00 |
| shorne | ZipCPU: yes -fdump-all-all | 08:00 |
| ZipCPU | Yeah, that reload thing *really* got me. | 08:00 |
| ZipCPU | So, here's what I learned .... | 08:00 |
| shorne | or -fdump-rtl-all-all | 08:00 |
| shorne | I really dont enjoy the globals | 08:00 |
| ZipCPU | (Yes!) GCC commits to an instruction pattern long before it commits to registers. | 08:01 |
| ZipCPU | The trick, though, in any load/store architecture is that the instructions can rarely handle the "modes" that result from reload. | 08:01 |
| shorne | I dont get the reload_in_progress thing yet | 08: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 |
| ZipCPU | load/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 |
| shorne | or1k, has flags but not affected by load/store/move for the most part | 08:03 |
| shorne | atomics load/store are an exception | 08:04 |
| ZipCPU | So, 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 |
| shorne | yes, during register allocation, if not enougn registers, a spill is needed | 08:04 |
| ZipCPU | That 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 | |
| shorne | yes, thats what I was planning too, just one def_insn for load,store,move,load_immediate, etc | 08:05 |
| ZipCPU | Ahh, here's the terms: predicates and constraints. | 08:06 |
| ZipCPU | The rule is: predicates are used when assigning the instruction--constraints are ignored. | 08:06 |
| ZipCPU | constraints are used to handle reloads | 08:06 |
| ZipCPU | The 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 |
| shorne | I see, yeah that is one thing that was not completely clear yet | 08:07 |
| ZipCPU | The constraints are then used to guide the reloading. | 08:07 |
| ZipCPU | Yeah ... I had to trace (debug by printf) through *a*lot* of GCC code to figure that out. | 08:08 |
| shorne | I did a lot of that too so far | 08:08 |
| shorne | rtl dumps, and printfs, then when I get stuck I took some time to read what is "register allocat" what is "spill" in some formal documentation | 08:08 |
| shorne | (not gcc docs) | 08:09 |
| ZipCPU | :D | 08:09 |
| shorne | then there is some interesting stuff with Flog Control Diagrams, and edge diagrams etc | 08:09 |
| ZipCPU | I 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 only | 08:10 |
| shorne | I think recently they are trying to deco the 'reload' and replace with the "ira" | 08:10 |
| ZipCPU | Yes. I need to get into those. Familiar with what a "basic block" is? | 08:10 |
| shorne | basic block is everyting between branches right? | 08:11 |
| ZipCPU | Yes. | 08:11 |
| shorne | I think I figured that out a long time ago | 08:11 |
| ZipCPU | In 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 |
| shorne | I might as well put some comments in my predicate.md and contrainsts.md file to explain what they are | 08:12 |
| ZipCPU | Comments are always good things. :) | 08:12 |
| shorne | i.e. one is for instructions, one is for reload | 08:12 |
| ZipCPU | Oh, and then ... if you ever have to trace through the instruction issue ... heheh ... | 08:12 |
| shorne | ZipCPU: are you going to upstream your gcc port? | 08:13 |
| ZipCPU | I'm forever thinking about it. | 08:13 |
| ZipCPU | I'm really sitting on the fence regarding it. | 08:13 |
| ZipCPU | I could be easily persuaded in one direction or the other ... | 08:14 |
| shorne | Are you using the lastest version of GCC i.e. 8.0.1? | 08:19 |
| ZipCPU | No. I'm currently using 6.2.0, but I can see benefits in moving to later versions. | 08:19 |
| ZipCPU | 6.2.0 wasn't a problem for me while or1k was stuck in 4.xx ;P | 08:20 |
| ZipCPU | Maybe I should ask in #gcc on OFTC if they'd be interested in a GCC back end for the ZipCPU ... | 08:25 |
| shorne | ZipCPU: I think they would as long as there are some users and its maintained | 08:35 |
| shorne | Have you had a look at moxie? | 08:35 |
| ZipCPU | Well, it's maintained. I just don't know how many users there are. | 08:35 |
| ZipCPU | Yes, I have looked at moxie. | 08:36 |
| ZipCPU | It was the reference for the gentleman who helped me get started in the first place. | 08:36 |
| shorne | yes, its a very simple soft core only cpu built as a tutorial on how to port to gnu toolchain | 08:37 |
| shorne | I think if thats in then ZipCPU could also be added | 08:37 |
| shorne | I guess you would need binutils too | 08:38 |
| ZipCPU | Makes 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!