[M3devel] m3front/TInt/TFloat should maintain "textual expressions" for constants?

[Jay K]

 >  However, if you really implement target arithmetic somewhere,
I don't. I just want to print out constants or expressions for a C or C++ compiler to deal with.


My initial goal is a C-generating backend that "work".
The code will be target-dependent and not very debuggable (like what stock debuggers do today with Modula-3).
Longer term, I want the code to be target-endian-indepenent, target-wordsize-independent, target-jmpbuf-independent, and possibly floating-point-representation-independent -- completely target-independent. Floating-point-representation independence doesn't gain anything -- all hosts and targets use the same representation, and I think the current system depends on that anyway (see TFloat). Floating-point-representation independence is "difficult" for "most compilers", but if generating C/C++, I think it is easy.


target-wordsize-independence I believe shall be gained by my proposal here.
target-endian-indepencence I believe shall be gained by small changes in m3front and the existing backends -- m3front only checks endianness in like one or two places.
target-jmpbuf-size-independence I believe shall be gained by roughly the change I made in late 2010, but w/o causing loops to allocate stack for every try "invocation". Or, well, there is likely another way -- some indication to the backend that the variable is a jumpbuf and then outputing "jmp_buf jb" in the C backend..it should be easy enough..add declare_jmpbuf that has the same signature as declare_local, or add a boolean to declare_local. That is more efficient than the alloca(Csetjmp_jmpbuf_size) approach, but doesn't achieve the same gain for m3middle -- that is, even when targeting m3cc, m3front/m3middle ought not have this information -- that would cut out yet one more target-dependence in cm3/m3front/m3middle. Anyway, I'm not to this point yet. I have a fair amount more to do just for target-dependent C to be generated and work. I have made progress, but there is more to do.




 - Jay


> Date: Sun, 19 Aug 2012 16:48:27 -0500
> From: rodney_bates at lcwb.coop
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] m3front/TInt/TFloat should maintain "textual expressions" for constants?
> 
> 
> 
> On 08/19/2012 02:11 AM, Jay K wrote:
> > I propose the following changed to m3front, TInt, TFloat.
> > It does kind of "infact" the front/middle end with the "intent" of a specific backend.
> >
> >
> > When a TInt or TFloat is initialized from text, that text is remembered.
> > When such a TInt/TFloat is added/subtracted/multiplied/divided by another,
> > the obvious text is built up in the target.
> >
> >
> > Initialization of TInt with constants could/should also maintain the textual representation.
> >
> >
> > The implication is multi part:
> >
> >
> > 1) init_float in a C-or-such backend can just output the textual expression.
> > No need to worry about roundtripping it.
> >
> >
> > 2) Longer term, TInt "constant expressions" could contain like "sizeof(INTEGER)"
> > (preceded by a typedef for INTEGER in the larger context)..thereby factoring
> > out the target from the generated C.
> >
> >
> > 3) This provides some hypothetical portability when host/target
> > don't use the "same" sort of floating point. Ignoring rounding details however.
> > And TFloat does seem to round correctly at compile-time, assuming host/target
> > are about the same -- and they all are.
> > (What does the language definition say here anyway? I'll have to check..)
> >
> 
> As far as I can find, the language says nothing about this.
> 
> However, I feel *extremely* strongly that arithmetic done at
> compile time should be *exactly* the same as on the target machine,
> including what happens in exceptional cases, e.g., overflows,
> NaNs, etc.
> 
> I know this can be hard to get right, and it raises hard questions
> about division of work between front/back.  Even harder when there
> are multiple back ends, especially ones you don't control.
> But I consider it a serious compiler bug if CT and RT arithmetic
> differ.  This might be something that could be postponed for more
> urgent things, but the design at least should anticipate it.
> 
> I have no problems with the principal of preserving/generating
> textual representations.  However, if you really implement target
> arithmetic somewhere, it might be easier to convert back and forth
> than to do faithful target arithmetic on character strings.  If
> that is what you are referring to as {not} roundtripping.
> 
> >
> > Reasonable?
> >
> >
> > For now I'll probably punt.
> >   I can just use TFloat.ToChars and munge it slightly.
> > But this is probably a good direction.
> > In the short term I'm trying hard to make do w/o m3front/m3middle changes.
> >
> >
> > You know..implementing another backend, you tend to visit more of the system,
> > gradually understand it..think of what you how one might prefer it to be..esp.
> > for the task at hand. :)
> >
> >
> > Obviously this is somewhat of a hack, in that...what should the syntax of the expressions be?
> > If/when I make the change, I'll probably use C. It will be almost identical to Modula-3 anyway.
> >
> >
> >   - Jay
> >
> >
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120819/30243f43/attachment-0002.html>