IRC logs for #openrisc Tuesday, 2012-09-04

stekernso SI = signed32 and DI = signed64, which explains why that change breaks on 32-bit machines, since the incoming value is a long05:27
juliusbI reckon it's worth a post to the CGEN mailing list about it12:43
juliusbIt's not too active, but you may get a bite12:43
stekernjuliusb: I'm not sure how I should phrase a question there12:47
stekerndid you see the post to our ML?12:47
juliusbsorry, I didn't fully get it, the problem was caused by the SI being changed to DI in the opcodes/or1k-ibld.c file, right?13:01
juliusband your fix was to change cpu/or1korbis.cpu in the way you pasted, where IAI should be SI13:02
stekernbut the commit we looked at yesterday (the one with massive changes to cpu-files), doesn't change that line13:03
stekernstill, the SI -> DI happens in that commit13:03
stekernso somewhere hidden in the massive cpu-file changes is something else that makes the SI go DI13:04
juliusbno, that's just the regeneration of the CGEN files13:06
stekernI'm speaking about 1d4d4eac0d93d514ad37db18cf04c542062d51b913:07
juliusbthe source file cpu/or1korbis.cpu changed with commit 7231606b799b79b305eb43e3709e5bebf2c39bfb13:07
juliusbso a checkin of the source file, without the regeneration, will plant the seed for the bug, but you won't see it until later13:08
juliusbuntil the commit of the regenerated files13:08
stekerneeh, what tree are you looking at?13:08
juliusbisn't that the rigt one?13:08
stekernjust that our commit # doesn't match up13:09
juliusbsorry, I'm being confusing aren't I?13:09
stekernit's 1d4d4eac0d93d514ad37db18cf04c542062d51b913:10
juliusbbasically, I think the change to the cpu/or1korbis.cpu file causing the 32-bit breakage occurs with the change to the disp26 definition (change from "sra WI (..." to sra IAI (...")13:11
stekernI regenerated the cpu files in that commit too, and SI went DI, so it's that one for sure13:11
stekernno, because sra WI is still in that commit13:12
stekernand SI goes DI there13:12
juliusbso you took the tree back to 1d4d4... and regnerated the opcodes files and the bug manifested itself there?13:13
stekernspot on13:13
juliusbbut... not in the one before it?13:14
juliusbOk, thanks for walking me through this :) I get it  now13:15
juliusbcould it be the case that parts of the tree weren't committed but were used to regenerated the opcodes stuff?13:16
juliusbbut... no, if you get the exact same result, ie. the SI->DI in opcodes/or1k-ibld.c at that stage too, then it must just be something in the tree there causing that13:17
juliusbin the tree that is committed13:18
stekernI'll do a sanity check and regenerate on the commit before 1d4d4 again13:18
stekernyup, still SI on that one13:23
juliusbSo the change of the df f-disp26 encode thing of WI to IAI in 7231606b7... isn't at all relevant. The bug was there whether that used WI or IAI, but the fix is to change IAI back to SI13:23
juliusbwhat happens if you change WI to SI for f-disp26 encode with the code at commit 1d4d4...?\13:24
juliusbit'd surely stick to the SI?13:24
juliusbso... therefore it's definitely something else which effected it there13:24
juliusband it _must_ have been something which is in the tree there because you're seeing the change, too13:25
juliusbCan I be annoying and ask you to regenerate the opcodes files at commit state 1d4d4... with removing the (MACH ORBIS-MACHS) from the PCREL-ADDR line?13:27
juliusbleaving everything else as it was at that state, and seeing if the DI->SI change occurs13:27
juliusb... or maybe you've already tried that?13:27
juliusbThat's the only major change I can see in the f-disp26 definition13:28
stekernyes, I tried removing the MACH ORBIS-MACS, no effect13:28
juliusbalso, the PC hardware definition changes13:28
juliusbin the 1d4d4... change13:28
stekernyup, no effect13:29
juliusbbut you tried that yesterday didn't you?13:29
juliusbI see the ORBIS-MACHS definition is or32,or6413:29
juliusb+(define-pmacro ORBIS-MACHS   or32,or64)13:29
stekernand changing WI to SI gives SI back from DI13:29
juliusbwhat happens if you remove or64 there13:29
juliusbHmm, there's also this change:13:31
juliusb-(dsh h-delay-insn "delay insn addr" () (register SI))13:31
stekernlet's see13:31
juliusb+(dsh h-delay-pc "delay insn addr" () (register IAI))13:31
juliusbwhich is introducing the IAI version to the delay slot13:31
juliusbbut I don't really get the dsh definition thing, just reading up on it13:31
stekernmmm, let's try that next13:31
juliusbbut yeah I'd try removing or64 to see if it has any effect13:32
stekernwe're great at shootgun debugging! =)13:32
juliusbwell it _must_ be in this commit13:32
juliusbI'd try some of the more obvious ones, hopefully it's not too long to do right, if I recall, running opcode generation wasn't too long13:33
stekernok, removing or64 didn't make DI->SI happen13:33
stekernyeah, it doesn't take long, except I'm on the slow 32-bit machine now13:34
juliusbhuh? the bug was SI->DI, you mean it didn't fix it?13:34
juliusbIt didn't reverse the bug you mean?13:34
stekernI'll rephrase: removing or64 didn't have any effect13:34
juliusbumm, dsh is: Scalar registers with no special requirements occur frequently. Macro define-simple-hardware (with alias dsh) is identical to dnh except does not include the indices, values, or handlers13:35
stekernwhere is that dsh?13:35
stekernah, or1kcommon13:36
juliusbi dunno, left column says 214 for old line, and 262 for new line13:36
juliusbI kinda guess this won't change things, though? maybe?13:37
juliusbmaybe there's some magical link via h-delay-pc?13:37
juliusb(to PC encoding ops)13:38
juliusbbut.... I'm doubting it actually, but worth a try13:38
juliusbahhh, also, l-bf flags have had changes inserting IAI as the format for PC13:40
juliusberrr, l-bf definitions13:40
juliusbin cpu/or1korbis.cpu, we see13:41
juliusb-   (delay 1 (set pc disp26))13:41
juliusb+   (delay 1 (set IAI pc disp26))13:41
stekernchanging IAI to SI on the dsh didn't have any effect13:41
stekernmmm, but the SI->DI is in insert_operand, I can't imagine that it is generated from the 13:43
stekernis h-iaddr something magic?13:43
juliusbi was looking at that too, but there appears to be no change to its definition13:45
juliusbIsn't it possible that the l-bf definitino change is effecting it?13:49
juliusblike, it may fix it to change DI->SI in the opcode insertion bit13:49
juliusbbut maybe the fact that it's also a change from SI->DI in the l-bf operand checking code or something, also makes it break13:49
stekernyeah, but you have that change in l-bnf and l-j too13:51
stekernworth a shoot still, I'm building with IAI removed on all of those13:51
stekernnope, no change13:51
juliusbwtf is it then!?14:01
stekernwe're all out of shotgun shells :/14:07
stekernI'm suspecting the or64-bit changes though14:55
stekernlooking in mode.scm14:55
stekern; This is defined by the target in define-cpu:word-bitsize.14:55
stekern(define WI #f)14:55
stekern(define UWI #f)14:55
stekernand the IAI and AI have similiar comment14:55
stekernotoh, that comment make me believe we _should_ explicitly use SI on the instructions, since they are 32-bits in or64, right?14:59
stekernjupp, removing some more or64 stuff give me a SI15:04
stekernor just changing the or64 word-bitsize to 3215:10
stekernI wonder if the or64 bit stuff even could work on a 32-bit machine (without changing core cgen stuff)15:14
juliusbOK, but data word is 64, insn word is still 3215:39
juliusbso, not sure what that word-bitsize you mentioned before pertains to15:39
stekernyeah, me neither, but I guess it's still handy in some cases with the WI/UWI/IAI/AI changing bitsize according to the bitsize of the target20:28
stekernmakes me nervous what other surprises might be lurking though...20:29

Generated by 2.15.2 by Marius Gedminas - find it at!