Projects that I'm either too lazy or too ignorant to do.

Here are a list of ideas I have about Squeak, as I have not followed the
most recent developments closely, some of them may be redundant.

-- C Code generator improvements --
Prior to doing much with the VM or plugins, the C Code generator could
use some help.

1. Re-design it so that it does not have any special knowledge about the
interpreter. The current design does some rather supprising things to
the interpreter in the interest of speed.

2. Improve the support for C99 features, possibly even, *mumble* adding
an option to generate C++ classes.

-- VM improvements.

1. Design a profiling mechanism that can count the number of times any
specific bytecode is sent and a mechanism to access this information
from the image. I would imagine this would involve a "profile variables"
special object, and the ability to add "profileCounterA preincrement" to
 the mesage to be examined. This would help target further work on the VM.

2. Consider the idea of "atomic concepts" in that Interpreter should
only "know" about the most atomic classes including, but not limited to,
"SmallInteger", "ByteArray", "Object", "Float" (as it is a common
machine type...) and fail should any command trigger a result that lies
outside this domain. Many of the arithmetic operations could be
simplified tremendously if they didn't have to consider domain limitations.

##################
primitiveBitAnd
        | integerReceiver integerArgument |
        integerArgument _ self popPos32BitInteger.
        integerReceiver _ self popPos32BitInteger.
        successFlag
                ifTrue: [self push: (self positive32BitIntegerFor:
                                        (integerReceiver bitAnd: integerArgument))]
                ifFalse: [self unPop: 2]
#################

Could be rewritten as:

########################
PrimitiveBitAnd
        PopAndPushIfInt: StackTop bitAnd: StackSecond.
#########################

This works because the low-order bit of the result will be 1 iff both
oop arguments are ints and therefore are legal canidates for this
operation. The only thing that needs to be done then is to test that bit
and then write to the stack pointer exactly once and then to the stack
exactly once only if it succedes.

The other code goes through lengthy gyrations trying to determine if the
 value is either a positive int or a large integer that is also
positive... It then does type conversions if necessary, and writes to
the stack pointer three times whether it succedes or fails...

Add would have to be rewritten in assembler to test the CPU's overflow
flag as well as the low-order bits...

3. Prune the special objects list. It would be very helpful to be able
to instance things such as Display in order to elegantly support
multiple host windows, including multiple display devices (I wish mine
still worked; linux sucks...)

4. For smalltalk source readability, make variables used as constants ^K
methods...

5. Remove dead variables from long-abandoned projects such as jitter...

-- Low-level subsystem improvements.

1. BitBlit has experienced an absolutly astonishing degree of
mission-creep. It is now used as a general purpose byte-mover where it
is obviously something that is a sub-class of such a byte-mover. I have
seen a number of calls intended to simply move memory that include
special parameters to ensure that the color conversion engine doesn't do
anything to the stream... I can't immagine how this could be as
efficient as a wrapper for memcopy()....

-- UI improvements --

1.  Rewrite CommandShell so that it can be used with real terminals
including Ian's terminal emulator, virtual console devices such as
X-terms, and alternate consoles, and networked devices.

2. Finally remove that click-and-hold over world icon to bring up
super-secret menu feature.

--
Don't let your schoolwork get in the way of your learning.

### NEW E-MAIL: [hidden email] ###

Hi Alan,

on Sat, 13 May 2006 19:10:11 +0200, you <[hidden email]> wrote:

> Here are a list of ideas I have about Squeak, as I have not followed the
> most recent developments closely, some of them may be redundant.
...
> -- VM improvements.
>
> 1. Design a profiling mechanism that can count the number of times any
> specific bytecode is sent and a mechanism to access this information
> from the image. I would imagine this would involve a "profile variables"
> special object, and the ability to add "profileCounterA preincrement" to
>  the mesage to be examined. This would help target further work on the  
> VM.
...

This is on my list for quite some time now and, despite having not very  
much time, I can develop that, we here need bytecode profiling more than  
any other improvement or enhancement to the VM.

But, what makes us reluctant is that InterpreterSimulator seems to have  
collected a bit of rott. We do*not*want and have*not*much*time for the  
"[development cycle via gcc] loop".

And a colleague of mine would like to do his first Squeak project and  
visualize the results of profiling the bytecodes (perhaps also for the  
primitives+memory routines, we have drafted a design for an easy to  
implement general VM profiling implementation).

But without help from InterpreterSimulator, such a project won't fly (at  
least not for us here).

/Klaus