<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
The backend interface has a few aspects that the frontend does not use.<BR>
Implementations of these are therefore <EM>extremely</EM> difficult to test and therefore probably don't work. <BR><BR>
<BR>I propose:<BR>
<BR>
<BR>
extract and extract_n should not take a sign_extend:BOOLEAN parameter.<BR>
It is always false.<BR>
<BR>
<BR>
extract_mn shall retain its sign_extend:BOOLEAN parameter.<BR>
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>
(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>
<BR>
<BR>
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>
The front end already issues range checks for these parameters.<BR>
The backend shouldn't worry about such wide ranges.<BR>
<BR>
<BR>
Arguably remove insert_m/n and extract_m/n and just have insert/extract.<BR>
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>
So I'm on the fence there.<BR>
<BR>
<BR>zero_n should be removed.<BR>
It isn't used.<BR>
<BR>
<BR>
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>
<BR>
<BR>
- Jay<BR><BR> </body>
</html>