| From: | mef |
| Date: | 11 Sep 2000 at 18:37:45 |
| Subject: | RE: AMIOPEN: has anyone run SPEC benchmark using VP? |
Jim Peters [SMTP:jim@aguazul.demon.co.uk] writes:
>If an optimising VP->native code compiler can do a
>better job than the built-in VP (even if just by 10%),
>then why not ?
I think so.
>Leave it running overnight, generating native tools
>from each of the VP ones, and see the speed-up next
>morning.
I doubt it would have to run that long. When was the last time you had to
run GCC overnight? :)
>If so, it might be a nice project for someone
>somewhere down the line, to squeeze the last
>drops of power out of their particular processor.
This is one of the things that I was thinking about. My idea was basically
to code up a "front-end" to GCC that could read in VP bytecodes as GCC tree
expressions and then have it compile stuff to its native backend(s). This
is what the GCJ project does with Java bytecodes, and therefore it should be
possible with VP.
The bigger problem would be building the other tools to interact with the
GCC compiler. That is, one would probably need a slightly different
assembler/linker tool set than the one that Tao has released, which is
proprietary anyways.
>But I think the idea is that mostly there's no point
>- the VP is designed to be fast enough to save you
>from the temptation to code natively (and lose your
>portability and `code immortality' by breaking
>compatibility with the Amiga virtual machine).
First, one would not be coding natively, and therefore one would not be
loosing portability etc. That is, one could still use the current tools to
generate the "VP binary", but rather feeding it through Tao's translator,
one would be feeding it through a more sophisticated translator. In the
case of my idea, this translator would be the GCC optimization engine, which
is pretty darn good.
c.F. the GCJ project at http://sources.redhat.com/java/
Second, without benchmarks (which was the cause of this original thread of
discussion), we do not really know how well Tao's translator works. Sure,
stuff seems fast enough, and kudos to Tao for that. However, why not have a
little opensource project to 1) measure its performance, and 2) build an
even better translator that could be used to make various programs fly even
more!
Please contact me if you are an individual who might be interested to work
on such a project. Knowledge of the GCC tools (i.e., gcc, cc1, gas, gld,
etc.) internals would be great
Cheers,
Marc
Jim