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