[M3devel] m3cg.i3 reduction?

[Tony Hosking]

On 8 Mar 2010, at 04:15, Jay K wrote:

> The backend interface has a few aspects that the frontend does not use.
> Implementations of these are therefore extremely difficult to test and therefore probably don't work. 

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.

> I propose:
>  
>  
> extract and extract_n should not take a sign_extend:BOOLEAN parameter.
> It is always false.

Only as currently generated by m3front.

>  extract_mn shall retain its sign_extend:BOOLEAN parameter.

For consistency and generality we should retain it for all extract operators.

> Though really, it could go too.
> The front end could just issue divide and the backends could probably
> figure it out. I like the frontend doing the work though.

The front-end should not be concerned with optimisation.  It's job is semantics, and having extract/insert is important for some targets.

>  (Really, if it going to optimize divide by a power of 2, it might be nice
> to compute reciprocals too...on my list for m3back..)

Same.  Front-ends should not be worried about optimising.

>  The integer parameters to extract*/insert* should be CARDINAL instead of INTEGER.
> Or [0..63], with the "63" abstracted out somehow and comments that clarify it is
> really sometimes only 0..31.

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.

> The front end already issues range checks for these parameters.
> The backend shouldn't worry about such wide ranges.

The backend should be prepared for them.

>  Arguably remove insert_m/n and extract_m/n and just have insert/extract.

That is a possibility.  But again, some backends might find it convenient to know about constant operands.  Let's not constrain things.

> The NT386 backend already notices when parameters on the stack are constants,
> and the gcc backend probably does too, at least when optimizing.
> The "specializations" do make it easier for a hypothetical backend simpler
> than the NT386 to optimize a bit.

Precisely!

> So I'm on the fence there.

We should retain them.

>  Zero_n should be removed.

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.

> It isn't used.

Yet...

> Far more radically, I'm suspicious that the use of a stack is a good idea.
> It'd probably be just as easy or easier, and lead to better code, to
> have a *sort* of union that encapsulates constants and variables,
> and pass each "operation" (add/multiply/subtract/insert/extract/etc.) its
> parameters with the function all.

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.

>  
>  
>  - Jay
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100308/7a6becfe/attachment-0002.html>