IRC logs for #openrisc Thursday, 2014-08-14

--- Log opened Thu Aug 14 00:00:06 2014
poke53281nbench runs flawless if compiled statically.00:16
poke53281stekern: looks like the nbench problem is solved. I corrected my implementation of l.lwa and l.swa01:21
stekernolofk: I didn't ask if you installed binutils, I asked if you installed newlib02:39
stekernpoke53281: I pushed the patch upstream anyway,;a=commit;h=ffccb7afb54cf09db1013f941e8dfc5127b0187602:45
stekernyou should update your gcc too, I pushed the accompanying patch there too02:46
stekernand you should use this instead of the alignment fix in musl:
heshamHi, 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
olofkAhh. 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
heshamolofk: I build newlib from or1k-src, after installing binutils to a know prefix, and set the same prefix when configuring or1k-src to build newlib12:39
heshamolofk: FYI, there is minimal newlib support upstream to sourceware with no libgloss stuff12:40
stekernolofk: yeah, it's a bit of a mess at the moment13:21
stekernI'm in the progress of merging the sim bits from or1k-src to binutils-gdb13:21
stekernthen it's just gdb that's not upstreamed in the binutils part13:22
rahin general, does the number of bits to shift in a bitshift operation make a difference to performance?13:52
rahthat is, is 1 << 7 more expensive than 1 << 2 ?13:52
ysionneaudepends if your shift logic is pipelined or not13:55
ysionneauif it's not pipelined (and therefore bigger) then it can do the shift in 1 clock cycle13:56
ysionneauif it's pipelined (and smaller) then the more you shift the more it takes time13:56
stekernthe more common term for 'not pipelined' is barrel shifter13:58
daliassimplest-profile microblaze only has <<1 and >>1 :-p14:58
daliasso >>24 generates 24 >>1 ops in a row14:59
daliasand >>n generates a loop14:59
stekernsounds annoying to have the performance of the shifts being decided at compile time15:13
stekernbut I think lm32 is like that too?15:14
ysionneauyou have a register you can read to know if the barrel shifter is enabled or not15:21
ysionneauso you can decide at runtime15:21
stekernthat usually doesn't make it less annoying, runtime decisions are usually impractical as well15:28
stekernbut what is the alternative if there's no barrel shifter, no shifter at all?15:29
stekernif it's functionally same serial shifter, then it's not an issue15:30
ysionneauyou have 2 different barrel shifter, one pipelined but executes in 3 cycles15:33
ysionneauone ... which can execute up to 32 cycles15:33
ysionneauand you can have none of them as well, then none of the shift instruction are available15:34
stekernah, ok15:37
stekernare you sure that it's in 3 cycles?15:37
ysionneauI'm not sure, but I'm sure that it's what the datasheet says15:38
stekernI thought the none serial was 1 cycle non-pipelined15:38
ysionneauI thought that as well15:39
ysionneauI was surprised to read 3 cycles15:39
ysionneaumaybe they preferred using smaller mux ...15:39
stekernsmaller mux?15:40
ysionneauhumm maybe I'm saying BS15:40
ysionneauthe (up to 32) multi cycle shifter is there :
ysionneauthe 3 cycles pipelined one is there :
ysionneauit does not look really 3 cycles ...15:49
ysionneaudoes it?15:49
stekernno, it looks like a 2-cycle pipelined implementation, with the result ready in mem stage15:50
stekerni.e. it's non-stall, but will cause bubbles in the15:52
ysionneaumaybe 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
stekernto be 1 cycle, it'd need to be combinatorial15:55
stekern(the mor1kx is)15:56
stekern*the one in15:58
stekernwonder if the mor1kx shifter is creating any critical paths16:09
-!- FreezingAlt is now known as FreezingCold17:06
mor1kx[mor1kx] skristiansson pushed 1 new commit to master:
mor1kxmor1kx/master 5090306 Stefan Kristiansson: cappuccino/lsu: stay in WRITE state on store_buffer_write...17:14
poke53281Thanks again for the patches stekern. Pulling ...18:07
poke53281ASM_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
daliason 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 unsupported18:10
daliasso that the compiler can generate a conditional-branch right after the instruction to go to the fallback code18:11
daliaspoke53281, 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
poke53281I 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
daliaswell i don't think that's related to ASM_PREFERRED_EH_DATA_FORMAT, but maybe i'm misunderstanding...18:23
poke53281No, it's not.18:23
poke53281but as a result, we got a misaligned memory access.18:24
daliasyes. 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 with19:12
daliasif dwarf allows misaligned data, the unwind code has to be capable of handling that19:12
daliasbut there's no reason the dynamic linker should have to since it shouldn't have to modify eh_frame at all19:13
stekernyes, and with DW_EH_PE_pcrel, there's no R_OR1K_32 relocation in eh_frame19:50
blueCmdjeremybennett: I asked gcc about patch submission and stuff like that a few weeks back. I got this:20:58
blueCmdyou should submit the patch series to gcc-patches mailing list.   I20:58
blueCmddon't know if you know anyone listed as global reviewer, but you20:58
blueCmdprobably need to contact a few privately to convince someone to review20:58
blueCmdthe patches.  It's sort of a thankless job.  It's mainly to ensure20:58
blueCmdthat it is following the GCC style and formatting.20:58
blueCmdjeremybennett: 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 out20:59
olofkAre 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
olofkwikipedia doesn't indicate anything21:10
olofkAnd 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 case21:13
blueCmdolofk: we had some discussions on that off list I think. I think that Stefan W is looking into that21:14
blueCmdit doesn't need to be after GCC either, could just as well be done ASAP21:14
blueCmdstekern: i keep forgetting if I upstreamed sim21:14
olofkSure. I just figured that it would free up some resources if we did it one at a time21:15
stekernblueCmd: you didn't, I'm looking into doing it now(ish)21:17
blueCmdstekern: cool21:17
blueCmdstekern: thanks21:17
stekernwell, as always I'm doing about 10 other things at the same time ;)21:17
blueCmdyeah, 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
blueCmdI spoke with some coworkers that worked on NetApp before in an attempt to reach Jungsook, but that failed.21:19
blueCmdPeople warn me from calling NetApp and simply asking, larger companies apparently don't like that very nuch21:20
stekernI think it's time to start an 11th project21:31
stekerncalled zzz21:31
blueCmdstekern: :) gn21:31
olofkstekern: Does that project involve conflicting drivers? ;)21:40
--- Log closed Fri Aug 15 00:00:07 2014

Generated by 2.15.2 by Marius Gedminas - find it at!