| --- Log opened Fri Jan 22 00:00:57 2016 | ||
| dalias | stekern, do you have any ideas about my condition flag question? | 03:02 |
|---|---|---|
| dalias | poke53281 said i can get the value in a GPR using l.mfspr for the SR register, but the ISA docs seem to say this operation is privileged | 03:03 |
| dalias | i think you'll like this: http://git.musl-libc.org/cgit/musl/diff/arch/or1k?id=1315596b510189b5159e742110b504177bdd4932 | 03:04 |
| dalias | but it would be even nicer to be able to define a_ll and a_sc as separate atomic fragments so the compiler can put them together and make arbitrary atomics | 03:05 |
| stekern | dalias: yeah, unfortunately it seems to be restrictred to priviliged mode. you could of course use l.cmov to read the flag, but that instruction is not mandatory to implement | 04:36 |
| dalias | so it looks like the only really supported way is to branch on the flag and set a value in branch path.. | 04:40 |
| dalias | something hideous like: | 04:41 |
| dalias | "l.swa %2, %1, r0 ; l.bf 1f ; l.addi %0,r0,1 ; l.addi %0,r0,0 ; 1:" | 04:41 |
| dalias | gcc asm goto would solve the problem perfectly well, but other "gnu c" compilers do not want to implement it | 04:53 |
| dalias | allowing output constraints for condition flags would solve it more elegantly | 04:53 |
| _franck_ | olofk: just did "fusesoc sim my_probably_bad_core_file" | 06:18 |
| olofk | _franck_: I tried fusesoc sim --sim=verilator mor1k-generic, and that seems to work. Can I take a look at your core file? | 08:08 |
| _franck__ | olofk: https://github.com/fjullien/orpsoc-cores/blob/systemc/cores/simple_spi/simple_spi.core | 08:15 |
| _franck__ | it's an old thing on an old branch when I did some tests | 08:16 |
| _franck__ | but it shouldn't crash fusesoc anyhow | 08:17 |
| _franck__ | olofk: you can use this branch to reproduce the problem: https://github.com/fjullien/orpsoc-cores/tree/systemc_rework | 08:43 |
| olofk | _franck_: I agree. Not sure what's going on here. I'll try to reproduce it here | 08:49 |
| olofk | Anyone handy with llvm? | 13:45 |
| olofk | Installed the llvm toolchain to the Nyuzi GPU, but it complains it can't find ld.mcld now | 13:45 |
| juliusb | I think the first question is why aren't you using the open source (YES IT IS. Issue closed. Move on) SYMPL-GP-GPU-Compute engine? | 14:18 |
| olofk | lol | 14:19 |
| juliusb | I think you'll find it's pedigree is impeccable | 14:19 |
| olofk | I thought you had to be a advanced level (Stage-6) in Controlled Remote Viewing by ex-Defense Intelligence Agency military remote viewer to use it | 14:20 |
| juliusb | No, you just have to hate open source. | 14:22 |
| juliusb | ... despite co-opting the concept to peddle your IP. | 14:23 |
| juliusb | Sorry to derail your serious inquiry about an actual open source bit of IP :) | 14:24 |
| olofk | Ah it's ok. This is more fun. Did you see the hidden patent stuff too? https://github.com/jerry-D/SYMPL-GP-GPU-Compute-Engines/commit/6da0b9ade8345f00c09efcca0dea98d3e174aaad#diff-2c498e22e9855736f5b96c543e929f52L16 | 14:25 |
| juliusb | I mean, this guys' track record with patent trolling and remote viewing aside, this is an interesting situation. He's gone wrong by claiming it's open source and then being abbrasive in the ensuring conversation. But consider open source IP really taking off, and companies (Synopsys, Xilinx, etc.) wanting to release IP for the sorts of uses Hardcock here outlines (evaluation, education, enthusiasts, strictly non-commerical). That seems mostly reasonably to me. It's IP that otherwise wouldn't have been out there, enabling others to take it, not make money from it, but develop other things around it which could well be open sourced. It's a lot like the licenses FPGA vendors put on their proprietary IP cores like DDR controllers and the like you get from their tools. | 14:36 |
| juliusb | It depends a lot on what license applies to derivative works, obviously, but I'm not entirely opposed to IP which is available under such terms (ie. not available for commerical use), because it ultimately does add to what's available. As I mentioned, it's almost precisely what FPGA vendors' do, right? And that's not entirely bad thing; and in fact spurs you on to want to supplant their stuff eventually, but gets you off the ground to begin with. | 14:38 |
| olofk | yep. agree | 14:44 |
| olofk | Having the source code available is way better than closed IP, since you have the option for example to fix problems | 14:47 |
| rah_ | what is this guy's track record with remote viewing? | 14:59 |
| -!- rah_ is now known as rah | 14:59 | |
| olofk | rah: Judge for yourself :) http://www.escapistmagazine.com/forums/read/7.339774-Psychic-Apollo-16-Astronauts-Found-Alien-Life-on-the-Moon | 15:25 |
| rah | olofk: that seems like a prejudiced article but the guy's behaviour does seem odd | 16:51 |
| rah | juliusb: out of interest, where was the conversation in which he was abrasive? | 16:52 |
| rah | I see | 17:04 |
| rah | https://github.com/jerry-D/SYMPL-GP-GPU-Compute-Engines/issues/1 | 17:04 |
| wallento | I also agree with juliusb. Actually I would not have known from the top of my had that "open source" forbids a non-commercial clause.. | 17:09 |
| wallento | Also in the software world it is not uncommon and releasing someone's code is already an improvement | 17:09 |
| wallento | haha, I like that one: http://wonko.com/post/jsmin-isnt-welcome-on-google-code | 17:13 |
| stekern | yeah, even the first license of Linux had a non-commercial clause | 18:39 |
| _franck_ | olofk: this seems to fix the problem : http://pastebin.com/bBPApp5d | 21:19 |
| _franck_ | you tell me why | 21:19 |
| olofk | _franck_: I think the problem is that src_files just used to be a list of strings, and now they are a list of File instead | 21:47 |
| olofk | And somewhere things are getting mixed up. Not sure exactly what goes wrong though | 21:47 |
| --- Log closed Sat Jan 23 00:00:59 2016 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!