<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'>This should all be fixed now in the NT386 backend. Verification welcome.<div><br></div><div>Work could be shifted to the frontend for some of this, perhaps.</div><div><br></div><div> - Jay</div><div><br><div><hr id="stopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Subject: RE: Grisu vs. NT386<br>Date: Tue, 26 Jul 2016 06:42:28 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">I think I can fix the nested helper call easily enough in the backend.<div><br></div><div>But note that NT386 is definitely currently broken since the introduction of Grisu.</div><div><br></div><div>We might also consider having the frontend always form parameters into temporaries.</div><div><br></div><div>Not clear if it should do this as needed for a few known cases, like LONGINT multiplication, or for all integer and float operations on all types, despite most of them not requiring function calls.</div><div><br></div><div>Also not clear wrt longer standing helper functions like div/mod.<br><div><br></div><div> - Jay<br><br><div><hr id="ecxstopSpelling">From: jay.krell@cornell.edu<br>To: m3devel@elegosoft.com<br>Subject: Grisu vs. NT386<br>Date: Mon, 25 Jul 2016 07:27:46 +0000<br><br>
<style><!--
.ExternalClass .ecxhmmessage P {
padding:0px;
}
.ExternalClass body.ecxhmmessage {
font-size:12pt;
font-family:Calibri;
}
--></style>
<div dir="ltr">Fyi, Grisu reveals at least two problems in the NT386 backend.<div>In particular, it uses LONGINT, and we don't have much code that does.</div><div><br></div><div>The two problem are that NT386:</div><div> - generates function calls for e.g. 64bit integer muliplication</div><div> - doesn't like generating function calls within function calls, i.e.</div><div> VAR a,b: LONGINT;</div><div> Foo(a * b);</div><div><br></div><div>It fails an assert -- when it goes to do the multiply, which is a function call, it asserts that no function call is in progress.</div><div><br></div><div>For now I'll change Grisu:</div><div><div> VAR a,b,t: LONGINT;</div><div> t := a * b;</div><div><div> Foo(t);</div></div><div><br></div><div>but fixing NT386 shouldn't be difficult.</div><div><br></div><div>Really, we should allow for:</div><div> Foo(Bar(a * b) * b);</div><div><br></div><div>.. the thing is, the frontend handles this -- it produces temporaries for function return results:</div><div> t1 := Bar(a * b);</div><div> Foo(t1 * a * b);</div><div><br></div><div>but it doesn't do so for things like add/subtract/multiply/divide. Perhaps it should.</div><div>Decent backends, including possibly NT386, will enregister the temporaries and generate good code anyway.</div><div><br></div><div>Thoughts?</div><div><br></div><div>The alternative is NT386 needs to maintain a stack where it doesn't previously -- a stack of pending function calls.</div><div><br></div><div><br></div><br>2) Grisu uses loophole between LONGREAL and LONGINT. This is reasonable, but perhaps not previously seen.</div><div>NT386 requires loopholes that convert between integers and floats to be using REAL, at least for one direction.</div><div>This seem merely historical and it should allow LONGREAL, or in particular, it should require no size change.</div><div>Historically NT386 backend maintained an internal stack, of 32bit sized things -- variables and constants.</div><div>I extended that to be variably sized, i.e. 32bits or 64bits, but this code wasn't updated. It should be trivial, maybe just relaxing the assertion.</div><div><br></div><div><br></div><div> - Jay</div><div><br></div> </div></div></div></div> </div></div></div> </div></body>
</html>