Blair McGlashan wrote:
> "Eliot Miranda" <
[hidden email]> wrote in message
> news:7pvVc.5645$
[hidden email]...
>
>>
>>Andy Bower wrote:
>>
>>
>>>Pablo,
>>>
>>>
>>>
>>>>I have a basic question.
>>>>Dolphin apps works on windows CE?. I mean very simple applications
>>>>with simple interfaces.
>>>
>>>
>>>No, the Dolphin VM is tied to the x86 series of processors and
>>>therefore is not available for the PocketPC/CE machines.
>>
>>Andy, note that a number of WindowsCE machines use x86-compatible
>>processors. e.g. the Tatung WebPad uses a Geode, which is an (ex-natsemi)
>>x86 compatible.
>>
>>But I'm curious, given you don't do dynamic translation, what features of
>>the Dolphin VM do tie you to x86?
>
>
> Quite simply because it is largely written in x86 assembler. To get really
> good performance from an interpreter we found it necessary to be able to
> hand optimise certain critical aspects, since even one extra instruction
> behind certain bytecodes has a measurable performance impact. On older
> processors (PIII vintage and earlier) instruction ordering was also a very
> fruitful area for improving performance by using assembler in place of C,
> but this does seem much less important now on CPUs with out-of-order
> execution capabilities. With the benefit of hindsight I think it has
> probably cost us more over time to create and maintain a very highly
> optimised interpreter than it would have done to build a dynamic translater,
> and it has rendered the current Dolphin VM unportable.
I cut my teeth writing bytecoded VMs in C and post-processing the
assembler output to remove precisely those instructions. Every C
compiler I tried circa 1987 wasn't smart enough to realise that if one
fetched a byte and dispatched though a switch statement covering the
cases 0 to 255 that no bounds check was necessary. Sed or awk could be
used to remove the bounds checks. Further, certain C compilers were
dumb enough that if you used macros to add register declarations for the
VM's bytecode instruction pointer, stack pointer and frame pointer to
every function then the C compiler would use the same registers for
these variables. Thus sed or awk could be used to remove the register
save and restore instructions in the function prologs and epilogs
resulting in global register variables long before gcc provided it as a
feature. One could even write compiled bitblt in C (see e.g. my
BrouHaHa paper or Bart Locanthi's compiled bitblt paper). These tricks
were relatively easy to port from machine to machine (I once ported a
threaded code machine that used heinous tricks to generate direct
threaded code from the C compiler from 68k to SPARC in 3 days).
With these tricks I was able to equal the performance of e.g. the
Tektronix m68k VM which was hand-coded in assembler with a C VM that was
quite portable.
Of course the one platform which didn't support these tricks was ...
Windows, because the Microsoft C compilers produced object code directly
and their -S "produce assembly output" option was an afterthought that
worked by (incorrectly) disassembling the object code. Sigh...
But look, there's no time like the present. There's nothing (bar
resources, the constraints of running a real business, etc, etc) to stop
you moving parts of the VM to C. Soon it'll all be there.
> Regards
>
> Blair
>
>
--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd
Locked
