| --- Log opened Fri May 27 00:00:25 2016 | ||
| wallento | SMDwrk: I second olofk, as far as I know no processor has ever been formally verified, because that is of incredible complexity | 03:50 |
|---|---|---|
| wallento | people pay money for vendors because they trust their cores work and to hold up to that ARM and other spend the most of their work with verification | 03:51 |
| wallento | OpenRISC should have more verification, for sure, but formal verification seems out of range | 03:52 |
| olof | Has anyone worked with Opal Kelly boards? | 06:08 |
| wallento | olofk: never even heard of them | 06:42 |
| olof | Hey, OpenRISC is in the news :) http://boingboing.net/2016/05/26/undetectable-proof-of-concept.html | 07:54 |
| ZipCPU | olof: Fascinating article. I'm not sure if I would call that good news or bad news. | 14:12 |
| FireFalcon | olofk: I see that my paper has reached the openrisc community | 14:24 |
| FireFalcon | olofk: re: your boing boing pointer | 14:27 |
| FireFalcon | while I am here, anyone know how I can convince or1k-elf to emit multiply and divide instructions? | 14:29 |
| olofk | FireFalcon: Ahh. Hi, and welcome back. It was a while ago I saw you here. I was just writing a reply to your forum post | 14:56 |
| olofk | void main(void) {int a=1, b=2, c; c = a*b;} gives me an l.mul | 14:56 |
| olofk | But if I do a division instead it jumps to __divsi3 and does it in software instead | 14:57 |
| olofk | Must be a compiler switch for that I guess | 14:57 |
| olofk | FireFalcon: And I totally missed your name on the paper to be honest, but I see it now | 14:59 |
| olofk | FireFalcon: or1k-elf-gcc -mhard-div did the trick | 15:01 |
| olofk | There's also -mhard-mul if you hav problems with mults | 15:02 |
| FireFalcon | olofk: I could of swore that I tried mhard-div too | 15:08 |
| FireFalcon | olof: thanks, that worked. My scrollback reveals that I had tried mhard-mul, tisk tisk | 15:14 |
| ZipCPU | olofk: Mind if I copy that answer into the OpenCores forum request? (Just to try to keep OpenCores ... a little more alive.) | 15:19 |
| olofk | ZipCPU: Be my guest. I agree that it's good to keep up the activity, especially when it comes to relevant questions | 17:48 |
| ZipCPU | Will do. | 17:48 |
| shorne | FireFalcon: I have been looking at gcc a bit lately, I see div/mul is output in gcc/config/or1k/or1k.md (if defined TARGET_HARD_MUL/DIV) | 17:49 |
| ZipCPU | I should mention that my favorite question is still the one at the bottom of http://opencores.org/forum,Other,0,5534 | 17:49 |
| shorne | not sure how to define those... the macros in this gnu code are hard to track down | 17:49 |
| olofk | ZipCPU: Haha. Someone got really tired of answering stupid questions :) | 17:52 |
| ZipCPU | I keep that one around. I love it. | 17:52 |
| shorne | Interesting, TARGET_HARD_MUL is defined for sparc, and used. For for openrisc we only use it, but dont define it | 17:54 |
| shorne | Meaning not possible to enable without a patch it looks like | 17:55 |
| shorne | Anyone else know if its possible to do hard divide/multiply? | 17:55 |
| olofk | shorne: Yep, I just tried. It works | 17:55 |
| shorne | oh, ok so not sure what FireFalcon is mentioning, let me test | 17:56 |
| olofk | Not sure, but it could that what you're seeing are default values, i.e. hard mul is turned off by default | 17:56 |
| ZipCPU | Hold on ... I might know where to find that ... | 17:56 |
| olofk | shorne: In my testing, hard mul was enabled by default, but hard div was disabled | 17:56 |
| ZipCPU | I found a default optimization table in common/config/zip/zip-common.c. It's part of the option optimization table though. | 17:57 |
| shorne | olofk: confirmed for me to div is l.jal 23f4 <__divsi3>, mul is l.mul r3,r4,r3 | 18:01 |
| olofk | shorne: Try -mhard-div to get a l.div | 18:06 |
| shorne | l.div r4,r4,r3 | 18:07 |
| shorne | yeah, that works, using gcc 5.3.0 | 18:07 |
| shorne | ah... and that is defined in gcc/config/or1k/or1k.opt, and it will set Mask(HARD_DIV) | 18:09 |
| shorne | Just trying to understand how it works, now where the place we define the default mask | 18:11 |
| shorne | #define TARGET_DEFAULT_TARGET_FLAGS (MASK_HARD_MUL) | 18:12 |
| shorne | gcc/common/config/or1k/or1k-common.c | 18:12 |
| shorne | olofk: FYI, I am looking into more gdb failures, now this one `110 FAILs in: gdb.compile/compile.exp` | 18:15 |
| shorne | basically in gdb you can run (gdb) compile i = 8; | 18:15 |
| shorne | and it will load up or1k-elf-gcc and compile that snippet of code to debug | 18:15 |
| shorne | problem #1, the way it looks for gcc is a regex, and it builds it as '^or1k(-[^-]*)?--or1k-elf-gcc$' which is completely wrong | 18:16 |
| shorne | problem #2, there is actually a plugin `libcc1` used to load gcc which gets loaded by dlopen, but if I have gcc for newlib, musl, arm, x86, it could load any of the `libcc1.so` | 18:19 |
| shorne | I need to talk to gdb/gcc guys to fix this, its a bad design I think | 18:19 |
| -!- Cybernaut is now known as GenTooMan | 18:25 | |
| --- Log closed Sat May 28 00:00:26 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!