<html><head><base href="x-msg://1277/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>The front-end does do that for known calls. But not for arithmetic ops. You will need to cope in the backend. But, there have always been calls for mod/div, so I think it really comes down to the back-end needing to do the right thing.<br>
<br><div><div>On 6 Feb 2010, at 07:29, Jay K wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="hmmessage" style="font-size: 10pt; font-family: Verdana; ">Tony, can you confirm something?<br>It's hard to explain.<br> <br><br>The NT36 backend of course maintains<br>a bunch of information as to which registers are in use.<br><br> <br>For example, at the start of the function, it<br>marks all registers as not in use.<br> (It always preserves all volatile registers I believe.<br> Obviously it could do better. It should only<br> mark non-volatile registers as in use, see<br> which registers it uses in the function, and<br> then only preserve/restore the nonvolatile ones<br> that it uses.)<br><br> <br>As well when it generates a function call it<br>marks them as all not in use too.<br>But in that case, it checks itself.<br>Again, it is a bit dumb -- nonvolatile registers<br> would be ok to still be in use.<br> <br><br>Now, all is ok.<br>But then, I've introduced function calls where<br>they weren't before -- multiply, divide, mod etc.<br> <br><br>Upon generating the call to mod (for example),<br>I get an assertion failure, because registers<br>are still in use. In this case it is a nonvolatile<br>register, but I think that's largely luck.<br> <br><br>In particular I think the location that<br>will be stored to after the mod is in a register.<br>That is reasonable.<br>You know..as a compiler, given:<br> *(a + b) = f();<br><br> <br>you might generate code to evaluate a + b first,<br>put it in a (non volatile) register, then call f(),<br>or you might call f() first.<br> <br><br>A simpler approach is to call all the functions first,<br>so you have more easy use of registers.<br> <br><br>But then imagine<br> *(a + b) = (c % d);<br><br> <br>is there a function call in there or not?<br>It depends.<br><br> <br>So then my question is, like, when does the<br>frontend assume a "stack based code generator"'s<br>stack can/should/will be empty?<br>Does it endeavor to make it so?<br> <br><br>That is, is it very reasonable to for the NT386<br>backend to assume its stack is empty when<br>it calls a function, because the front end<br>colludes to make it so, but then<br>the front end doesn't do similar for things<br>like multiply/divide?<br> <br><br>I can deal with this pretty easily either way.<br>Around function calls I introduce that weren't<br>previously there I can save whatever volatile<br>registers are in use.<br> <br><br>But I'd like to understand.<br> <br><br>Thanks,<br> - Jay<br></div></span></blockquote></div><br></div></body></html>