front-end target arithmetic (was: [G95] Re: [tree-ssa] Integrating g95)

[Laurent GUERBY]

On Tue, 2003-06-03 at 17:34, Michael S.Zick wrote:
> On Tuesday 03 June 2003 07:40 am, Geert Bosch wrote:
> > Now of course, this is mostly because Ada requires calculations of
> > "static" expressions (subset of compile-time known expressions) to be
> > performed exactly.
> Ouch.

Well for a language designed in 1995, I don't believe it's that silly
to require this given the portability advantage it gives
for not that much work on implementors.

> > However, if you are doing a lot of inlining and compile numerical code,
> > I wouldn't be surprised if you'd do a lot of target arithmetic and find
> > that for some programs the time required is significant.

If inlining is on, then target arithmetic might be out
of the radar in proportion of the total compile time again :). 

> Is the Ada compiler (at compile time) using an external (to Ada)
> multi-precision library?

It's internal, see ada/uintp.ad[sb]  (infinite precision integer
arithmetic) and ada/urealp.ad[sb] (rational numbers arithmetic). That's
a bit less of 5 ksloc of documented code, no big deal.

> If not, could it?
> Could one mp library be used (at compile time) for both g95 & Ada?
> Might that also simplifing 'lifting' the Ada library(ies) upto the library
> level in the build tree?

Well, you're trading clean and simple code for configure/header/Makefile
headaches :).

If GCC decides to implement such a thing in C as a front-end service,
with care to special services required by the Ada front-end (I can think
of being able to dump/reload the number table from a file
like Table.Table does for GNAT), I'm inclined to think that Ada
maintainers wouldn't mind dropping the current Ada code
and just Import the C routines, probably low priority though.

Laurent