[M3devel] [M3commit] CVS Update: cm3

[Daniel Alejandro Benavides D.]

Hi all:
I noticed originally factored code is better, and if its dead then that's optimization.
I don't know too much gcc or gdb, but factoring to match open64 (c++) might be better.
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?
Besides that I think that developing a product for that end is what HP is doing:
http://www.zdnetasia.com/hp-aiming-for-data-protection-battleground-62305019.htm?src=newsletter

That said, alphas wouldn't use gcc but their own backend directed optimizer, like for their DEClanguages internal products.
Thanks in advance

--- El mié, 6/6/12, Dragiša Durić <dragisha at m3w.org> escribió:

De: Dragiša Durić <dragisha at m3w.org>
Asunto: Re: [M3devel] [M3commit] CVS Update: cm3
Para: "Jay K" <jay.krell at cornell.edu>
CC: "Jay Krell" <jkrell at elego.de>, "m3devel" <m3devel at elegosoft.com>
Fecha: miércoles, 6 de junio, 2012 05:17

I know that much about generated code :).

"Good" thing is - not many things changed in *m3 backend since I ported pm3 to LINUX_ALPHA :)

On Jun 6, 2012, at 11:42 AM, Jay K wrote:

> 
>  > Functions that call setjmp 
> 
> 
> I meant -- functions wtih TRY/EXCEPT or TRY/FINALLY. :)
> 
>  - Jay
> 
> ----------------------------------------
>> From: jay.krell at cornell.edu
>> To: dragisha at m3w.org
>> Date: Wed, 6 Jun 2012 09:38:18 +0000
>> CC: jkrell at elego.de; m3devel at elegosoft.com
>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>> 
>> 
>> 5.8.6 does allow many optimizations to occur.
>> We turn off a very small number directly.
>> Functions that call setjmp have optimizations inhibited by declaring all locals volatile.
>> We don't give the compiler good type information, and we take the address of stuff more than necessary, by
>> generating very low level code.
>> Where you have e.g.
>> MODULE Foo;
>> TYPE Point =  RECORD x,y:INTEGER END;
>> PROCEDURE GetY(VAR pt:Point):INTEGER = BEGIN RETURN pt.y; END GetY;
>> 
>> 
>> We generate the equivalent of:
>> 
>> 
>> typedef ptrdiff_t INTEGER;
>> typedef char* ADDRESS;
>> INTEGER Foo_GetY(ADDRESS pt) { return *(INTEGER*)(pt + sizeof(INTEGER)); }
>> 
>> 
>> Maybe I'll wrap up 4.6, not enable it, and move on to 4.7..
>> 
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>>> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
>>> From: dragisha at m3w.org
>>> Date: Wed, 6 Jun 2012 10:51:33 +0200
>>> CC: jkrell at elego.de; m3devel at elegosoft.com
>>> To: jay.krell at cornell.edu
>>> 
>>> I am using it, and I need it.
>>> 
>>> Does it run better/faster? I didn't test, but is it something to even
>>> ask, these days, architectures, … ?
>>> 
>>> Only if you turned everything off in 5.8.6 and later, as you'r doing it
>>> now, then probably my "-O2" default it is of no benefit at all :).
>>> 
>>> Generally, our "pitch" to "sell"
>>> super-modern-ultra-blast-mega-fast-superlative-OO and everything else
>>> you only dreamed about… And add "no CPU optimizations"… Imagine that.
>>> 
>>> On Jun 6, 2012, at 10:10 AM, Jay K wrote:
>>> 
>>> 7) Do folks out there really use the Modula-3/gcc optimizer, and notice
>>> it produces code that runs much faster?
>>> 
>> 
>                           

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20120606/a831771d/attachment-0002.html>