IRC logs for #openrisc Tuesday, 2012-11-20

@juliusbupdated arch spec:
-!- maximi89_ is now known as maximi8904:20
@stekernjuliusb: nice04:21
@stekernor1200-simple passes as well now, I had to seperate the lsu address from the "real" alu results that is registered onto mem stage, since the alu result might be needed for pipeline forwarding05:05
@stekernnow the first fail is in or1200-basic, and that test is really annoying05:11
@stekerna long series of tests that all depend on the result of the previous test and just one check to see if the end result match up05:12
@stekernman, hazard handling is a b*tch...07:58
@olofkjuliusb: Great. I'll try to read through it today and give you comments09:39
@stekernbah, I realise that the second mail about returning structs was a bit confused too...09:42
@stekernif your not returning by value your not really returning a struct, but a pointer...09:43
@stekernnevertheless, the original text should still be there, the address is also put in the RV-register.09:49
@olofkhmm.... I think yaml is a hot candidate for next version of orpsoc's core descriptions. I was shown some problems with python's configparser12:44
@olofkjuliusb: You're the yaml expert, right? :)12:44
@juliusbolofk: I've used it now and then, yes13:19
@juliusbactually, i've used it a lot with the Python parser13:25
@juliusbthose two things together are awesome13:25
@juliusbphew, I finally waded through the carry/overflow discussion15:57
@juliusbif people are happy I can roll this into the or1k spec update draft too15:59
@juliusbI'm with jeremybennett on asking rdiez to cross-post. He's being purposefully annoying and I think his arguments for why he does it aren't convincing16:05
jeremybennettjuliusb: Thanks for the support16:45
@juliusbYep, and good on you for telling him to pull his head in17:32
@juliusbhmm, i just realised that may have been Australian vernacular you're not familiar with17:33
jeremybennettjuliusb: Always useful to broaden one's vocabulary.17:38
@juliusbone thing I wanted to ask was whether we think the multiply and overflow stuff is solid enough (pgavin only put it up on the wiki a few days ago) to roll into the current architectural updates17:38
@juliusbit seems well thought through though17:38
@olofkjeremybennett: Yes, you have my support too, and thanks for dealing with it. I haven't had anything constructive to add to the argument, so I have kept quiet17:57
jeremybennettjuliusb: could you give me a wiki pointer18:28
jeremybennettolofk: Thanks for your support. Even if you don't have anything to say, it might be worth a one liner response to say you agree. If Ruben starts to see the whole community agrees, he might change. He has some good stuff to say, he's just being annoying how he says it.18:29
@juliusbthat was meant for the ex-jeremybennett18:52
jeremybennettjuliusb: Yes - that looks clean. The CYE flag is a good idea, but remember it will have a knock-on effect for other opcodes.19:02
jeremybennettJust thinking this through. On the whole arithmetic exceptions are used for erroneous behavior, like divide by zero, because of the high cost of an exception.19:03
jeremybennettYou really don't want CYE triggering when doing a multi-word addition. So you could be in a situation where you are forever turning CYE on and off.19:04
jeremybennettl.div and l.divu need similar changes.19:07
jeremybennettBTW - where should commentary go? On the talk page I presume.19:10
jeremybennettComments added to the talk page19:35
@juliusbI think we should have an exception triggerable by a divide-by-zero19:40
@juliusbor maybe, have an arithmetic exception config register, where you pick if overflow, carry or divide-by-zero trigger exceptions, then when they do, trip a range exception, and have another register indicating what caused the range exception19:41
@juliusbthat we we keep the single exception bit in the SR and have a very configurable, neat way of dealing with arithmetic exceptions19:41
@juliusbsimilar to the floating point stuff, where you can trigger on various things19:42
@juliusbhowever, it probably adds an extra bit of state you'll need to maintain between contexts19:53
@juliusbbut, we already have a few of those don't we? MAC SPRs are one19:54
@juliusbMy suggestion doesn't go to the case where CYE needs to be switched off for multiword addition19:59
@juliusbyou could make it user R/W and have GCC emit instructions which clear the bit before doing a known multi-word addition20:00
@juliusbGCC doesn't emit add-with-carry now20:00
@juliusbso, does long long additiion fail?20:00
jeremybennettHave you looked in gcclib at the hand-written assembler?20:18
jeremybennettsorry libgcc I mean20:18
@juliusbnot lately...20:22
jeremybennettyou might find it is used there...20:22
@juliusbthere's or1k-specific stuff in libgcc?20:22
jeremybennettYes - assembly functions for soft-mul etc.20:22
jeremybennettAt least I think that's where they are.20:22
jeremybennettThey are somewhere in there!20:23
@juliusbNope, none in or1k-gcc/libgcc/config/or1k20:23
@juliusbappears to not be used anywhere20:27
jeremybennettHa ha - you've just found a bug I think. Hold on while I check...20:30
jeremybennettWhat should this print out?20:30
jeremybennett#include <stdio.h>20:30
jeremybennettmain ()20:30
jeremybennett  long long int  x, y, z;20:30
jeremybennett  x = -1LL;20:30
jeremybennett  y = -1LL;20:30
jeremybennett  z = x + y;20:30
jeremybennett  printf ("z = %lld\n", z);20:30
jeremybennettOr1ksim at least gets it wrong.20:35
jeremybennettBut a look at the code suggests it might be the printf that is the problem?20:35
jeremybennettI think it fails to correctly take z as being of type long long20:36
@juliusbim compiling some stuff and looking into it20:39
jeremybennettThat could be it failing to recognize "ll" as a length modifier.20:39
@juliusbit looks right20:39
@juliusbbut just checking it in my own head20:39
jeremybennettIt should print -2, but Or1ksim prints -120:39
@juliusbit's not using carry, it's checking if the lower 32-bits wrapped and if so adding 1 to the addition of the upper 32-bits20:39
jeremybennettAgreed - I thought it would use a library routine, but it does not. Clearly somewhere optimization could be applied!20:40
@juliusbit's not using a library routine for me20:40
jeremybennettNor me.20:40
jeremybennettThere is however the question of the printf bug. That might be a newlib limitation of course.20:40
@juliusbit looks like the upper 32-bits of a long long argument is passed in r3 and lower 32-bits in r420:41
jeremybennettIn my version, it's passed in r4/r5 (r3 is used for the printf string)20:44
jeremybennettr5 has the lower 32-bits20:44
jeremybennettHow was that compiled to get that listing?20:45
@juliusbor1k-elf-gcc -c -O220:45
@juliusbthen or1k-elf-objdump -d20:45
@juliusbAnyway, question answered, long long maths should work20:47
@juliusbyou could skip the branch, though, if it used l.addc20:47
jeremybennettYes - but printf doesn't print them out properly, at least with newlib and Or1ksim.20:47
jeremybennettAre the comments in pastebin hand-added by you?20:48
@juliusbSorry, I should have mentioned, that I annotated it20:48
jeremybennettAh - I thought it must have been some whizzo gcc 4.8 output mode, which put intelligent comments into the code it generated.20:48
@juliusbhaha, I wish20:49
@juliusbmust run, bye20:50

Generated by 2.15.2 by Marius Gedminas - find it at!