00:02 <GitHub-m-labs> [artiq] sbourdeauducq commented on issue #854: mmc firmware? https://github.com/m-labs/artiq/issues/854#issuecomment-377649069

00:08 <mithro> sb0: Would you be open to type annotations (https://www.python.org/dev/peps/pep-0484/) in migen / misoc code? -- I'm not sure I _actually_ like the idea, but if you say No then there isn't even any point in entertaining the idea

00:11 <mithro> sb0: I'm very unsure if your response would be "hell no" or "hell yes" to that idea :-P

00:52 <sb0> mithro, for what?

00:53 <mithro> sb0: Not sure yet - possibly things like the interconnect / hdl stuff?

01:50 <sb0> well I cannot see how...

01:50 <sb0> and why?

02:58 <sb0> whitequark, are you going to test the mor1kx bus errors? or should I do it?

03:00 <sb0> this is a bit tricky with the write buffer

03:00 <sb0> unless it is bypassed for non-cacheable accesses?

04:36 <whitequark> sb0: I'll test them

04:36 <whitequark> just woke up, finishing package building, might as well do something useful meanwhile

07:11 <whitequark> sb0: mor1kx indeed has precise exceptions for bus accesses even with store buffer

07:12 <whitequark> the way it works is, well, it stores the PC for every access, and that is used when an error is raised

07:14 <whitequark> so when the exception is raised, some instructions could have executed past the exception PC, but the EPCR is correct

07:15 <whitequark> in other words, synchronous and precise but not immediate

07:55 <cr1901> "some instructions could have executed past the exception PC, but the EPCR is correct" How are those insns that went past the exception PC "rolled back"?

07:56 <whitequark> they aren't

07:56 <whitequark> lol

07:57 <cr1901> oh...

08:00 <cr1901> That... seems like it could be a problem lol

15:48 <mithro> sb0: Why? Because sphinx (and other tools) have added support for using them in things like documentation for better cross-linking and similar. I'm going to put it into the "leave for another time" bucket for now

15:48 <sb0> but what do they indicate?