Re: Mike and Ward, what next?

On Fri, 17 Jun 2005 19:44:23 +1000, robert spykerman
<robspyke_nospam@[EMAIL PROTECTED]
> wrote:

>Even with the limited amount of registers an x86 has, in still seems
>on average to trounce PPCs on performance (the monster P4's, FX's and
>even overclocked Pentium M's - see tom's hardware) and probably
>efficiency as well (Pentium M and further iterations of same).

I'm no PPC expert - I get the architecture manuals out for
an hour or two once in a while.

First, CPU clock rate is *not* really the issue. At present,
CPU clock rate is 5-10 times greater than memory bandwidth, so
which CPU is faster depends very much on the cache and memory
structure *and* on the application use of memory.

The current Intel P4 memory architecture is dire and very
much assumes the use of C-style linkers. In a random number
generator benchmark that uses a single variable, we saw a
variation of 7:1 according to the address of the variable.
The P4 seems to have pipelines in the range of 21-41 stages,
and so is very susceptible to branch target problems.

In most cases, the memory design is not specified by the
architecture. Most SPARCs are very good in this respect.

>x86's FPU is a load of b*ll*cks compared to PPC but it is a 7 element
>stack like critter like forth.
>
>If you want to jump the wagon to learning x86 and keep doing forth,
>might I recommend Stephen Pelc's excellent VFX
>
>http://www.mpeltd.demon.co.uk/arena.htm
>
>If you like MOPS, you will LOVE VFX.... I have to say his code
>generator IMO is about the best on x86 platforms.

Blush. We spent a serious amount of time and money developing
the VFX code generator. Fortunately we managed to get a grant
for some of it. The results show that it was worthwhile. However,
we also designed VFX Forth for ****tability. There are fewer than
30 coded routines in the system, nearly all for startup and
O/S interfacing. The entire interface to the VFX code
generator is though COMPILE, and some internal data in the
dictionary headers.

When ****ting VFX Forth to another platform, changing CPU is
the least of the problems. The real work is in the binary
format, e.g. ELF, and in the operating system API interface.

I have not looked at source code for the Mac Forths, so I can't
comment on their ****ting issues, but providing that only the CPU
changes, the Forth kernel was designed for ****tability, and the
existing O/S kernel interfaces do not change, the job is quite
straight forward. Whether the authors have the energy for it
is another matter.

There are several quality Forths already for the Mac. I don't
see commercial success in MPE doing another except in
collaboration with an existing Mac organisation.

Stephen

--
Stephen Pelc, stephenXXX@[EMAIL PROTECTED]
 Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeltd.demon.co.uk
- free VFX Forth downloads