<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
> Front-ends should not be worried about optimising.<BR>
<BR>
<BR>
But it does so much already.<BR>
It unrolls comparisons of "solid" types to a certain extent.<BR>
It took me a while to track that down.<BR>
<BR>
It converts divides by powers of two into shift/extract.<BR>
<BR>
<BR>
m3front (or m3middle?) could act as "shared code" for multiple backends.<BR>
Computing the reciprocal is something that would be common<BR>
to various backends. The computation itself is portable.<BR>
The backend could chose to use it or not<BR>
(maybe some processor has a fast divide instruction..or equally<BR>
slow divide and mutiply...).<BR>
<BR>
<BR>
How about TInt.Reciprocal or somesuch?<BR>
<BR>
<BR> > doesn't mean that all upstream clients of m3middle will do so<BR><BR>
<BR>
What other clients of m3middle could possibly exist?<BR>
And that really need more functionality than m3front needs?<BR>
<BR>
<BR>
What does insert/extract with negative numbers mean?<BR>
I'll see if the .i3 files describes it in comments.<BR>
<BR>
<BR>
Please let's not just invent general generalities, that we don't use, and can't test.<BR>
What m3front needs, we should do.<BR>
What m3front doesn't need, we should not do.<BR>
m3middle serves m3front.<BR>
If/when m3front needs it, do it then.<BR>
<BR>
<BR>
Generalities produce dead untestable buggy code and wasted time.<BR>
There was definitely some in m3back, e.g. sign extended<BR>
extract seemed wrong for count = 0.<BR>
<BR>
<BR>
I forgot another suggestion:<BR>
set_eq and set_ne are implemented the same by the two backends,<BR>
by calling memcmp. All the other comparisons are the same too, via<BR>
calling functions. Maybe the frontend should just know about this<BR>
and call the functions? These are unusually high level operations<BR>
in the backends, that neither one implements in an at all clever way.<BR>
<BR>
<BR>
<BLOCKQUOTE> - Jay<BR><BR> </BLOCKQUOTE>
<HR id=stopSpelling>
From: hosking@cs.purdue.edu<BR>Date: Mon, 8 Mar 2010 09:59:41 -0500<BR>To: jay.krell@cornell.edu<BR>CC: m3devel@elegosoft.com<BR>Subject: Re: [M3devel] m3cg.i3 reduction?<BR><BR><BASE>
<DIV><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV style="WORD-WRAP: break-word"><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span><SPAN style="TEXT-TRANSFORM: none; TEXT-INDENT: 0px; BORDER-COLLAPSE: separate; FONT: 12px Helvetica; WHITE-SPACE: normal; LETTER-SPACING: normal; COLOR: rgb(0,0,0); WORD-SPACING: 0px" class=ecxApple-style-span>
<DIV><SPAN style="FONT-SIZE: medium" class=ecxApple-style-span>On 8 Mar 2010, at 04:15, Jay K wrote:</SPAN></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></SPAN></DIV>
<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>The backend interface has a few aspects that the frontend does not use.<BR>Implementations of these are therefore<SPAN class=ecxApple-converted-space> </SPAN><EM>extremely</EM><SPAN class=ecxApple-converted-space> </SPAN>difficult to test and therefore probably don't work.<SPAN class=ecxApple-converted-space> </SPAN><BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>This is inevitable. Your backend is not implementing an interface that the front-end defines. It is implementing an interface defined in m3middle which is much wider than that used by m3front. For good reason, we should not dumb down m3middle just because m3front doesn't make use of all its operations. Similarly, you should not assume that m3front will not make use of some operations in future. This is good practice for separation of concerns in support of modularity.</DIV><BR>
<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>I propose:<BR> <BR> <BR>extract and extract_n should not take a sign_extend:BOOLEAN parameter.<BR>It is always false.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Only as currently generated by m3front.</DIV><BR>
<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> extract_mn shall retain its sign_extend:BOOLEAN parameter.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>For consistency and generality we should retain it for all extract operators.</DIV><BR>
<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>Though really, it could go too.<BR>The front end could just issue divide and the backends could probably<BR>figure it out. I like the frontend doing the work though.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>The front-end should not be concerned with optimisation. It's job is semantics, and having extract/insert is important for some targets.</DIV><BR>
<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> (Really, if it going to optimize divide by a power of 2, it might be nice<BR>to compute reciprocals too...on my list for m3back..)<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Same. Front-ends should not be worried about optimising.</DIV><BR>
<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> The integer parameters to extract*/insert* should be CARDINAL instead of INTEGER.<BR>Or [0..63], with the "63" abstracted out somehow and comments that clarify it is<BR>really sometimes only 0..31.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>That is not a general interface. Just because m3front filters the operands it provides doesn't mean that all upstream clients of m3middle will do so.</DIV><BR>
<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>The front end already issues range checks for these parameters.</DIV></SPAN></BLOCKQUOTE>
<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>The backend shouldn't worry about such wide ranges.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>The backend should be prepared for them.</DIV><BR>
<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> Arguably remove insert_m/n and extract_m/n and just have insert/extract.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>That is a possibility. But again, some backends might find it convenient to know about constant operands. Let's not constrain things.</DIV><BR>
<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>The NT386 backend already notices when parameters on the stack are constants,<BR>and the gcc backend probably does too, at least when optimizing.<BR>The "specializations" do make it easier for a hypothetical backend simpler<BR>than the NT386 to optimize a bit.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Precisely!</DIV><BR>
<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>So I'm on the fence there.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>We should retain them.</DIV><BR>
<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> Zero_n should be removed.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>I've considered using it for some initialisation support. We don't want to throw something out that may later be useful. M3CG was designed for generality, and actually even predates the Modula-3 language itself. It is derived from code generators at DEC SRC from the 1980s.</DIV><BR>
<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>It isn't used.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Yet...</DIV><BR>
<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>Far more radically, I'm suspicious that the use of a stack is a good idea.<BR>It'd probably be just as easy or easier, and lead to better code, to<BR>have a *sort* of union that encapsulates constants and variables,<BR>and pass each "operation" (add/multiply/subtract/insert/extract/etc.) its<BR>parameters with the function all.<BR></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Stack models versus "registers" have always been argued about in compiling. Witness the Java VM spec's use of a stack as compared to the fact that most Java VMs convert the stack to registers for specific targets.</DIV><BR>
<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> <BR> <BR> - Jay<BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR> </body>
</html>