[M3devel] m3cg.i3 reduction?

[Jay K]

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. 



I propose:

 

 

extract and extract_n should not take a sign_extend:BOOLEAN parameter.

It is always false.

 

 

extract_mn shall retain its sign_extend:BOOLEAN parameter.

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.

 (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..)

 

 

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.

The front end already issues range checks for these parameters.

The backend shouldn't worry about such wide ranges.

 

 

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

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.

So I'm on the fence there.

 


zero_n should be removed.

It isn't used.

 

 

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.

 

 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100308/18f52ea3/attachment-0001.html>