I said:

A set of Smalltalk primitives that models an ISA that was designed to handle advanced graphics and DSP operations, regardless of whether these are implemented using single instructions, or a larger C-based simulation, would be VERY worthwhile, don't you agree?

I've been looking more closely at the AltiVec instructions.

Here are a few of the potentially useful instructions that I'm thinking of simulating:

vperm: vector permute -takes 3 128-bit registers and merges the byte- contents of registers b and c based on the control bits in register a.

vor: vector logical OR -logical ORs 2 128-bit registers vnor: vector logical NOR -logical NORs 2 128 bit registers etc

vsl: vector shift left -128-bit shift left etc

vrlb: vector rotate left integer byte -rotates each byte in a 128-bit register by the amount specified in the corresponding low 3-bits of each byte in another register

vrlh: vector rotate left half-word -as above with 16-bits vrlw: vector rotate left word -32 bits etc

There are various vector mul-add instructions for bytes, half-words, words and 32-bit floats. Various pixel pack and unpack instructions, etc. 162 instructions in all.

I don't know what the savings would be to perform these operations via C primitives instead of directly in Smalltalk, but I betcha that they CAN save significant time and space. Testing new color transforms (like the GX colors that I want to do) would be a lot easier and faster if efficient multi-pixel bit-manipulation primitives were available, no?

I'm sure that other people could come up with other uses for the ability to perform vector arithmetic, bit-manipulation and logic operations via C-based primitives (and G4 Mac and AIX users would get single-cycle implementations of these in the CPU, of course).

---------------------------------------------------------------------- Use your imagination. ----------------------------------------------------------------------