| --- Log opened Thu Jul 25 00:00:42 2013 | ||
| stekern | hno: 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 |
| stekern | you deserve a beer for fixing that btw | 02:34 |
| stekern | poke53281: I've been looking into the unaligned issue you spoke about, I'm not sure I understand how that happens | 04:29 |
| stekern | I can't reproduce in a simple testcase neither | 04:29 |
| stekern | http://pastie.org/8173230 | 04:32 |
| stekern | gives this output: | 04:33 |
| stekern | sizeof(struct kbd_struct) = 8 | 04:33 |
| stekern | &kbd[0] = 7fffe4 | 04:33 |
| stekern | &kbd[1] = 7fffec | 04:33 |
| stekern | so, it's not even that the struct is of an "unaligned" size | 04:34 |
| stekern | I mean, if the size would be 7 for instance, accessing kbd[1] would generate unaligned accesses | 04:34 |
| stekern | s/would/could | 04:39 |
| poke53281 | Yes, 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 |
| poke53281 | I could reproduce it, but don't know why the compiler is doing it | 04:55 |
| poke53281 | on x86 the struct size is 5 | 04:55 |
| poke53281 | But I have to find the correct alignment for this struct right now | 04:56 |
| poke53281 | so, 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 |
| poke53281 | maybe a bitfield is aligned in such way, that it crosses a word alignment. | 04:59 |
| stekern | when does it do the +2, i.e. what member of the struct is it accessing? | 04:59 |
| poke53281 | one moment | 05:03 |
| poke53281 | pastie.org/8173320 | 05:18 |
| poke53281 | 50: and 60: contains the unaligned access | 05:19 |
| stekern | poke53281: yes, indeed. the curious thing is that when I compile your test code, it doesn't generate that code | 05:52 |
| poke53281 | with -O2 ? | 05:56 |
| stekern | it generate l.lhz loads and l.sh stores | 05:57 |
| stekern | yes, with -O2 | 05:57 |
| stekern | http://pastie.org/8173396 | 05:58 |
| poke53281 | 4.8.0 | 06:01 |
| poke53281 | look like you compiler does 16-Bit aligned access | 06:01 |
| stekern | yeah, maybe there's a bug in 4.8.0 then | 06:02 |
| stekern | yup, with 4.8.0 I get the l.lwz | 06:03 |
| poke53281 | Possible that it started with 4.8.0 | 06:03 |
| poke53281 | Ok, problem solved I would say. 4.8.0 is incompatible :) | 06:04 |
| stekern | indeed | 06:04 |
| poke53281 | Well, there is normally some kind of unwritten rule. Never trust software that end with .0 | 06:07 |
| stekern | =P | 06:07 |
| stekern | and our 4.8.0 is not even tied to the .0 release, it's some random point in the experimental tree | 06:08 |
| stekern | I like this pastie.org shell script I've found: http://raim.codingfarm.de/blog/2010/04/06/pastie-org-shell-script/ | 06:09 |
| poke53281 | Copy and Paste is also fast. | 06:10 |
| stekern | makes it possible to do this: 'or1k-elf-objdump -D bitfield-poke.o | pastie' | 06:10 |
| poke53281 | Hehe | 06:10 |
| stekern | and the previous line in the bash history was the same, except with the 'pastie' replaced with 'less' | 06:11 |
| stekern | yes, copy-paste is fast too, but it's annooying when you have something 'lessed' that takes more than one screen | 06:12 |
| hno | stekern, on Fedora we have fpaste | 06:17 |
| stekern | hno: yeah, yeah, stop reminding me that I should get rid of this (k)ubuntu sh*t =P | 06:22 |
| stekern | I 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 it | 06:24 |
| stekern | but 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 release | 06:25 |
| poke53281 | try archlinux. I like it | 06:29 |
| poke53281 | Rolling release | 06:29 |
| stekern | the problem with switching distro is... I'd have to "waste" time setting up the ws again | 06:30 |
| poke53281 | At least you have choice. Think of all the hundreds of million Windows Users :) | 06:38 |
| hno | stekern, I never upgrade, do a new install into a new lvm volume, keeping /home and some other data. | 06:46 |
| stekern | hno: yeah, that's probably the smart way of doing things | 06:50 |
| stekern | the problems I've seen have been release specific though, not related to the actual upgrade | 06:51 |
| poke53281 | I have switched to 4.8.1. Let's hope the best. Recompiling everything over night | 07:05 |
| stekern | I'm actually on 4.9.0, but I tested compiling with 4.8.1 too, and that seems to be doing the right thing too | 07:12 |
| poke53281 | Promise me that you there will be always one branch of an official stable gcc version | 07:14 |
| stekern | that was precisely my idea with syncing with both the release and svn tip-of-trunk | 07:15 |
| abc_ | Hello | 14:23 |
| juliusb | 3 minutes of waiting... | 14:28 |
| juliusb | and then he was gone | 14:28 |
| juliusb | (or she) | 14:28 |
| juliusb | kids these days, such short attention spans | 14:28 |
| juliusb | although, maybe that's an unfair criticism - there wasn't much to keep that person's attention | 14:29 |
| hno | juliusb, have added "Don't ask to ask, just ask and wait." to some of my channels... | 14:33 |
| hno | in /topic | 14:33 |
| juliusb | oh yes that's a good one | 14:33 |
| juliusb | haha | 14:33 |
| juliusb | someone named "Iscray Openray" has just posted to the opencores list | 14:33 |
| juliusb | and their address is [email protected] | 14:34 |
| juliusb | http://en.wikipedia.org/wiki/Pig_Latin | 14:37 |
| jeremybennett | juliusb: I've replied to him. | 14:53 |
| juliusb | jeremybennett: nice one | 15:16 |
| juliusb | any thoughts on the teleconf call? is today or tomorrow preferrable? | 15:16 |
| juliusb | sorry, I spoke too soon | 15:17 |
| juliusb | thanks very much for organising it | 15:17 |
| jeremybennett | juliusb: NP | 15:42 |
| stekern | working on the mor1kx dtlb reload, I stumbled on an icache invalidate bug | 16:11 |
| stekern | I've fixed it, but it makes me wonder how expensive true dual port rams are in asics? | 16:11 |
| stekern | because by using a dpram I could just connect the spr bus to the second port and remove a lot of annoying logic surrounding that | 16:12 |
| hno | stekern, I would think it | 16:37 |
| hno | it's less expensive in ASIC than in FPGA. | 16:38 |
| hno | stekern, how many bits you need, and how many ports? | 16:44 |
| stekern | hno: in (most) FPGAs (from the major vendors) dpram is no more expensive than spram, the ram blocks are hard dual port rams | 17:06 |
| stekern | it's the RAM that caches the tags, so the size is a bit dependant on the cache setup | 17:07 |
| stekern | oh, and the "dual" in dual port ram should give away the port number ;) | 17:21 |
| stekern | actually, I only need the write side of the second port | 17:21 |
| hno | stekern, so dual write single read? | 17:23 |
| stekern | yup | 18:21 |
| stekern | but with separate write and read on the r/w port | 18:28 |
| stekern | umm, and that was implied by what you said | 18:30 |
| poke53281 | LTP testsuite part memory: Total Tests:80 Total Failures: 24, No total crash | 19:16 |
| poke53281 | But a lot of error messages. Maybe some were on purpose. | 19:18 |
| poke53281 | And a lot of tests didn't work because of missing features like NUMA or shared memory | 19:19 |
| -!- Netsplit *.net <-> *.split quits: mbuf, Logxen, forkG | 19:20 | |
| -!- Netsplit over, joins: Logxen, forkG | 19:21 | |
| -!- Netsplit *.net <-> *.split quits: poke53281 | 19:24 | |
| stekern | passed were > failed at least =P | 19:27 |
| --- Log closed Fri Jul 26 00:00:43 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!