<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> But, there have always been calls for mod/div<BR><BR>
Not on NT386.<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
Subject: Re: front end function about a "virtual stack"<BR>From: hosking@cs.purdue.edu<BR>Date: Sat, 6 Feb 2010 13:07:23 -0500<BR>CC: m3devel@elegosoft.com<BR>To: jay.krell@cornell.edu<BR><BR><BASE>
<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=ecxApple-interchange-newline>
<BLOCKQUOTE><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: medium Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="FONT-FAMILY: Verdana; FONT-SIZE: 10pt" class=ecxhmmessage>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>