| --- Log opened Thu Aug 14 00:00:06 2014 | ||
| poke53281 | nbench runs flawless if compiled statically. | 00:16 |
|---|---|---|
| poke53281 | stekern: looks like the nbench problem is solved. I corrected my implementation of l.lwa and l.swa | 01:21 |
| stekern | olofk: I didn't ask if you installed binutils, I asked if you installed newlib | 02:39 |
| stekern | poke53281: I pushed the patch upstream anyway, https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=ffccb7afb54cf09db1013f941e8dfc5127b01876 | 02:45 |
| stekern | you should update your gcc too, I pushed the accompanying patch there too | 02:46 |
| stekern | and you should use this instead of the alignment fix in musl: https://github.com/openrisc/or1k-gcc/commit/b554855d6df5e46e7153e4206a18d89d8d6f | 02:46 |
| hesham | Hi, for or1ksim UART, can I fill a buffer and send write command instead of writing a character by character to register every time? | 11:23 |
| olofk | Ahh. right. newlib isn't in binutils-gdb. Hmm.. does that mean I should copy newlib from or1k-src to binutils-gdb, or should I do the second stage from or1k-src? | 12:26 |
| olofk | (Haven't really figured out what is installed at each pass) | 12:27 |
| hesham | olofk: I build newlib from or1k-src, after installing binutils to a know prefix, and set the same prefix when configuring or1k-src to build newlib | 12:39 |
| hesham | olofk: FYI, there is minimal newlib support upstream to sourceware with no libgloss stuff | 12:40 |
| stekern | olofk: yeah, it's a bit of a mess at the moment | 13:21 |
| stekern | I'm in the progress of merging the sim bits from or1k-src to binutils-gdb | 13:21 |
| stekern | then it's just gdb that's not upstreamed in the binutils part | 13:22 |
| rah | in general, does the number of bits to shift in a bitshift operation make a difference to performance? | 13:52 |
| rah | that is, is 1 << 7 more expensive than 1 << 2 ? | 13:52 |
| ysionneau | depends if your shift logic is pipelined or not | 13:55 |
| ysionneau | if it's not pipelined (and therefore bigger) then it can do the shift in 1 clock cycle | 13:56 |
| ysionneau | if it's pipelined (and smaller) then the more you shift the more it takes time | 13:56 |
| stekern | the more common term for 'not pipelined' is barrel shifter | 13:58 |
| dalias | simplest-profile microblaze only has <<1 and >>1 :-p | 14:58 |
| dalias | so >>24 generates 24 >>1 ops in a row | 14:59 |
| dalias | and >>n generates a loop | 14:59 |
| stekern | sounds annoying to have the performance of the shifts being decided at compile time | 15:13 |
| stekern | but I think lm32 is like that too? | 15:14 |
| ysionneau | you have a register you can read to know if the barrel shifter is enabled or not | 15:21 |
| ysionneau | so you can decide at runtime | 15:21 |
| stekern | that usually doesn't make it less annoying, runtime decisions are usually impractical as well | 15:28 |
| stekern | but what is the alternative if there's no barrel shifter, no shifter at all? | 15:29 |
| stekern | if it's functionally same serial shifter, then it's not an issue | 15:30 |
| stekern | +a | 15:31 |
| ysionneau | you have 2 different barrel shifter, one pipelined but executes in 3 cycles | 15:33 |
| ysionneau | one ... which can execute up to 32 cycles | 15:33 |
| ysionneau | and you can have none of them as well, then none of the shift instruction are available | 15:34 |
| stekern | ah, ok | 15:37 |
| stekern | are you sure that it's in 3 cycles? | 15:37 |
| ysionneau | I'm not sure, but I'm sure that it's what the datasheet says | 15:38 |
| stekern | I thought the none serial was 1 cycle non-pipelined | 15:38 |
| ysionneau | I thought that as well | 15:39 |
| ysionneau | I was surprised to read 3 cycles | 15:39 |
| ysionneau | maybe they preferred using smaller mux ... | 15:39 |
| ysionneau | weird | 15:40 |
| stekern | smaller mux? | 15:40 |
| ysionneau | humm maybe I'm saying BS | 15:40 |
| ysionneau | the (up to 32) multi cycle shifter is there : https://github.com/m-labs/lm32/blob/master/rtl/lm32_mc_arithmetic.v | 15:45 |
| ysionneau | the 3 cycles pipelined one is there : https://github.com/m-labs/lm32/blob/master/rtl/lm32_shifter.v | 15:45 |
| ysionneau | it does not look really 3 cycles ... | 15:49 |
| ysionneau | does it? | 15:49 |
| stekern | no, it looks like a 2-cycle pipelined implementation, with the result ready in mem stage | 15:50 |
| stekern | i.e. it's non-stall, but will cause bubbles in the | 15:52 |
| stekern | pipeline | 15:52 |
| ysionneau | maybe I'm getting it wrong but the content of lm32_shifter.v seems to compute the shift in 1 cycle, isn't it? | 15:53 |
| stekern | to be 1 cycle, it'd need to be combinatorial | 15:55 |
| stekern | (the mor1kx is) | 15:56 |
| stekern | *the one in | 15:58 |
| ysionneau | ok | 15:59 |
| stekern | wonder if the mor1kx shifter is creating any critical paths | 16:09 |
| -!- FreezingAlt is now known as FreezingCold | 17:06 | |
| mor1kx | [mor1kx] skristiansson pushed 1 new commit to master: https://github.com/openrisc/mor1kx/commit/5090306ec02b496ca21fad808bc62fc5342ee86b | 17:14 |
| mor1kx | mor1kx/master 5090306 Stefan Kristiansson: cappuccino/lsu: stay in WRITE state on store_buffer_write... | 17:14 |
| poke53281 | Thanks again for the patches stekern. Pulling ... | 18:07 |
| poke53281 | ASM_PREFERRED_EH_DATA_FORMAT ... I don't linke the word PREFERRED. Is there nothing like: Under no circumstances, never never access the memory misaligned. :) | 18:10 |
| dalias | on ISAs where <<n and >>n instructions are "optional", they should be defined not to trap but to set a flag or something when they're unsupported | 18:10 |
| dalias | so that the compiler can generate a conditional-branch right after the instruction to go to the fallback code | 18:11 |
| dalias | poke53281, misaligned is not the biggest issue there. the big issue is making unwind data that requires relocations at runtime, which is utterly idiotic. | 18:12 |
| poke53281 | I am not in that topic, that I can really make useful comments. Normally it just works. But I run already two or three times into a misaligned problem. And it was most of the time a problem of gcc. | 18:16 |
| dalias | well i don't think that's related to ASM_PREFERRED_EH_DATA_FORMAT, but maybe i'm misunderstanding... | 18:23 |
| poke53281 | No, it's not. | 18:23 |
| poke53281 | but as a result, we got a misaligned memory access. | 18:24 |
| dalias | yes. i'm not sure whether that's allowed in dwarf or not. but it couldn't have happened if the dynamic linker was not being asked to access the eh_frame segment to begin with | 19:12 |
| dalias | if dwarf allows misaligned data, the unwind code has to be capable of handling that | 19:12 |
| dalias | but there's no reason the dynamic linker should have to since it shouldn't have to modify eh_frame at all | 19:13 |
| stekern | yes, and with DW_EH_PE_pcrel, there's no R_OR1K_32 relocation in eh_frame | 19:50 |
| dalias | *nod* | 19:56 |
| blueCmd | jeremybennett: I asked gcc about patch submission and stuff like that a few weeks back. I got this: | 20:58 |
| blueCmd | you should submit the patch series to gcc-patches mailing list. I | 20:58 |
| blueCmd | don't know if you know anyone listed as global reviewer, but you | 20:58 |
| blueCmd | probably need to contact a few privately to convince someone to review | 20:58 |
| blueCmd | the patches. It's sort of a thankless job. It's mainly to ensure | 20:58 |
| blueCmd | that it is following the GCC style and formatting. | 20:58 |
| blueCmd | jeremybennett: I figure you might be the one with the most connections in that world if you know anyone we can buy a cake or a bottle of whiskey for helping us out | 20:59 |
| olofk | mmmm...cake | 21:07 |
| stekern | mmmm...whiskey | 21:08 |
| olofk | Are there any other potential bare-metal C libraries that we could/should use except for newlib? I think I heard about someting else. nano something maybe? | 21:09 |
| olofk | wikipedia doesn't indicate anything | 21:10 |
| olofk | And would newlib be a good candidate for upstreaming after GCC? I know that the current implementation is intended more as an educational example (hence the gplv3 license), so maybe we have to reimplement it in that case | 21:13 |
| blueCmd | olofk: we had some discussions on that off list I think. I think that Stefan W is looking into that | 21:14 |
| blueCmd | it doesn't need to be after GCC either, could just as well be done ASAP | 21:14 |
| blueCmd | stekern: i keep forgetting if I upstreamed sim | 21:14 |
| olofk | Sure. I just figured that it would free up some resources if we did it one at a time | 21:15 |
| stekern | blueCmd: you didn't, I'm looking into doing it now(ish) | 21:17 |
| blueCmd | stekern: cool | 21:17 |
| blueCmd | stekern: thanks | 21:17 |
| stekern | well, as always I'm doing about 10 other things at the same time ;) | 21:17 |
| blueCmd | yeah, I'm a bit tired of lately - lot of stuff IRL, i'm trying to keep pulling GCC but yeah, not in a productive period ATM. | 21:18 |
| blueCmd | I spoke with some coworkers that worked on NetApp before in an attempt to reach Jungsook, but that failed. | 21:19 |
| blueCmd | People warn me from calling NetApp and simply asking, larger companies apparently don't like that very nuch | 21:20 |
| stekern | yeah | 21:25 |
| stekern | I think it's time to start an 11th project | 21:31 |
| stekern | called zzz | 21:31 |
| blueCmd | stekern: :) gn | 21:31 |
| olofk | stekern: Does that project involve conflicting drivers? ;) | 21:40 |
| --- Log closed Fri Aug 15 00:00:07 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!