🚀 go-pugleaf

"Nick Maclaren" <nm...@cus.cam.ac.uk> wrote in message
news:bbhnfp$2as$1@pegasus.csx.cam.ac.uk...
>
> In article <bruce-706CA0....@copper.ipg.tsnz.net>,
> Bruce Hoult <br...@hoult.org> writes:
> |>
> |> I haven't seen a BCPL compiler since 1983/84, when some friends and I
> |> did an OCODE to 6809 back end, but from memory OCODE was pretty
horrible
> |> for high performance interpretation, but pretty decent for generating
> |> machine code from.
>
> Yes - its design dated from that era :-)
>
> My view is that it is long past time that we rethought the basics
> of how compilers and hardware fit together.  To a great extent,
> almost no commercial vendors have put any thought into the MODEL
> since the 1950s - and precious few academics have done better!
>
> I can think of several ways in which Martin Richards' and others'
> results could be significantly improved by hardware support, and
> there is a strong sense in which we should be moving away from
> source-to-machine-code compilers as the core of optimisation and
> towards higher level target codes and tuned libraries.

Can you elaborate on some of these ways.  While no one would argue with
tuned libraries wherever they make sense, SITM that there are lots of
places, perhaps even most, where they don't, and where the overhead of
calling them simply adds to the execution time.

> Yes, I know that this is very like Java, which is a pretty fair
> performance disaster - but the reasons for that are not in that
> aspect, but in its interactions with other aspects.

Again, ISTM that interpretation will always be slower than "direct
execution" given a reasonable compiler.  You just save too much overhead by
not interpreting and with more global optimizations to overcome with "tuned"
implementation of the primitives.

But I am open to other ideas, so I would like to see specifically what you
are proposing.

-- 
 - Stephen Fuld
   e-mail address disguised to prevent spam