[M3devel] what is wrong with TIntN?

[Jay K]

So, if I just move the code to m3back, you are ok?Clearly m3middle is for front and backends though. i.e. at least Target, TInt, TFloat is needed by both/all.How does m3front get away w/o having similar functionality?


What is the meaning of: CONST a = 16_7FFFFFFF + 1;  CONST b = 16_7FFFFFFF + 1 - 1;  


for a 32bit target?

or CONST c = 16_7FFFFFFFFFFFFFFFL + 1;  CONST d = 16_7FFFFFFFFFFFFFFFL + 1 - 1; 

(I should try them and see and read code, granted.I should read more of m3front in general.)


Restated, clearly larger-than-host-integer precisionarithemetic is needed by the frontend. But I don't seethat it is sufficient to have fixed-64-bit-precision arithmetic.It seems to me you would want to further "type" or restrictthe precision, depending on context, to one of INT8, UINT8, INT16,UINT16, INT32, UINT32, INT64, UINT64.(where "unsigned" is perhaps "half interval", 0 to the maximum signednumber of that precision...though this half interval stuff stillmakes me uneasy..but I grant that TInt does not implement full range64bit unsigned math, it is really a portable INT64).


What I can't immediately guess with high confidence is if the "typing"is appropriate for intermediate results, or only final results.i.e. range checking all along, or only upon some conversion at the end.


I guess, again, I should read m3front and the language spec more.

Also, regarding m3middle..M3CG_Ops.i3 does lend itself to an intermediaterepresentation. In-memory that can be processed in multiple passes.I realize using it as such isn't very creative and ultimatelyone would want to augment it further. But it is useful.

And so there is the idea that m3middle is code of use to multiple backends,even if not to the frontend at all.

As well, the idea of actual "shared middle ends" or shared passes.i.e. in M3C I eliminate unused local variables.(not through sophisticated analysis like eliminating locals thatare only ever written to..though I could do that...but locals thatare neither written to nor read from. If M3CG were in-memory "in an array"and that was a common interface to multiple backends, this trasnformcould be shared among backends, or heck, always applied as a matter of course.

It kind of seems to me that backends should have some characteristicsdescribed about them, communicated to the frontend, like requestingthe frontend interface with them in one of two or three ways, andrequesting certain passes be applied before them.

Or, look how gcc is structured, as a series of passes.We could do that.passes:  m3front   m3cg function calls to in-memory format   eliminate unused locals   compute operations x types -- i.e. discover if extract is      applied to int32 and/or int64, for backends that want to output     helper functions; not all targets care  compute or estimate maximum compile-time stack depth -- I've been     tempted to add this, but so far haven't done it; it is easy to estimate;     my motivation isn't good -- it is that I don't like the Modula-3     generic mechanism and how it steers me toward "RefSeq" and lots of     NARROW() operations -- slower than needed. I'd rather use an open array     if I can compute the right size early.  move imports ahead of everything   compute frames, maybe 

These can all be done reasonably well with the "obvious" internalrepresentation, plus just a little extra data.

I guess what I'm saying is there could/should be more shared code forbackends. Given the two in existance today, that isn't really true, theyare too different.But it is perhaps true if we had some other mix of backend implementations.

Granted, LLVM does "everything" itself anyway, all those passesare trivial for it, most likely. It doesn't need any help.



 - Jay



From: hosking at cs.purdue.edu
Date: Thu, 25 Oct 2012 10:37:57 -0400
To: jay.krell at cornell.edu
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] what is wrong with TIntN?

The problem is that you are trying to bring front-end mechanisms into the backend.If you want to perform optimizations in your backend they should be standalone and independent of the front end.For example, the llvm backend can perform a whole bunch of optimizations in its own IR.TInt is a service provided by m3middle to the front-end.Feel free to add whatever you like to your backend.  I just don’t want to see unnecessary stuff introduced into m3middle.
On Oct 25, 2012, at 4:12 AM, Jay K <jay.krell at cornell.edu> wrote:When faced with

VAR a := FIRST(INTEGER) + 1;VAR b := LAST(INTEGER) + 1;VAR c := LAST(INTEGER) + 1 - 1;VAR d := (a > 0);

I would like backends to optimize initialization a,not optimize initialization of b,and probably not optimize initialization of c,and hopefully optimize initialization of d, but that is moredifficult in the C backend.

Fold constants when it is obviously safe.Do not fold constants when there is a chance of overflow -- evenat intermediate points of the expression.

This is why I believe TIntN is useful.

I bring this up because I'm about to add constant folding to M3C.m3.And to introduce use of TIntN.Which Tony has insisted is wrong, i.e. use in M3x86.m3.


Thanks, - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20121025/63d5d60d/attachment-0002.html>