<table cellspacing="0" cellpadding="0" border="0" ><tr><td valign="top" style="font: inherit;">Hi all:<br>I noticed originally factored code is better, and if its dead then that's optimization.<br>I don't know too much gcc or gdb, but factoring to match open64 (c++) might be better.<br>About Alphas, I know that DEC Firefly was commercialized as SMP VS3520/40 and unrelease V3820/40, given that a DB vendor ported products to it, shouldn't we use their backends to a DB machine?<br>Besides that I think that developing a product for that end is what HP is doing:<br>http://www.zdnetasia.com/hp-aiming-for-data-protection-battleground-62305019.htm?src=newsletter<br><br>That said, alphas wouldn't use gcc but their own backend directed optimizer, like for their DEClanguages internal products.<br>Thanks in advance<br><br>--- El <b>mié, 6/6/12, Dragiša Durić <i><dragisha@m3w.org></i></b> escribió:<br><blockquote style="border-left: 2px solid rgb(16, 16,
255); margin-left: 5px; padding-left: 5px;"><br>De: Dragiša Durić <dragisha@m3w.org><br>Asunto: Re: [M3devel] [M3commit] CVS Update: cm3<br>Para: "Jay K" <jay.krell@cornell.edu><br>CC: "Jay Krell" <jkrell@elego.de>, "m3devel" <m3devel@elegosoft.com><br>Fecha: miércoles, 6 de junio, 2012 05:17<br><br><div class="plainMail">I know that much about generated code :).<br><br>"Good" thing is - not many things changed in *m3 backend since I ported pm3 to LINUX_ALPHA :)<br><br>On Jun 6, 2012, at 11:42 AM, Jay K wrote:<br><br>> <br>> > Functions that call setjmp <br>> <br>> <br>> I meant -- functions wtih TRY/EXCEPT or TRY/FINALLY. :)<br>> <br>> - Jay<br>> <br>> ----------------------------------------<br>>> From: <a ymailto="mailto:jay.krell@cornell.edu" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>>> To: <a ymailto="mailto:dragisha@m3w.org"
href="/mc/compose?to=dragisha@m3w.org">dragisha@m3w.org</a><br>>> Date: Wed, 6 Jun 2012 09:38:18 +0000<br>>> CC: <a ymailto="mailto:jkrell@elego.de" href="/mc/compose?to=jkrell@elego.de">jkrell@elego.de</a>; <a ymailto="mailto:m3devel@elegosoft.com" href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>>> <br>>> <br>>> 5.8.6 does allow many optimizations to occur.<br>>> We turn off a very small number directly.<br>>> Functions that call setjmp have optimizations inhibited by declaring all locals volatile.<br>>> We don't give the compiler good type information, and we take the address of stuff more than necessary, by<br>>> generating very low level code.<br>>> Where you have e.g.<br>>> MODULE Foo;<br>>> TYPE Point = RECORD x,y:INTEGER END;<br>>> PROCEDURE GetY(VAR pt:Point):INTEGER = BEGIN
RETURN pt.y; END GetY;<br>>> <br>>> <br>>> We generate the equivalent of:<br>>> <br>>> <br>>> typedef ptrdiff_t INTEGER;<br>>> typedef char* ADDRESS;<br>>> INTEGER Foo_GetY(ADDRESS pt) { return *(INTEGER*)(pt + sizeof(INTEGER)); }<br>>> <br>>> <br>>> Maybe I'll wrap up 4.6, not enable it, and move on to 4.7..<br>>> <br>>> <br>>> <br>>> - Jay<br>>> <br>>> <br>>> ________________________________<br>>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3<br>>>> From: <a ymailto="mailto:dragisha@m3w.org" href="/mc/compose?to=dragisha@m3w.org">dragisha@m3w.org</a><br>>>> Date: Wed, 6 Jun 2012 10:51:33 +0200<br>>>> CC: <a ymailto="mailto:jkrell@elego.de" href="/mc/compose?to=jkrell@elego.de">jkrell@elego.de</a>; <a ymailto="mailto:m3devel@elegosoft.com"
href="/mc/compose?to=m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>>>> To: <a ymailto="mailto:jay.krell@cornell.edu" href="/mc/compose?to=jay.krell@cornell.edu">jay.krell@cornell.edu</a><br>>>> <br>>>> I am using it, and I need it.<br>>>> <br>>>> Does it run better/faster? I didn't test, but is it something to even<br>>>> ask, these days, architectures, … ?<br>>>> <br>>>> Only if you turned everything off in 5.8.6 and later, as you'r doing it<br>>>> now, then probably my "-O2" default it is of no benefit at all :).<br>>>> <br>>>> Generally, our "pitch" to "sell"<br>>>> super-modern-ultra-blast-mega-fast-superlative-OO and everything else<br>>>> you only dreamed about… And add "no CPU optimizations"… Imagine that.<br>>>> <br>>>> On Jun 6, 2012, at 10:10 AM, Jay K wrote:<br>>>> <br>>>> 7) Do
folks out there really use the Modula-3/gcc optimizer, and notice<br>>>> it produces code that runs much faster?<br>>>> <br>>> <br>> <br><br></div></blockquote></td></tr></table>