IRC logs for #openrisc Thursday, 2013-07-25

--- Log opened Thu Jul 25 00:00:42 2013
stekernhno: nice one!02:15
stekern...although it's good to keep the bugs in a not _too_ distant_ memory, they might pop back up, and then it's good to remember them ;)02:16
stekernyou deserve a beer for fixing that btw02:34
stekernpoke53281: I've been looking into the unaligned issue you spoke about, I'm not sure I understand how that happens04:29
stekernI can't reproduce in a simple testcase neither04:29
stekerngives this output:04:33
stekernsizeof(struct kbd_struct) = 804:33
stekern&kbd[0] = 7fffe404:33
stekern&kbd[1] = 7fffec04:33
stekernso, it's not even that the struct is of an "unaligned" size04:34
stekernI mean, if the size would be 7 for instance, accessing kbd[1] would generate unaligned accesses04:34
poke53281Yes, I have also analyzed the problem a little bit. The alignment in principle is Ok. 8 Bytes. But for some reason the compiler adds two to the offset and produces an unaligned  word access.04:55
poke53281I could reproduce it, but don't know why the compiler is doing it04:55
poke53281on x86 the struct size is 504:55
poke53281But I have to find the correct alignment for this struct right now04:56
poke53281so, in principle the compiler is doing this: l.add r7,r6,2  r6 is the aligned memory offset of the struct. Then he accesses the struct with l.lwz r8, 0(r7)04:58
poke53281maybe a bitfield is aligned in such way, that it crosses a word alignment.04:59
stekernwhen does it do the +2, i.e. what member of the struct is it accessing?04:59
poke53281one moment05:03
poke5328150: and 60: contains the unaligned access05:19
stekernpoke53281: yes, indeed. the curious thing is that when I compile your test code, it doesn't generate that code05:52
poke53281with -O2 ?05:56
stekernit generate l.lhz loads and stores05:57
stekernyes, with -O205:57
poke53281look like you compiler does 16-Bit aligned access06:01
stekernyeah, maybe there's a bug in 4.8.0 then06:02
stekernyup, with 4.8.0 I get the l.lwz06:03
poke53281Possible that it started with 4.8.006:03
poke53281Ok, problem solved I would say. 4.8.0 is incompatible :)06:04
poke53281Well, there is normally some kind of unwritten rule. Never trust software that end with .006:07
stekernand our 4.8.0 is not even tied to the .0 release, it's some random point in the experimental tree06:08
stekernI like this shell script I've found:
poke53281Copy and Paste is also fast.06:10
stekernmakes it possible to do this: 'or1k-elf-objdump -D bitfield-poke.o | pastie'06:10
stekernand the previous line in the bash history was the same, except with the 'pastie' replaced with 'less'06:11
stekernyes, copy-paste is fast too, but it's annooying when you have something 'lessed' that takes more than one screen06:12
hnostekern, on Fedora we have fpaste06:17
stekernhno: yeah, yeah, stop reminding me that I should get rid of this (k)ubuntu sh*t =P06:22
stekernI switched to (k)ubuntu from gentoo a couple of years ago, because I realised that I spent more time maintaining the system than actually using it06:24
stekernbut with the latest ubuntu releases, it almost feels like I'm back to the aftermaths of doing an emerge world when upgrading to a new release06:25
poke53281try archlinux. I like it06:29
poke53281Rolling release06:29
stekernthe problem with switching distro is... I'd have to "waste" time setting up the ws again06:30
poke53281At least you have choice. Think of all the hundreds of million  Windows Users :)06:38
hnostekern, I never upgrade, do a new install into a new lvm volume, keeping /home and some other data.06:46
stekernhno: yeah, that's probably the smart way of doing things06:50
stekernthe problems I've seen have been release specific though, not related to the actual upgrade06:51
poke53281I have switched to 4.8.1. Let's hope the best. Recompiling everything over night07:05
stekernI'm actually on 4.9.0, but I tested compiling with 4.8.1 too, and that seems to be doing the right thing too07:12
poke53281Promise me that you there will be always one branch of an official stable gcc version07:14
stekernthat was precisely my idea with syncing with both the release and svn tip-of-trunk07:15
juliusb3 minutes of waiting...14:28
juliusband then he was gone14:28
juliusb(or she)14:28
juliusbkids these days, such short attention spans14:28
juliusbalthough, maybe that's an unfair criticism - there wasn't much to keep that person's attention14:29
hnojuliusb, have added "Don't ask to ask, just ask and wait." to some of my channels...14:33
hnoin /topic14:33
juliusboh yes that's a good one14:33
juliusbsomeone named "Iscray Openray" has just posted to the opencores list14:33
juliusband their address is openrisc@yahoo.com14:34
jeremybennettjuliusb: I've replied to him.14:53
juliusbjeremybennett: nice one15:16
juliusbany thoughts on the teleconf call? is today or tomorrow preferrable?15:16
juliusbsorry, I spoke too soon15:17
juliusbthanks very much for organising it15:17
jeremybennettjuliusb: NP15:42
stekernworking on the mor1kx dtlb reload, I stumbled on an icache invalidate bug16:11
stekernI've fixed it, but it makes me wonder how expensive true dual port rams are in asics?16:11
stekernbecause by using a dpram I could just connect the spr bus to the second port and remove a lot of annoying logic surrounding that16:12
hnostekern, I would think it16:37
hnoit's less expensive in ASIC than in FPGA.16:38
hnostekern, how many bits you need, and how many ports?16:44
stekernhno: in (most) FPGAs (from the major vendors) dpram is no more expensive than spram, the ram blocks are hard dual port rams17:06
stekernit's the RAM that caches the tags, so the size is a bit dependant on the cache setup17:07
stekernoh, and the "dual" in dual port ram should give away the port number ;)17:21
stekernactually, I only need the write side of the second port17:21
hnostekern, so dual write single read?17:23
stekernbut with separate write and read on the r/w port18:28
stekernumm, and that was implied by what you said18:30
poke53281LTP testsuite part memory: Total Tests:80 Total Failures: 24, No total crash19:16
poke53281But a lot of error messages. Maybe some were on purpose.19:18
poke53281And a lot of tests didn't work because of missing features like NUMA or shared memory19:19
-!- Netsplit *.net <-> *.split quits: mbuf, Logxen, forkG19:20
-!- Netsplit over, joins: Logxen, forkG19:21
-!- Netsplit *.net <-> *.split quits: poke5328119:24
stekernpassed were > failed at least =P19:27
--- Log closed Fri Jul 26 00:00:43 2013

Generated by 2.15.2 by Marius Gedminas - find it at!