<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 31 Jan 2017 8:58 p.m., "Kostya Serebryany" <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>hmm. I am not sure I understood you. The last two paragraphs seem to contradict each other. </div><div>So, you recommend to extend read_register to read the PC, or </div><div>"read_register is locked at the stack pointer as a design decision"?</div></div></div></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">Both. :-)</div><div dir="auto"><br></div><div dir="auto">There was a design decision to only support SP because we had no clear case for anything other than the stack pointer. </div><div dir="auto"><br></div><div dir="auto">If you have one for the PC, it would be a much better technical decision to reuse the machinery that already exists, is documented and tested, than come up with an independent implementation. </div><div dir="auto"><br></div><div dir="auto">The discussion whether to support it in clang or not is orthogonal. But once decided that we should support reading the PC, then read_register is the obvious place. </div><div dir="auto"><br></div><div dir="auto">If the clang developers refuse the idea, then inline assembly is the only option that would work across compilers. </div><div dir="auto"><br></div><div dir="auto">Makes sense? </div><div dir="auto"><br></div><div dir="auto">Cheers, </div><div dir="auto">Renato </div><div dir="auto"></div></div>