Alan Grimes <alangrimes at starpower.net> wrote:

> So here are some more peanut-galary comments about the interpreter:
> 
> 1. Functions to control platform specific features such as power 
> managment, sound IO, and some interfaces to the 3D accelerator are _IN_ 
> the VM ***BUT*** primitives to process basic data structures such as 
> float arrays and large integers are not...
There's a couple of miscellaneous prims hanging around that could be
moved but that would require co-ordinated image changes. Since we try to
maintain backward compatability over fairly long periods of time, this
is a barrier. I intend to excise them for the v4 release since we wil
be breaking backwards compatability all over the place. I disagree that
large ints and floatarrays are basic data structures. I don't think
there is any real reason to care whether LargeInt or FloatArray prims
are implemented as plugins code or internal-to-the-core code. There will
be even less when the new prim calling system is in use.

> 
> Furthermore the Large Integer Plugin seems to be very stale. The code in 
> the LargeIntegerPlugin seemed content to process a 64 bit int on a 64 
> bit platform with a loop that processed 1 byte at a time!!! I have not 
> really looked at it yet, I just discovered it this evening.
That's not stale, that's the chosen alorithm. Since LargeInts are byte
array objects it works well t process them byte by byte. Anything else
adds endian complications. If you have time to write faster
replacements that will work on all endian types, please do so and they
will be used.

> 
> It tried to write a version of BitAnd etc... to process anything that 
> could be thrown at it with one function. That effort showed that any 
> solution that my meager skills colud write would be very awkward and 
> slow... I think the best approach would be to simply attempt to do a 
> small-int -- small-int  operation then put, as the first operation of 
> the failue code, to simply swap the order of the first two items on the 
> stack and re-attempt the same selector. That should have the effect of 
> triggering the code that is more specialized for large ints...
I don't think attempting double dispatching within the VM is a very good
idea. Fail the prim and let the image work it out. Have multiple
versions of the prim that handle different mixes efficiently. Allow
polymorphism to work.

> 
> 2. I have come across some downright silly code...
> 
> In Object memory there are a number of global variables such as:
> 
> "fooObj" which are constants assigned to some value say 6,
> 
> Then there is a method barObj which is written:
> 
> barObj
>     ^ self  splObj: fooObj.
> 
> Finally, throughout the rest of the interpreter the constant fooObj is 
> _ALWAYS_ used with the call self splObj but the method barObj is NEVER 
> used.
It's inlined (almost certainly) in all the places where the
CCodeGenerator can manage. It's also there as barObj because it is in
the list that requires the CCG to keep a copy - so external files can
access it. Remove it and there is a good chance some plugin will stop
working - or coredump. It might be convoluted but it's far from silly.

> 
> 3. It is annoying trying to keep the generated sources in sync with 
> ./Cross/vm/sqVirtualMachine.h  It would be much more convenient if the 
> compiler generated the appropriate headers too. For example the compiler 
> already writes prototypes for all functions.  It would make more sense 
> to be able to declare some, as public by a method similar to the one 
> used to control the inliner and the compiler would simply emit these to 
> the common header which would save me alot of work cuz 
> sqVirtualMachine.h seems very stale to me, I have already identified a 
> number of problems and annoyances with it...
Depends where you get it from  and which version of VMMaker you are
using. We try to keep the version of SourceForge (and soon on the
squeakfoundation cvs server) up to date and matching VMMaker but just
occasionally it skews for a short while. However, since we only add (at
least I can't recall ever removing) it should never be a problem to use
a newer sq.h (etc) with an older VMMaker.
I'm sure there are some parts of the files kept as text files that
could be generated but thus far noone has considered it a worthwhile
use of their time to change much. Since we keep the platform specific
code as external text files it doesn't add much to keep the few
crossplatform files that way and at least in a cvs system we can track
changes.

To the best of my ability to tell there are no serious problems with
any of the platforms/Cross/* files when used with any recent VMMaker. To
what do you refer when you mention a 'number of problems and annoyances
with it...'? Tell us and we can think of fixing them.


tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Strange OpCodes: EFBI: Emulate Five-volt Battery Intermittently