Future of asm_fast grade with gcc 4

View: New views
2 Messages — Rating Filter:   Alert me  

Future of asm_fast grade with gcc 4

by Michael Day :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

The asm_fast grade is still faster for us than the hlc grade, but it
seems that there are issues supporting asm_fast with gcc 4.

Will the asm_fast grade be deprecated in the future, or will it be
possible to revive it? gcc 3.4 won't be usable forever, especially on
platforms like MacOS X which require customised gcc variants.

Alternatively, is there another option for the future, like using the
gcc back-end, or LLVM in Mercury?

Cheers,

Michael

--
Print XML with Prince!
http://www.princexml.com
--------------------------------------------------------------------------
mercury-users mailing list
Post messages to:       mercury-users@...
Administrative Queries: owner-mercury-users@...
Subscriptions:          mercury-users-request@...
--------------------------------------------------------------------------

Re: Future of asm_fast grade with gcc 4

by Paul Bone :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Mon, Oct 12, 2009 at 11:55:18AM +1100, Michael Day wrote:
> Hi,
>
> The asm_fast grade is still faster for us than the hlc grade, but it  
> seems that there are issues supporting asm_fast with gcc 4.
>
> Will the asm_fast grade be deprecated in the future, or will it be  
> possible to revive it? gcc 3.4 won't be usable forever, especially on  
> platforms like MacOS X which require customised gcc variants.

Hi Michael,

Zoltan and I have been working on these problems and have some partial
solutions.  We want (and need) to maintain the low level C grades as the
profilers and debuggers rely on them.  Also as you say asm_fast is faster for
some programs.

This work is something at occurs in some of our spare time, which their isn't a
lot off.  Therefore, this takes longer than we'd like it to.

> Alternatively, is there another option for the future, like using the  
> gcc back-end, or LLVM in Mercury?

I'd be interested in having an LLVM backend for Mercury.  The main problem here
again is resourcing, we'd need somebody to implement it and then people to
maintain it.

We'll probably make some sort of announcement when our ROTD builds work with
GCC 4.x.

Thanks.




signature.asc (500 bytes) Download Attachment